Alex and I holding "No More Free Bugs" sign during Charlie's Lighting Talk at CanSecWest

A few weeks ago, Charlie Miller, Alex Sotirov, and I arrived on a new meme: No More Free Bugs.  We started talking about it publicly at CanSecWest where Charlie Miller notably announced it for his Lightning Talk and in his ZDNet interview.  It is now making its way through Twitter and the rest of the tubes.  It is understandable that this may be a controversial position, so I’m going to give some more background on the argument here.

First, this is neither advocating non-disclosure nor any disclosure at all.  That decision is left to the discoverer of the vulnerability.  I’m not even going to touch the anti/partial/full disclosure argument.

Second, this philosophy is primarily regarding vulnerabilities in products sold for profit by for profit companies, especially those that already employ security engineers as employees or consultants.  Vulnerabilities discovered in open source projects or Internet infrastructure deservedly require different handling.

The basic argument is as follows:

• Vulnerabilities place users and customers at risk.  Otherwise, vendors wouldn’t bother to fix them.  Internet malware and worms spread via security vulnerabilities and place home users’ and enterprises’ sensitive data at risk.
• Vulnerabilities have legitimate value.  Software vendors pay their own employees and consultants to find them and help them fix them in their products during development.  Third-party companies such as Verisign (iDefense) and ZDI will pay researchers for exclusive rights to the vulnerability so that they may responsibly disclose it to the vendor but also share advance information about it to their customers (Verisign/iDefense) or build detection for it into their product (ZDI).  Google is even offering a cash bounty for the best security vulnerability in Native Client.  Donald Knuth personally pays for bugs found in his software and Dan Bernstein paid $1000 personally as a bounty for a vulnerability in djbdns.
• Reporting vulnerabilities can be legally and professionally risky.  When a researcher discloses the vulnerability to the vendor, there is no “whistle blower” protection and independent security researchers may be unable to legally defend themselves.  You may get threatened, sued, or even thrown in jail.  A number of security researchers have had their employers pressured by vendors to whom they were responsibly disclosing security vulnerabilities.  Vendors expect security researchers to follow responsible disclosure guidelines when they volunteer vulnerabilities, but they are under no such pressure to follow responsible guidelines in their actions towards security researchers.  Where are the vendors’ security research amnesty agreements?
• It is unfair to paying customers.  Professional bug hunting is a specialized and expensive business.  Software vendors that “freeload” on the security research community place their customers at risk by not putting forth resources to discover vulnerabilities in and fix their products.

Therefore, reporting vulnerabilities for free without any legal agreements in place is risky volunteer work.  There are a number of legitimate alternatives to the risky proposition of volunteering free vulnerabilities and I have already mentioned a few (I don’t want to turn this into an advertisement or discussion on the best/proper way to monetize security research).   There just need to be more legal and transparent options for monetizing security research.  This would provide a fair market value for a researcher’s findings and incentivize more researchers to find and report vulnerabilities to these organizations.  All of this would help make security research a more widespread and legitimate profession.  In the meantime, I’m not complaining about its current cachet and allure.

The Mac Hacker’s Handbook by Charlie Miller and myself has just been published and is now shipping from Amazon.  I have even spotted it in several bookstores where you can usually find it in the Mac section.  The book is all about Mac OS X-specific vulnerability discovery, reverse-engineering, exploitation, and post-exploitation.

For me, this book is a culmination of over 8 years of personal Mac OS X security research.  I had bought and restored a NeXTSTATION Turbo Color in college and fell in love with the NeXTSTEP and OpenStep operating systems.  When I got a check for my first pen-test, I bought a brand-new iBook 500 Mhz to run OS X 10.0 on and I have used OS X as my primary operating system ever since.

Of course, I started hacking on it immediately.  I wrote a monitor-mode wireless packet capture driver for AirPort (Viha) back when the only documentation on IOKit was the Darwin source code and a series of emails on the darwin mailing lists from an Apple kernel developer.  And that was just the first part of my WEP cracking project for my Crypto class.  I was so stubborn about using my iBook for it that I wrote my own driver, stumbler, and WEP weak RC4 key cracker for it.

