Dan Kaminsky Disqualified from Most Overhyped Bug Pwnie

Posted in Conferences, Vulnerabilities on July 9, 2008 by Dino Dai Zovi

I can be pretty skeptical and cynical at times (part of what drives my interest in security) and I am especially skeptical of massively hyped vulnerabilities. If anything, I tend to underhype what I do and let others hype it for me if they think that it warrants more attention.

With all of the hype around Dan Kaminsky’s DNS vulnerability, I naturally doubted that all of the hype was warranted.  I was flattered, however, when Rich Mogull called and invited me onto a conference call with Dan Kaminsky and the other Doubting Thomas (Ptacek, that is).  Dan explained the full details and scope of his attack and both of us were impressed and agreed that it is way more serious than we had imagined.  Yes, I am being light on the specifics here because I was sworn to secrecy and if I were to break it, Dan would cause my nameservers to rickroll me until the end of time.

In summary, when the full details of Dan’s attack come out, you will most likely be impressed.  I definitely was.

12 Comments »

ARDAgent.app Vulnerability Analysis

Posted in Apple, Vulnerabilities on July 5, 2008 by Dino Dai Zovi

Apple recently released Mac OS X 10.5.4 with accompanying security updates for 25 vulnerabilities.  Notably absent, however, is a fix for the recently brouhaha’d ARDAgent.app local privilege escalation vulnerability.  The exploit is extremely simple and unfortunately, it seems that the fix is not; otherwise Apple would have fixed it in this batch.  For more information on the exploit including temporary fixes and workarounds to protect yourself until Apple fixes this vulnerability, see the full write-up at MacShadows.com.

In the interest of fully understanding Mac OS X security issues, let’s dive in and see how this vulnerability works.  As a reminder, the vulnerability is that ARDAgent.app, a set-user-id root executable, responds to the “do shell script” Apple Event, effectively running arbitrary commands as root.

Applications must announce that they can receive Apple Events before they may be scripted.  In Cocoa applications, this is done by setting the NSAppleScriptEnabled property to “YES” in the application bundle’s Info.plist file.  In Carbon applications, an application is made scriptable by simply calling the AEInstallEventHandler() function.  AEInstallEventHandler() lets the application define which Apple Events it can handle and supply the handler functions for them.

ARDAgent.app did not do anything special in order to respond to the “do shell script” Apple Event, this event is defined in the StandardAdditions Scripting Addition in /System/Library/ScriptingAdditions.  Scripting Additions are dynamic libraries (dylibs) that will be loaded automatically by the Apple Event handler if the application receives an Apple Event that is defined in them.  There are several Scripting Additions in /System/Library/ScriptingAdditions, but they may also potentially be found in /Library/Scripting/Additions or ~/Library/ScriptingAdditions.

Interestingly, ARDAgent.app calls AESetInteractionAllowed() with kAEInteractWithSelf after installing its own Apple Event handlers which is supposed to restrict the processing of Apple Events to only those sent by the process itself.  It obviously does not seem to have its intended effect in this case.

This is a pretty isolated vulnerability not a massive security hole in AppleScript.  Set-user-id executables should not be scriptable and ARDAgent.app appears to be the only application that violates this.

UPDATE @ 20080704: As mentioned in the MacShadows security forums from the link in the comments below, SecurityAgent is also susceptible to this, but only when SecurityAgent is running with increased privileges (after a sudo, unlock of System Keychain, etc). But this is not because SecurityAgent is setuid, it is because it still receives Apple Events when it runs with increased privileges. It doesn’t, however, appear to call any Apple Events functions. So I am not sure why it is processing Apple Events (handled in a base framework?). If anyone knows why, let me know.

