Sometimes names just do not reflect the nature of things. Sometimes it is our fault to attribute a wrong meaning to names. I do not know which of the above holds for Windows ASLR. After Alex Sotirov and Mark Dowd’s talk at Blackhat I know that ASLR is not that random despite of its name.
The ASLR abbreviation contains “randomization”, which is enough (at least for me) to deduce that EXEs and DLLs get loaded at randomly chosen addresses. I was wrong to think that this makes it hard for the attacker to guess the loaded addresses. As it turns out, binaries get loaded to somehow predictable addresses.
While I understand that there were some technical difficulties and compatibility issues, the implementation choices made for ASLR effectively weakened it a lot to the point that it failed to deliver the promised.
Another revelation of this talk was that IE happily loads any .NET DLL provided by the web server using the plain old LoadLibrary function. The ramifications of this are enormous because the system is essentially accepting raw binary data (a file of the PE file format) and runs it on the user’s computer. No need to talk about GS, SafeSEH and any other protections mechanisms after this.
The outcome of these two choices is also predictable, as Alex and Mark demonstrated to us: anyone visiting a malicious web site with IE can be easily owned.
There were other interesting talks at Blackhat, no way I can mention all of them here. Just one more pointer: I was amused and amazed by Hovav Scacham’s Return-Oriented Programming. As it turns out, pieces of “good” code in standard libraries can be used to build a turing-complete machine. This machine is programmable by the attacker using a byte code which does not require the X (execute) bit in the page permissions. This defeats W^X or DEP protections.
My talk on decompilers was received well. If you missed it, find the white paper here.
Heading to DEFCON now, for more interesting talks!
Team
- Ilfak Guilfanov
- Elias Bachaalany
- Igor Skochinsky
- Daniel Pistelli
The IDA Pro Book (2nd Ed)
-
Recent Posts
Recent Comments
- Joxean on The trace replayer
- Jonas on The trace replayer
- Darmawan on Recon 2012: Compiler Internals
- Joxean on The trace replayer
- Xing on The trace replayer
Categories
Archives
- May 2013
- April 2013
- June 2012
- April 2012
- January 2012
- October 2011
- September 2011
- August 2011
- July 2011
- May 2011
- April 2011
- February 2011
- January 2011
- December 2010
- October 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- February 2009
- January 2009
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- April 2008
- March 2008
- February 2008
- January 2008
- November 2007
- October 2007
- September 2007
- August 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- October 2006
- September 2006
- August 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005

Hi Ilfak,
I enjoyed your decompiler presentation. I wanted to ask you if you considered using an existing compiler for implementing some of the passes that you mentioned in the talk. Some compilers provide infrastructure for def-use chains, in addition to passes such as mem2reg, cfg simplifications, etc .
Nadav
Nadav,
I did not use any third-party code. Everything in the decompiler has been developed from scratch. Compiler code is too strict for decompiler, which has to make some assumptions about the input and change them if they turn out to be wrong.