There was also very little documentation on shellcode for PowerPC around then.  Palante and LSD had both released PowerPC shellcode for Linux and AIX respectively.  But there was nothing for OS X.  I wrote this in a hotel room in Washington, D.C. a few days after DEFCON 9.  As far as I know I was the first one to publish PowerPC shellcode that filled in the unused bits in the ’sc’ instruction instead of dynamically overwriting them because self-modifying code is pretty tricky on PowerPC.  That shellcode is what appears encoded in the hex bytes on the cover of the book.

Alright, enough self-indulgent trips down memory lane.  I just presented “Mac OS Xploitation” at SOURCE Boston last week and I’ll be doing a bigger presentation called “Hacking Macs for Fun and Profit” next week at CanSecWest with Charlie Miller.  Stay tuned here for some more Mac tool releases.

At Hack in the Box in Kuala Lumpur this year, I was interviewed by Sumner Lemon of IDG about various Mac and iPhone-related security topics.  One of the topics was the relative security of ARM versus x86 processors and my comments on this seem to have bounced around the internets a bit.  There seems to have been some confusion over what I meant in my statements, so I thought I’d provide some clarification here on the technical and economic rationale behind this statement.

First, the technical rationale: The classic x86 architecture (pre NX-bit) is an exploit developer’s dream.  Almost every other architecture has complications that x86 almost coincidentally does not.  For example, SPARC has register windows, PowerPCs can have separate data and instruction caches, any RISC architecture has alignment requirements, most architectures support non-executable memory, and all of these make writing exploits on these platforms more difficult.  The x86 had none of these speedbumps and only started supporting truly non-executable memory somewhat recently.  Finally, the x86 instruction set is incredibly flexible, allowing all sorts of ingenious techniques for self-modifying code to evade character filters and intrusion detection systems.  Of course, this was all possible on other architectures as well (see ADMutate’s SPARC support), but x86 makes it way easier and more powerful.  I have a hard time imagining what could be changed in x86 to make a better target for exploit developers.

Since cybercrime and malware has become a significantly sized industry, it makes a lot of sense to analyze the risk presented by it through economics (and game theory).  Attackers have a lot of infrastructure already built that is x86-specific.  Besides exploit development experience, this also includes payload encoders and hand-written assembly exploit payloads.  Rewriting these takes time and effort.  Macs (and iPhones, as postulated in the article) using x86 processors allow attackers to carry over their experience and existing infrastructure, slightly lowering the barrier to entry to begin attacking a new platform.  If a new platform with marketshare X% starts attracting malware authors’ attention, a new platform with a familiar processor may attract malware authors’ attention at (X – Y)% marketshare (where Y is probably less than 10).  In the end, however, this earlier attention most likely matters less to the product vendor than the deep discount or performance improvements they can get by going with a dominant CPU architecture and manufacturer.

In summary, just about any commodity non-x86 CPU-based system is harder to write exploits for than an x86-based system assuming the same operating system is running on both.  But it does not matter because these differences are just speed bumps and a good exploit developer will be able to work around them.  Vendors should focus on the generic security defenses that they can build into their operating systems and application runtime environments as well as focus on eliminating software vulnerabilities before and after their software is shipped rather than caring what processor architecture they use and whatever impact it may have on attacks against their platform.

Finally, I would also like to make a retraction.  In the same interview, I said that I considered the iPhone OS to be “significantly less secure” than the desktop Mac OS X.  While I would still consider the iPhone OS 1.x to be less secure than Leopard, the iPhone OS 2.2 is quite the opposite.  A number of improvements, including a smaller attack surface, application sandboxes, a non-executable heap, and mandatory code signing for every executable launched (not just applications, even low-level binaries) make compromising the special-purpose iPhone more difficult than the general-purpose desktop Mac OS X.  For more details on the security improvements in the latest iPhone OS, see Charlie Miller’s HiTBSecConf presentation.  Of course, this primarily applies to unjailbroken iPhones since a jailbroken iPhone allows execution of unsigned binaries and it seems that most jailbroken phones still have an SSH server running with the default root account password anyway.  Qualitative comparisons of security are very difficult to whittle down into a one sentence summary, but that’s why organizations (hopefully) have security analysts around and don’t make all of their decisions based on what they read on the Internet.

It has been a busy few months as I have been finishing up the writing for The Mac Hacker’s Handbook and traveling to Malaysia to present Mac OS Xploitation at Hack in the Box.  I had to take a break from the blog to focus all of my writing on the book, otherwise my editors and co-author (Charlie Miller) would kill me for delaying the project.