UPDATE @ 20080705: I have poked around at this a bit more this weekend, and it turns out that an application does not need to call any Apple Events APIs in order to receive and process Apple Events.  While Cocoa applications must set the NSAppleScriptEnabled property, any Carbon application automatically handles Apple Events.  At the lowest level, Apple Events are sent over Mach ports looked up from the bootstrap server, so you need port send rights in order to send it Apple Events.  This means that a client will not be able to send events to an application running as a different user unless it is setuid/setgid (ARDAgent) or is run with increased privileges, but still checks its ports in with the bootstrap server (SecurityAgent, which is launched by securityd with gid=0 on Tiger in certain situations).

3 Comments »

ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My!

Posted in Apple, Malware, Vulnerabilities on June 22, 2008 by Dino Dai Zovi

As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on MacOS X Tiger and Leopard.  While Intego calls this a critical vulnerability, I’m mostly with Ptacek on this one where I am saying this vulnerability is not nearly that serious.  For one, it only works when it is run as the user who is logged into the console.  This means that no MacOS X servers are affected by this, but it can allow a web exploit or trojan horse to gain root access without the user’s knowledge or permission.  Also while root access is pretty serious, it is not necessary in order for the malware to do bad things to your system (i.e. install itself to run automatically, backdoor Safari, etc).  So I will dub this a serious, but not critical, vulnerability.

Perhaps the most interesting fact about this vulnerability is where it came from: a  thread (from Google cache because the forums seem to be down now) on the forums at Mac Shadows, a mac underground web site.  The aforementioned thread was discussing how to build AppleScript-based trojans until “callmenames” discovered the vulnerability and the discussion moved towards the vulnerability and ensuing news and attention.  And at the time of writing, the forums on the site have been taken offline.

The big question on everyone’s mind is when malware will begin to seriously affect MacOS X and what will happen when it does.  As for when, I am betting that it completely depends on market share, as per Adam O’Donnell’s game theoretic analysis.  As for how bad, that will all depend on Snow Leopard: when it will ship, how it will improve MacOS X security, and how many users will install it.

Snow Leopard will hopefully raise the bar for MacOS X as much as Vista did for Windows.  Of course it won’t stop all security attacks, but it should make exploiting them beyond the reach of most attackers.  I’d personally like to see the following improvements:

  • Real address space layout randomization.  Library randomization with dyld loaded at a fixed location just doesn’t cut it.
  • Full use of hardware-enforced Non-eXecutable memory (NX).  Currently, only the stack segments are enforced to be non-executable.  Welcome to the new millennium where buffer overflows aren’t only on the stack.
  • Default 64-bit native execution for any security-sensitive processes.  I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process.  Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
  • Sandbox policies for Safari, Mail.app, and third-party applications.  Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications.  I love the scheme-based policies, by the way.
  • Mandatory code signing for any kernel extensions.  I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk.  Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate. 

I’m hoping that Snow Leopard ships before we see too much Mac malware, fixes all of the above, and that it is a free upgrade.  Yes, I know that’s unlikely, but users will not pay money for security features.  When users don’t upgrade and are subjected to malware, Apple may still get a bad rap for it.

10 Comments »

Pwnie Awards Nominations Open

Posted in Conferences, Vulnerabilities on June 18, 2008 by Dino Dai Zovi

It’s about that time of year: the days when a young man’s thoughts drift from work and toil to lighter things. Like pwnies. No, not the Lisa Simpson kind of pony, but the 2nd Annual Pwnie Awards at BlackHat USA.

The pwnie awards are an annual awards ceremony to celebrate the successes and failures of the security research and larger security community. Check out the site for more info and send in your nominations. Please submit nominations for vulnerabilities or research disclosed between June 1, 2007 and May 31, 2008 and the nominations will be announced on July 14th.

And make sure to come to the ceremony to enjoy the stand-up comedy, musical performances, and exquisitely handmade gold-painted My Little Pony dolls (with little imperfections so that you know they were made by a real-live Pwnie Judge).

1 Comment »

REcon 2008 Review

Posted in Conferences on June 16, 2008 by Dino Dai Zovi

This last weekend, I made it out to my first REcon and had a blast.  Hugo, the Daves, and the rest of the organizers deserve a lot of credit for putting on an excellent conference.  The conference is one of the most hardcore technical that I have been to and just about every talk had assembly code in their slides and the audience grokked it immediately.  And best of all there was no commercial presence, so it felt more like an academic conference than a conference where the presentations are just there to get you to show up and walk by the vendor booths.

