Adobe misses low hanging fruit in Reader

One of the most common features of "secure development" is the ability to avoid functions that are known to be dangerous, functions which have caused major vulnerabilities (such as Internet worms) in the past. These are functions developed in the 1970s, before their risks were understood. Now that we have suffered from these functions and understand the risks, we have come up with safer alternatives. Using these alternatives are cheap and easy, and they can save a development house endless embarrassment and remediation time. More importantly, while verifying that your code is "secure" is an essentially impossible task, verifying that your code contains no banned functions is easy. We call this the "low hanging fruit" of secure development.

One such bad function is "strcat." It copies data from one area of memory into another. However, it does not check that the target memory is big enough. Strcat continues copying beyond the bounds of the target memory, overwriting other parts of memory. Hackers can manipulate the overwritten areas in just the right way to break into the machine. With 48,000 hits on Google for strcat vulnerabilities, some dating back more than a decade, this is a well known potential security issue.

The most recent exploit in Adobe Reader, the "SING Table Parsing Vulnerability" (CVE-2010-2883) contains exactly this function. First found exploited in the wild by Mila Parkour, this vulnerability has seen weeks of front page coverage. Metasploit's Joshua Drake did a great writeup of the exploit, here. Chester Wisniewski of Sophos posted a video that clearly demonstrates what the attack looks like, here. While this particular version of the exploit does use javascript, disabling javascript will not fix the problem (unlike the fix for the recent Adobe Reader Flash attack.)

So why doesn't Adobe fix its low hanging fruit? Why does it continue to use these toxic functions? It's strange, hardware vendors are removing hazardous substances (RoHS) from devices, but software vendors aren't being similarly diligent about cleaning up hazardous functions from old code. Errata Security provides a free tool known as "LookingGlass" that helps people see if their software is using these toxic functions. We ran it on Adobe Reader and found extensive use of these toxic functions back in 2008. LookingGlass can easily tell you if your software has these toxic functions, and quckly see what danger you are exposing yourself to. As of today, the danger from Adobe's software is still quite high.

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.

LookingGlass Vendor of the week: Google

Google just released Chrome, their own web browser. We decided to run it through Looking Glass and it doesn't look half bad. They at least have ASLR enabled on a few of their libraries, no NX though. Chrome is not as bad as some apps I have seen but that is not saying much.

LookingGlass Vendor of the week: Trillian

It has been a few weeks since I did a Vendor of the week post and I think its a great way to start off the week. Trillian has some bugs that you can read about here. Remember without protection like ASLR and NX vulns are easier to exploit.

The LookingGlass run of it:

New Team Member at Errata Security

Hi Everyone,

I'm Marisa and I am the new product manager for Errata's ProtoDev line of products. If you have feature requests for Ferret/Hamster, LookingGlass, or AxBan you can contact me at marisa@erratasec.com.

I'll also be contributing to the blog from time to time about the latest ProtoDev news and updates. It's really great to be a part of the Errata team, and I look forward to hearing from you all!

-marisa

Update on Apple and QuickTime

I just read at the Infosec Blog that a new version of QuickTime has been released that contain fixes that should make QuickTime harder to exploit on Vista. I say should because although it is a good start Apple did not completely close the loop. The reason ASLR is important to thwarting hackers is that the memory space of an application is randomized, or as the king would say, they are all shook up. Since most buffer overflows rely on knowing where a piece of code or data is in memory, the randomization can turn a remotely exploitable bug into nothing more than a Denial-of-Service. Although targeted attacks against individuals may still be possible, widespread QuickTime exploits will be much harder to write.

Not to signal doom and gloom but there is a problem or two. The main problem with implementing ASLR is that is really is all or nothing venture. If you have even one static shared library you open yourself to compromise. Below are screenshots of the new QuickTime from a filesystem and a process point of view using LookingGlass. Although most of the files are now marked as ASLR enabled there are still a few binaries that are not and could still provide an attacker a static location to utilize.

Don’t let these few oversights detract you from the huge stride forward Apple is making Vista users safer. It is good to see Apple embracing these security enhancements and I encourage other vendors, like Adobe, to follow their lead. I also hope that Apple extends these improvements to the other products offered to Windows users.

QuickTime File system scan withLookingGlass.

QuickTime Process scan with LookingGlass.

LookingGlass Vendor of the week:ATT

I have a Dell XPS 1330 with a built-in HSPDA card. Becasue of this I get some software branded ATT and its next up in my Program File directory. Bad ATT, no donut. This scan was done with LookingGlass 1.1 and the Microsoft SDL policy.
The stats say it all:

LookingGlass 1.1

We are releasing LookingGlass 1.1.