So more content (and code) will follow soon.

For today’s installment of Dead Bugs Society, I’m going to dig up another one of my favorite exploits.  This exploit is actually the second exploit that I wrote for the Apple File Server FPLoginExt stack overflow that DaveG found while we were both working for @stake.  I will also take this time to apologize to DaveG for insisting that the bug was a long PathName element (it wasn’t — it was a long UAM string), so that is why the advisory is wrong.  Oops.  My first exploit did a return into libc to branch into the stack pointer so that I didn’t have to hardcode or brute force stack addresses.  But for some odd reason, it worked most of the time, but not every time.  It was only after thinking about it a lot and a helpful tip at DEFCON that year that I figured it all out.  My second exploit, written post-@stake, for the AFP bug fixed that problem and made exploiting this remote root code execution vulnerability 100% reliable .

The PowerPC cache design makes exploits very interesting.  The PowerPC architecture may have separate instruction and data caches, but not necessarily.  PowerPC processors also may have write-back or write-through caches.  Understanding why these affect cache coherency, especially for exploits where you are dynamically injecting machine code as data and then executing it as instructions, is very important.  Apple’s processors have spanned just about every combination of these.  For example, whereas the earlier PowerPC 601 processors had a unified L1 cache, the G3 and G4 had separate 32 KB instruction and data L1 write-back caches.  The G5 on the other hand, has separate 64 KB instruction and 32 KB data L1 write-through caches.  For a quick comparison between the G4 and G5, see Apple’s TN2087: PowerPC G5 Performance Primer.

The difference between a write-back and write-through cache is when the data from the cache block is written to the next-level cache or main memory.  In a write-through cache, changed data is written through immediately.  A write-back cache only sends the data back to the next level when a “dirty” cache block is expired from the cache.  What does this mean for exploits?  On a separate write-back cache processor like the G3 and G4, your exploit payload will be sitting in the L1 data cache and when the CPU branches to your return address, it will fetch the instructions to execute from main memory or the L2 cache.  It is highly unlikely that an address on the stack will already be in the L1 instruction cache.  Essentially, the CPU will execute stale memory instead of your exploit payload.

In order to get reliable execution, I needed a way to deterministically flush the caches.  My first exploit worked most of the time because I would often trigger a page fault by returning into libSystem.  The page fault would cause a mode switch into the kernel, flushing all caches to main memory.  If I didn’t cause a page fault, however, the exploit would fail.  In the end, I wrote a stub that bounced around libSystem five times in order to execute a system call and then branch indirectly through the stack pointer back into my shellcode.

Chris Eagle’s long-awaited The IDA Pro Book has a very straightforward title, but it is perhaps the most descriptive title possible for this book.  It is simply the IDA Pro book.  The book weighs in at 640 pages and really does an excellent job of covering everything from the basic usage of IDA to using the SDK to extend IDA’s capabilities.  While IDA Pro comes with documentation, it is nowhere near as comprehensive or easy to read.

Chris Eagle is clearly an excellent educator, as he makes the sometimes very dense and technically involved material easy to read and understand and also chooses his examples well.  One of my personal favorites is an extended example on writing an IDA processor module for Python bytecode.  The bytecode’s simple stack language made it easy to focus on the specifics of writing IDA processor modules without getting bogged down in architectural details.  The amount of material spent on how to extend IDA is also unique to this book.

This book does not cover the basics of the x86 architecture and x86 assembly, so it is assumed that the reader is already familiar with it.  The book also does not spend too much time on showing how to identify high-level language constructs (functions, C++ virtual methods, switch tables, loops, etc) in assembly.  After all, this is a book on how to use IDA, not a book on how to read disassembly.  For an extensive treatment on how to read disassembly, check out Kris Kaspersky’s Hacker Disassembling Uncovered or Eldad Eilam’s Reversing: Secrets of Reverse Engineering.

There are several skill levels of IDA Pro users.  The casual (can follow strings or imports references to interesting functions), experienced (can use custom structures to make code easier to read), advanced (can turn assembly into C pseudocode manually), and professional (can write custom IDC scripts and plugins to automate repetitive and/or difficult tasks).  This book makes getting to the higher levels much easier and should really be considered an essential purchase along with an IDA license for any serious user.