Pedram wrote up some great day by day recaps of the conference, but I’m going to review some of my personal highlights.

Day One

Methods for analyzing malicious Office documents - Bruce Dang

Bruce works in Microsoft’s Secure Windows Initiative and spends a lot of time analyzing targeted malicious office documents, often ones exploiting Office 0day. How cool is that? He has noticed a familiar pattern of documents with payloads that run their trojan, extract a “clean” document from the original file, and then reopen the “clean” document in Office. Nasty stuff. Moral of the story: Use Office 2003 SP3, MOICE, and/or Office 2007 if you deal with a lot of office documents from external sources.

Ilfak Guilfanov - Building plugins for IDA Pro

Um, he’s Ilfak and to (badly) paraphrase Dave Ahmad’s introduction: Everyone loves Ilfak. Everyone, whether they are finding vulnerabilities, writing exploits, analyzing exploits, analyzing malware, or writing malware uses IDA. He talked about the architecture of IDA and how to write plugins for it. He could have just stood there for an hour and everyone still would have been happy.

Under the iHood, Cameron Hotchkies

Cameron gave a good overview of the internals of MacOS X and how a reverser might try to understand this space-alien technology: Bundles, Mach-O, Objective-C and how to rebuild Objective-C classes and method calls from compiled binaries. He also was so kind as to plug Charlie Miller’s and my upcoming book.

Day Two

Unfortunately, I missed a few of the earlier talks on Day 2 and my memory was a bit fuzzy on the other ones. I blame Pedram for all of the bottles that he bought at the club the night before.

Hacking Culture, Dr. Michael Strangelove

Michael has some interesting ideas about media ecology and the Internet, and I especially love his phrase, “democratizing the cultural means of production.” He also gave a very interesting performance at the REcon party on friday night. One thing though: Michael, you aren’t supposed to edit your own Wikipedia page.

Alexander Sotirov - Blackbox Reversing Of XSS Filters

Alex started off by scaring everyone in the room in the first minute of his presentation by confirming everyone’s unspoken fears: everything is moving to the web. He consoled the frightened conference-goers, however, by reminding everyone that there can be interesting reverse engineering challenges on the web and you won’t have to take a turpentine shower after dealing Cross-Site Scripting vulnerabilities. In a nutshell, Alex crafted input to Facebook to reverse engineer their anti-XSS filters in order to build a local model of them to simulate attacks against. He then used this model to find real live Facebook XSS bugs and forcibly shut down the Zombie army application. Oh wait, I just wished that he’d do that last bit.

Day Three

Yes, on sunday I only made it to one talk. However, you’d be amazed at how good poutine tastes at like 5am. Or just how bad it’ll make you feel at 6am.

Tiller Beauchamp - RE:Trace - Applied Reverse Engineering on OS X

DTrace is freaking cool. Solaris has it, FreeBSD has it, and MacOS X has it. Linux should begin to feel totally left out around now and for also missing out on the gravy train of cool that is ZFS. Oh yeah, back to Tiller’s talk. Tiller showed off a lot of cool ruby debugging and reversing tools for MacOS X so I was bound to like his talk. Check out his slides once they go up on the REcon site for DTrace tricks to detect stack and heap smashes among other nifty techniques.

Leave A Comment »

RECONnaissance

Posted in Conferences on June 10, 2008 by Dino Dai Zovi

REcon is back and in Montreal this year, so I’m going to be flying up there for the weekend to check it out.  I’ve heard great things about this con and am looking forward to some interesting talks:

Wait, Alex Sotirov the ANI/HeapFengShui ninja does XSS?!?  This should be interesting…

Leave A Comment »

Dead Bugs Society: Introduction and AnswerBook2

Posted in Dead Bugs Society, Vulnerabilities on June 8, 2008 by Dino Dai Zovi

