New Microsoft technical blog about security vulnerabilities RSS
We are excited to have this outlet to share more in-depth technical information about vulnerabilities serviced by MSRC security updates and ways you can protect your organization from security vulnerabilities. You can read much more about the goals of the blog and about the SWI teams contributing to the blog in our “About” link: http://blogs.technet.com/swi/about.aspx
Friday, December 28, 2007
New Microsoft technical blog about security vulnerabilities RSS
Posted by them at 11:01 AM
Thursday, December 20, 2007
by Matt Conover 2007
To learn to exploit real heap memory corruption vulnerabilities on Windows one of the things you have to do is to read every Matt Conover's publication. The next are two posts in the Symantec Security Response Blog about double free() bugs. More articles and publications by him will be posted later in this blog.
In light of the recent CSRSS double free bug, I wanted to provide some information on the exploitation of double frees on Windows on XP SP2 and later. Prior to XP SP2, double frees were trivial to exploit, but now the security cookie (in each heap chunk) and safe unlinking checks make it more difficult to exploit. So this blog entry will discuss the exploitability on XP SP2 and later heap implements.
Double Free Vulnerabilities Part 1
Double Free Vulnerabilities Part 2
Tuesday, December 18, 2007
Craig J. Heffner article about the problems he found while reading and following the examples in Smashing The Stack For Fun And Profit using a modern Linux system.
"...the GNU C Compiler (gcc) has evolved since 1998, and as a result, many people are left wondering why they can't get the examples to work for them, or if they do get the code to work, why they had to make the changes that they did. Having these same problems myself, and being unable to find an updated version of Aleph One's document on the web, I set out to identify the source of these variations on my own. ..."
Smashing The Modern Stack For Fun And Profit
Sunday, December 16, 2007
Valgrind is an award-winning suite of tools for debugging and profiling Linux programs. With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, avoiding hours of frustrating bug-hunting, making your programs more stable. You can also perform detailed profiling, to speed up and reduce memory use of your programs.
The Valgrind distribution currently includes four tools: a memory error detector, a cache (time) profiler, a call-graph profiler, and a heap (space) profiler. It runs on the following platforms: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux.
The main excitement in 3.3.0 is new and improved tools. Helgrind
works again, Massif has been completely overhauled and much improved,
Cachegrind now does branch-misprediction profiling, and a new category
of experimental tools has been created, containing two new tools:
Omega and DRD. There are many other smaller improvements. [...]
0x01 Introduction The Circle of Lost Hackers
0x02 Phrack Prophile of the new editors The Circle of Lost Hackers
0x03 Phrack World News The Circle of Lost Hackers
0x04 A brief history of the Underground scene The Circle of Lost Hackers
0x05 Hijacking RDS TMC traffic information signal lcars
0x06 Attacking the Core: Kernel Exploitation Notes twiz
0x07 The revolution will be on YouTube gladio
0x08 Automated vulnerability auditing in machine code Tyler Durden
0x09 The use of set_head to defeat the wilderness g463
0x0a Cryptanalysis of DPA-128 sysk
0x0b Mac OS X Wars - A XNU Hope nemo
0x0c Hacking deeper in the system scythale
0x0d The art of exploitation: Autopsy of cvsxpl Ac1dB1tch3z
0x0e Know your enemy: Facing the cops Lance
0x0f Blind TCP/IP hijacking is still alive Lkm
0x10 Hacking your brain: The projection of consciousness keptune
0x11 International scenes Various
Putting risk in perspective: Do people make better decisions when they understand average risk? from PhysOrg.com
If there were a pill that would cut your risk of breast cancer in half, would you take it? What if you were told your risk of breast cancer was already below average?
- 1. Trust User Input at Your Own Peril
- 2. Protect Against Buffer Overruns
- 3. Prevent Cross-site Scripting
- 4. Don't Require sa Permissions
- 5. Watch that Crypto Code!
- 6. Reduce Your Attack Profile
- 7. Employ the Principle of Least Privilege
- 8. Pay Attention to Failure Modes
- 9. Impersonation is Fragile
- 10. Write Apps that Non-admins Can Actually Use
Friday, December 14, 2007
CERT Secure Coding Standards
A collaborative site that provides rules and recommendations for secure coding practices in the C and C++ programming languages
Managed string library
The managed string library provides a more secure alternative to standard null-terminated byte strings in C. Managed string functions dynamically allocate memory as required, eliminating the possibility of buffer overflows, string truncation, and other common programming errors.
Secure integer library
This library includes functions for safe integer conversions and arithmetic operations.
Publications Podcast RSS
Not very interesting besides the title and abstract. It could be included it in the "everything ever written about format strings vulnerabilities" section.
By Vinod Ganapathy, Sanjit A. Seshia, Somesh Jha, Thomas W. Reps, Randal E. Bryant
We argue that finding vulnerabilities in software components is different from finding exploits against them. Exploits that compromise security often use several low-level details of the component, such as layouts of stack frames. Existing software analysis tools, while effective at identifying vulnerabilities, fail to model low-level details, and are hence unsuitable for exploit-finding. We study the issues involved in exploit-finding by considering application programming interface (API) level exploits. A software component is vulnerable to an API-level exploit if its security can be compromised by invoking a sequence of API operations allowed by the component. We present a framework to model low-level details of APIs, and develop an automatic technique based on bounded, infinite-state model checking to discover API-level exploits. We present two instantiations of this framework. We show that format-string exploits can be modeled as API-level exploits, and demonstrate our technique by finding exploits against vulnerabilities in widely-used software. We also use the framework to model a cryptographic-key management API (the IBM CCA) and demonstrate a tool that identifies a previously known exploit.
Blended Attacks: Exploits, Vulnerabilities and Buffer-Overflow Techniques in Computer Viruses
by Peter Szor and Eric Chien / Virus Bulletin Conference September 2002
Peter Szor is the author of the excellent The Art of Computer Virus Research and Defense.
Thursday, December 13, 2007
The purpose of the WASC Script Mapping Project is to come up with an exhaustive list of vectors to execute script within a web page without the use of [script] tags. This data can be useful when testing poorly implemented Cross-site Scripting blacklist filters, for those wishing to build an html white list system, as well as other uses.
The Script Mapping Project
If your interests include software vulnerabilities, buffer overflows, and exploiting them in current windows systems then what Matt Pietrek wrote in 1997 is still relevant for you
A Crash Course on the Depths of Win32 Structured Exception Handling
Posted by them at 9:56 AM
Wednesday, December 12, 2007
This vulnerability type is less frequent than buffer overflows but more entertaining to exploit. There are probably more articles written about how to exploit them than real format string vulnerabilities in programs. The best one is the scut/team-teso paper.
- Exploiting Format Strings Vulnerabilities - scut@team-teso Sep 2001 V1.2 PDF
More than ten years ago Aleph One published the "Smashing The Stack For Fun and Profit" article in Phrack. It is still referenced when anything about buffer overflows is written. It was not the first research or publication about the subject but well, it made a difference. What happened since then? more papers, more exploits, worms, books, conferences, courses,
solutions, a whole industry around this flaw?