Congratulations to all of the nominees and winners of the 2008 Pwnie Awards.  We had a much larger turnout for the ceremony this year and we actually had people present to accept their awards and give acceptance speeches.

In case you missed the awards, you can see the list of winners at the Pwnie Awards site.  Or get yourself some fresh popcorn, a cold beer, and some nice buggy code to relax and watch the video that Alex Sotirov just uploaded today.  Be sure to mock the guy with the “I 3> Pwnies” t-shirt.

It’s that time again.  It’s 110 degrees in Las Vegas and if that wasn’t causing the locals enough worry, the yearly invasion of hackers this week certainly will.  Expect to see more humungous LCD displays blue screen and guys walking around in the heat wearing black leather trenchcoats (that’s dedication!).

Anyway, it looks like there will be a lot of cool stuff happening at BlackHat, and here are some of the talks and events that I am looking forward to on Day 1:

• Alex Ionescu, “Pointers and Handles”:  I love the smell of kernel exploits in the morning.
• Dan Kaminsky, “Black Ops 2008: It’s the End of the Cache As We Know it”:  As if I would miss Dan’s talk this year.  Besides, if Dan is going to try and propose a last-minute Pwnie Award nomination, I have to be there.
• And of course, The Pwnie Awards!  Alex Sotirov, the other Pwnie Judges, and I have been working really hard on the awards for this year, so make sure to come out and laugh at support your peers.
• Rafal Wojtczuk, “Subverting the Xen Hypervisor”:  Backdooring and rootkitting Xen.  While I think that hyperjacking (ala BluePill and Vitriol) will not be possible for long since eventually most servers will run in virtual machines, rootkits within existing hypervisors could become be the new kernel rootkit.
• Mark Dowd and Alex Sotirov, “How to Impress Girls with Browser Memory Protection Bypasses”:  Alex was kind enough to hook me up with a draft of their paper and they have done some awesome work.  No one who does vulnerability analysis should miss Dowd and Sotirov dropping space alien technology.  In fact, if you use a web browser, you should see their talk.

Anyway, if anyone is trying to hunt me down, DM me on Twitter.

In evolutionary biology, the theory of punctuated equilibiria states that evolution is not a gradual process but instead consists of long periods of stasis interrupted by rapid, catastrophic change.  This is supported by fossil evidence that shows little variation within a species and new species that appear to come out of nowhere.  These changes are found to occur in small groups on the periphery of the central population where selection pressures are higher and often in response to changes in the external environment.  Eventually those peripheral groups replace the dominant species in an abrupt change.  While this theory has also been applied to the social sciences and business, it also applies to Internet security.

In the late 80’s, it was the “summer of love” era on the Internet.  Research institutions and universities were freely connecting to each other in a way that would make anyone of modern Internet sensibilities blush.  Internet sites regularly engaged in risky behavior, including exchanging traffic without the use of a protective firewall to protect against accidental infections (as such things were rare in those days).  Most users used weak passwords and some (Richard Stallman, notably) used none at all.  And then, just like in the Guns N’ Roses music video, the party was unceremoniously ended in the sudden cold November rain.  The Morris Worm swept through the Internet, taking machines down faster than anyone could imagine.  The era of innocence and non-disclosure of security vulnerabilities on the Internet had come to a close.

After the Internet worm, a variety of organizations were quickly established in order to track and address vulnerabilities in the Internet infrastructure.  The Computer Emergency Response Team (CERT) was established to handle any similar situations and a variety of mailing lists such as Phage, the Zardoz Security Digest, and Core Security Mailing List were established to discuss and track security vulnerabilities.  All of these lists and groups, however, were closed communities and the CERT security advisories were light on details in fear that revealing full details would enable attackers.  Thus began the era of partial-disclosure of security vulnerabilities.

A small full-disclosure movement began to grow on the periphary of the Internet.  This community believed that CERT was doing the community a disservice by not pressuring vendors to address vulnerabilities and revealing full information because system administrators were not able to determine whether they were vulnerable or not and should take the potentially disruptive risk of patching security vulnerabilities.  With full-disclosure, all parties are notified of the vulnerability at the same time.  Vendors are pressured to address serious vulnerabilities quickly and users have enough information to decide whether they should work around the vulnerability and/or apply the patch when it becomes available.  This community was centered around the Bugtraq mailing list.  This community quickly grew through the mid 90’s and early 2000’s until it became the dominant method of vulnerability disclosure on the Internet.