Looking back, I have been finding and exploiting security vulnerabilities for almost a decade at this point and have always loved remote code injection exploits the most.  Notice that I didn’t call them “buffer overflows,” because I think that is too specific.  The rest of the industry has started calling them “remote code execution,” which is much better, but I still prefer my terminology from back when I was playing hacker-turned academic.

I refer to these vulnerabilities as memory trespass vulnerabilities since that is a more general term that is an accurate description of buffer overflow, format string injection, out-of-bounds array access, double-free, and uninitialized variable vulnerabilities where the attacker can write to memory outside of the semantics of the programming language runtime.  While these vulnerabilities can be exploited in a number of ways, the most popular technique is a code injection exploit where a standalone machine code fragment, the exploit payload, is executed by the target process via an injection vector.  Popular injection vectors include overwriting stack return addresses, exception handlers, and other code pointers.  I consider techniques that do not inject payloads but merely reuse code that already exists in the address space (i.e. return into system() to run a chosen command) a different way to exploit memory trespass vulnerabilities.  Those are far less common anyway.

So what does this have to do with anything and what is the “Dead Bugs Society?”  This will be an until-I-get-bored-with-it blog feature where I dredge up some old exploit, publish it, and wax poetic about it.  Most of these will be of the code injection variety, so I wanted to introduce my terms.  To be clear, these are all old long-ago patched vulnerabilities.  I will also only publish an exploit or detailed information for a vulnerability that has been fixed for at least a year.  These are for educational purposes only, unless you have a time machine in which case you better share because I’d like to go rock 1994 with my 2008 skills also.

For the debut of this series, I’m publishing the first remote zero-day code execution exploit that I wrote: a remote format string/stack overflow exploit against the AnswerBook2 web server that was enabled by default in Solaris 2.6 - 8 on TCP port 8888.  I reported these vulnerabilities to Sun immediately, but they took their sweet time in fixing them and I finally published the advisory 2 years later.  I tend to comment heavily, so it should be pretty self-explanatory.  Enjoy the antique warez!

5 Comments »

Thoughts on the Flash Malware Attack

Posted in Malware, Vulnerabilities on June 2, 2008 by Dino Dai Zovi

It has almost been a week since the Adobe Flash zero-day attack false alarm.  Since then, a number of people have called Symantec out as being irresponsible for crying wolf and announcing the raising the ThreatCon without fully researching the vulnerability (Full disclosure: Based on that information, I wrote here that the exploit took advantage of a zero-day vulnerability before I had tested it on a patched system — I was more interested in reversing the malware payload at the time).  We must be careful, however, to make sure that the real lesson isn’t lost while we all breathe a collective sigh of relief: the vulnerability may as well have been zero-day.

Google Analytics has a nifty feature where it will give you information on your visitor’s browser capabilities, including the version of Flash installed down to the revision level1. I was looking through the analytics for my other, more neglected web site and noticed that less than a third of my high-technical visitors had a current version of Flash. An anonymous robot contributed statistics for a larger site that had significantly more visitors2 and the statistics confirmed the low percentage of up-to-date Flash players.

Date % up-to-date
5/26 15.28
5/27 15.93
5/28 16.50
5/29 17.51

Remember, this is still 7 weeks after the update was released. This brings me to my main points:

  • Flash 9 has 97.2% penetration in mature markets
  • After roughly 2 months, less than 20% of users had applied an update that addresses a critical remote code execution vulnerability
  • At CanSecWest’s PWN2OWN 2008, Shane Macaulay and Alexander Sotirov proved that with proper Feng Shui and a Java applet, a flash vulnerability is still very much exploitable even on Vista SP1 with ASLR, Hardware-enforced DEP, etc.
  • TippingPoint’s Zero Day Initiative has 7 upcoming advisories for high-risk vulnerabilities in Adobe products.  I doubt any of them are in Photoshop.
