DLL exploit not a job for secure coding programs

The big "zero-day" exploit this week was the malicious Windows DLL payload brought to the spotlight by Rapid7's HD Moore. Two other researchers appear to have also found this bug as well. Microsoft released a security advisory on this class of vulnerabilities, and stated "This issue is caused by specific insecure programming practices that allow so-called "binary planting" or "DLL preloading attacks". These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location."

So which one is it? Is this an issue caused by insecure coding practices, or by insecure desktop administration and security policy execution? The secure coding methodology made famous by Microsoft didn't protect them from having at least 4 major applications affected by this bug. Researchers say that Microsoft has known about this class of vulnerability for anywhere from 6 months to 10 years, depending on who you read. So why didn't they catch this bug? While it might seem to be, this is NOT an admonishment of Microsoft or their secure coding practices. The Microsoft SDL and SDL-Agile are successful, game-changing strategies that I give a lot of credit. The reason the SDL didn't catch this DLL code execution bug is because a bug like this is outside of the scope of a successful secure coding program. In a secure software development lifecycle, the goal is to prevent bugs from the start that are easy and cost-efficient to eliminate. The SDL is great at preventing SQL Injections and catching bugs where code sanitization is the fix, however this bug is in code that is behaving exactly as it was designed. In April 2009, Aviv Raff was told by Microsoft when dealing with a very similar disclosure that this bug was not a simple fix. "They said it would be very problematic to fix the whole thing, and would break a lot of third-party Windows applications."

Microsoft has put out a tool to help administrators mitigate the problem, and has a lengthy description to help guide developers to construct their code differently in the future. This is an appropriate response based on their Security Response Practices. It is possible that it is more cost-efficient to respond to a disclosure such as this than it is to prevent it. Third-party companies such as Rapid7 and Errata Security are adding modules to their auditing tools to check for this attack. Actions such as these may actually cause the DLL Preloading Attacks to become "low-hanging fruit" in the development process in the future, but for now it should not be expected that a secure coding program should have prevented this attack.

iPhone Shellcode by Metasploit

HD Moore publishes information on iPhone shellcode at the Metasploit blog. The shellcode combined with the number of bugs present in the iPhone finally make mobile attacks a real threat.

A really good question deserves an answer…

As a comment to our previous Safari post I got a really good question from Jeffrey Hawkins and exploit terminology. His question reads:

“I notice you found 2 remote execution bugs, but said one of them was
"weaponizable". What does that mean?Specifically, how can one remote execution
bug be weaponizable, while the other is not?”

First of all not all software bugs all vulnerabilities, sometimes a bug is just a bug and nothing useful can be done with them. One step up from useless bugs are Denial-of-Service (DoS) bugs that while MAY have some security impact in reality are mostly annoying and are often caused by things like NULL pointer dereferences. Most researchers think a DoS is lame. Then we have code execution vulnerabilities. These are software flaws that allow the flow of execution of a program to be redirected to whatever arbitrary code an attacker chooses. These are what most people search for however just because you find a bug like this doesn’t mean it’s exploitable or reliable. There are several factors that can cause a code execution bug not to be exploitable such as the process dying before execution has been achieved (remember to get execution often times you are overwriting parts of the process memory that may be relied upon later), nothing useful to overwrite, thread problems, and hardware or software based anti-exploitation technology like NX or DEP.

Weaponized basically means you have found a remote execution bug that you can successful and reliable get code execution (not just theoretical or in a lab environment) that requires little or no effort on the part of the attacker to successfully exploit. The exploit will also take application or operating system versions into account and can work on a variety. The Metasploit project is an example of high quality weaponized exploits.

A round up of things...

If you have been asking how to get Metasploit on the N800, you can find instructions here.

Its clock change time. If you have a blackberry and its not displaying the right time, you might need this patch.

I am on a eWeek panel this week with Jon Ellch, HD Moore, and Joanna Rutkowska. That’s right, 4 of the top 5 hackers on 2006 according to eWeek. I guess Mark is busy.

We will be making a new version of Ferret available at Blackhat Europe, with some really cool new features!

I also saw the 300. It made 70 million this weekend. That’s almost unheard of for a R rated movie. It’s great to see that there are movies moving away from the mindset that you have to make a movie PG-13 to make any money.

Maybe I am jaded but I didn’t really find it all that violent. A lot of reviewers seemed shocked over the level of violence, but it was more comic book style stuff that hardcore gore that you would find in something like Saw or Hostel (neither of which i really liked). Here is a tip for aspiring filmmakers, if half you movie is in slow motion you should find a different way to build drama or suspense. Every time there was a huge action scene I thought the slow-mo killed all momentum, it was like watching a music video...for two hours.

Needs more cowbell

With a few utils from here, and a ruby package from a friend of mine, its pretty easy to get metasploit running on a Nokia N800. I love that cow banner.

Thanks go out to HD Moore for making metasploit so easy to install on new platforms.

UPDATE: Breaking into a Win2k SP4 server using the ms03_026_dcom exploit. This is nifty!