If the late 80’s was the era of free love on the Internet, the late 90’s and early 2000’s was the era of free exploits.  Fully working exploits for serious vulnerabilities were regularly published on Bugtraq often as part of the disclosure of the vulnerability.  These were often remote privileged code execution exploits in serious Internet infrastructure like BIND, SSH, NCSA HTTPD, Sendmail, and Apache.  These exploits allowed administrators to easily test if they were vulnerable or not.  If they ran the exploit and they got a remote shell, they were definitely vulnerable.  Similarly, if someone wanted to take joyrides on the Internet, all they had to do was subscribe to Bugtraq, wait for an exploit to be posted, and then start scanning for vulnerable machines.  Thus were “script kiddies” born.  This environment continued through the early 2000’s.

The early to mid-2000’s could be considered the hangover from the free love 80’s and free exploit 90’s of the Internet.  Instead of Internet worms being a one-time event, they became an almost regular occurrence with ILOVEYOU (May 4, 2000), Code Red (July 13, 2001), Code Red II (August 4, 2001), Nimda (September 18, 2001), SQL Slammer (January 24, 2003), Blaster (August 12, 2003), and many others in between.  Many of these worms used exploits that had been posted publicly to Bugtraq to spread.  Clearly something was not right.  This onslaught of Internet-crippling worm outbreaks quickly brought about several evolutions in Internet security: “responsible” disclosure, the home router firewall, and Microsoft’s Security Push and Secure Development Lifecycle (SDL).  It was no longer enough to respond to security vulnerabilities and incidents as they happened; Internet security required proactive measures to protect against future disasters.

From 2003 until roughly the present, “responsible” disclosure and the duality of offensive security research and defensive security products have driven the security industry forward.  Security researchers have investigated and discovered volumes of security weaknesses, vulnerabilities, and attacks.  All of these have required security patches, restructuring, and risk mitigating technologies née product opportunities: anti-virus, firewalls, intrusion detection/prevention, patch management, etc.  Hundreds of vulnerabilities have been “responsibly” disclosed and patched.  Patching has become a monthly Shamanistic ritual for most IT departments.  There are now defensive security products to defend against every possible perceived security threat (imagined and real).

With all of this, Internet malware has only become more prevalent on users’ systems.  The United States Departments of Commerce, State, and Defense, have sustained targeted attacks and on multiple occasions detected large amounts of sensitive information being remotely extracted from their networks.  There is a serious DNS cache poisoning vulnerability that currently affects 50% of the nameservers on the Internet, almost a month after the issue has been disclosed throughout the tech and mainstream media and a week after a highly-effective exploit for it has been publicly released.  The Internet security community is holding its breath waiting for (hoping for?) widespread attacks, perhaps to justify their continued existence.

Clearly, we are not any closer to securing the Internet, if that is even possible.  If anything, the dangers on the Internet have gotten worse as the malicious actors have changed from joyriding teenagers to Internet worms to espionage and organized crime.  Right now, Internet security is due for another period of rapid change.

UPDATE @ 20080729: As pointed out in the comments below, the “cybercrime is bigger than drugs” figure is bogus.  I have removed it and instead used a reference to Microsoft’s latest Security Intelligence Report showing a general growth in malware.

This weekend at The Last HOPE, Jacob Appelbaum, Karsten Nohl and I gave the following presentation on the Debian OpenSSL weak PRNG vulnerability.

In May 2008, a weakness in Debian was discovered which makes cryptographic keys predictable. A Debian-specific patch to OpenSSL broke the pseudo-random number generator two years ago, which led to guessable SSL and SSH keys. The vulnerability allows for impersonation of secure servers, as well as the potential to login to SSH secured systems. Since many popular derivatives like Ubuntu and Xandros are affected, the weak keys are found all over the Internet. The panel will present their approach to generating lists of weak keys using cloud computing and explain how they collected large numbers of SSL certificates of which several thousand are weak.

Presentation materials:

• Slides
• Forthcoming: Weak RSA keys
• Forthcoming: Patch to ssldump to decrypt SSL traffic if the remote site has a weak RSA key and RSA key agreement is used