How does the average user know that they should update flash and how to do so?  By reading the trade press?  Microsoft learned that you have to harass the user into patching their operating system and even then, it should be as automatic as possible.  As Flash currently enjoys an essentially universal market share, now is the time to make significant security improvements without having to repeat the lessons that others have had to so painfully learn.

1. Actually, you only get revision numbers if the user’s browser is FireFox. I believe it is safe to assume that the average FireFox user would be more Internet security savvy than the average Internet Explorer user, so we may consider these numbers an upper bound.

2. Data is based on several hundred thousand unique visitors.

2 Comments »

“Virtual Worlds, Real Exploits” Presentation Posted

Posted in Conferences on June 1, 2008 by Dino Dai Zovi

Charlie Miller and I presented our research into exploiting SecondLife at ShmooCon 2008 and they have just posted our materials online.  Check out the video to see Charlie and I running our Linden-stealing QuickTime exploit in SecondLife, live and on ice stage.  For more information, check out the slides or more details at Independent Security Evaluators.  This year was my first ShmooCon and I really had a blast, so props to the Shmoo crew for putting on a fun con.

UPDATE @ 20080605: An authoritative reader corrected me on the slides that, “http://www.kb.cert.org/vuls/id/112179 was a heap overflow parsing the Reason-Phrase.  I think the vulnerability was actually CVE-2007-6166 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6166 which was a stack buffer overflow in the parsing of the Content-Type and which had a PoC by h07.”

Very true, we got the links wrong, the exploit was for the Content-Type stack overflow.

Leave A Comment »

MacOS X Vulnerability Metrics: Apple vs. The World

Posted in Apple, Vulnerabilities on May 29, 2008 by Dino Dai Zovi

Apple dropped a ton of security updates this week and since everybody loves vulnerability metrics, I’m going to join in on the fun also. But unlike seemingly everyone else, I’m not going to compare MacOS X to another operating system and tally up which system had the most critical vulnerabilities this month. I’m going to compare bug hunters: Apple vs. external researchers vs. upstream packages and draw a (hopefully) interesting conclusion.

I have always been fascinated by the number of unattributed vulnerabilities in Apple’s security update notices, which I am assuming are internally identified vulnerabilities (Apple Product Security, perhaps?).  Apple is pretty unique in this regard, most closed-source software vendors don’t issue security updates for internally identified vulnerabilities in shipping products. So we have to either assume that everyone else is only fixing the vulnerabilities in the development branch of their next release or they aren’t even looking. Software, especially critical software connected to the Internet, is not the Ronco Showtime Rotisserie: You can’t just “set it and forget it.”

So let’s see how they stack up for the year so far. My methodology is simple. Count vulnerabilities by CVEs, eliminate duplicates, and tally up which vulnerabilities were: unattributed, credited to an external researcher, or fixed as part of Apple updating an externally developed part of MacOS X to a newer version. Although WebKit is an open source project, I considered it Apple code so vulnerabilities fixed in it are counted as either internally or externally found vulnerabilities.

The 2008-003 update had 41 security updates: 12 of which were internally identified, 10 reported by external researchers, and 19 vulnerabilities fixed in upstream software packages. The 2008-002 update was a whopper with 20 internally identified vulnerabilities, 8 externally reported, and 62 (!) in upstream packages. The relatively petite 2008-001 update had 3 internally identified vulnerabilities, 5 externally reported, and 3 from upstream packages.

I counted up all of the Apple Security Updates (including iPhone, AirPort, etc) for the year and the grand totals were:

  • Internal: 44
  • External: 53
  • Upstream: 84

This brings me to my guess as to what Apple is doing and my advice to software vendors: You should be finding and fixing at least as many vulnerabilities in your shipping products as external researchers are. There is no reason that you can’t keep up, you have the source code and they don’t.  Only finding and fixing vulnerabilities in development for future releases and treating external vulnerability reports like other bug reports (customers X have issue Y w/ product Z) is a bad model for security vulnerability response when “customers X” are 98% of Internet users, “issue Y” is remote code execution, and “product Z” is Flash.

2 Comments »

« Previous Entries
Next Entries »