In addition o some bugfixes we have added the ability to define which “unsafe clib functions” you care about. Now when LookingGlass starts it will check the current directory for a file called lg-policy.txt. This file contains the policies and functions they contain. Right now there is a “Microsoft SDL” policy and a “Errata SDL” policy. To create a new policy you can just edit the lg-policy.txt and start you new policy with “#Policy:” and end it with “#Policy End”. In the middle you can add each function you wanted reported if found on individual lines. You need to restart the program after adding a new policy. It can be selected at runtime in the policy combo box.

You can find it at http://portal.erratasec.com/lg/LookingGlass.exe

Safari and Apple get Owned...Again...

Last week Apple released a huge security update, likely because 7 days later CanSecWest would be hosting its PWN2OWN contest. I wanted to write a blog post then and mention something about the best way to force Apple into releasing patches would be to announce an upcoming exploitation of Apples. It's not just Cansec, but the same thing happened when I announced I'd be publishing the disputed WiFi vulns at Toorcon, they quickly patched the vulns they denied existed. However, I decided to wait on that blog post.

Later in the week I saw Safari update debacle. I wanted to write a blog post about the underhanded padding of their marketshare, and note that Apple just made millions of Windows users less secure now by adding additional insecure code to their machines. However, I decided to wait on that blog post, too.

I decided to wait on writing both these posts because I know that even with the updates that Apple has released for Safari there are still tons of flaws in it that are exploitable and someone would leverage one to win the PWN2OWN contest and walk home with a Macbook Air.

Dave Aitel just reported on DailyDave that Charles Miller won the Macbook Air using a Safari exploit. I would like to note that out of the three machines (OSX, Linux, Vista) OSX was the first to fall. I hope this puts to rest the myth that OSX is more secure but I am sure the zealots will have a million reasons why this is a fixed or rigged contest. The only question I have remaining is who is going to be the first to file a class action lawsuit against Apple on behalf of users who were tricked into installing Safari and are now at risk of compromise? I am not advocating someone do that, I am not fan of needless litigation, but I can already picture the commercials the ambulance chasing lawyers could use.

"Were you tricked into installing Safari by Apple? Have you had any personal data compromised? Call the law firm of Dewey, Cheatem, and Howe!"

The other interesting thing about the updates is something I like to call the "window of owning". I advise our clients on this: Apple bundles open-source, but patches it late. It takes them weeks to as long as a year to patch their version of the code after it was patched in open-source. It's fairly straightforward to keep track of the open-source (and other 3rd party) code that Apple uses it, and when a vulnerability is announced for the open-source version, write exploits for the Mac version.

This "window of owning" is one reason that the update last week was so large. Apple security dug deep and fixed a lot of vulnerabilities that they would normally not bother with in a futile attempt to get OSX through the PWN2OWN contest unscratched.

UPDATE: More info at Security Focus.

UPDATE 2: Some people don't know the screenshot above is from our LookingGlass tool. I added it to show how many unsafe functions are used in Safari as well as the lack of ASLR or NX support. This means that I would wager that a vulnerability in the OSX version of Safari would also work on XP/Vista with a high success rate since Apple does not employ any of the available features to mitigate an attack.

The LookingGlass Vendor of the Week: Adobe

With the CanSecWest PWN2OWN contest pending the vendor for this week is particularly important. Adobe is fair game in PWN2OWN and this week it gets the scrutiny of the LookingGlass scanner. The first screenshot is from a filesystem scan, the second is the process scan of the Adobe reader, the 3rd is of a Flash helper application that I was unaware was running and I still don’t really know what it does. Since Flash is owned by Adobe now I decided to include it. As you can see there is an abundance of dangerous features and spotty support for ASLR and NX.
Up next week is AT&T.

New LookingGlass version: 1.0.1.0

LookingGlass Version 1.0.1.0 Released
This is a bug fix release.
The process scan now runs in a separate thread.
Process stats added.

New Version: Download at http://portal.erratasec.com/lg/LookingGlass.exe

The lookingGlass vendor of the week.

Now that a beta version of LookingGlass has been released, I will do a write up once a week on a vendor and how they fare under the scrunity. First up is Apple. The reason Apple gets the initial treatment is that Apple’s Quicktime inspired the creation of this tool. The two Apple applications I have installed are Quicktime and iTunes. Both have modules that do not support ASLR and NX. This can give an attacker a static location to make a remote overflow work, which allowed the two previous RTSP attacks to be exploitable. I doubt you will see a change anytime soon since I doubt Apple would want to have a more secure version of their software running on Vista than they would on OSX.

Next week: Adobe

New Looking Glass

A new version of LookingGlass with a process tab is available.
You can get it at http://portal.erratasec.com/lg/LookingGlass.exe