Linux.com

n/t

#

"Ellch notes that a crash caused this way doesn't guarantee a successful exploit, saying "If you're lucky, your UDP packet will end up on the stack. If you're less lucky, a beacon packet from a nearby network will end up on the stack. In the case where I successfully overwrote eip (Extended Instruction Pointer), the UDP packet was 1400 bytes."

does that mean it is or it isn't an exploit?
Is he aware that there's a free MacBook with his name written on it waiting for him?

<a href="http://daringfireball.net/2006/09/open_challenge" title="daringfireball.net">http://daringfireball.net/2006/09/open_challenge</a daringfireball.net>

#

He also went on to explain that while the debate was centered in the Mac blogger community, it made no sense to discuss it because most of them wouldn't understand the explanation if he gave it, adding, "Since this conversation has moved into a venue of people who can actually grasp the details of this, I'm ready to start saying something."

Regardless of if he is right (which I seriously doubt), does he actually believe that this is the way to have anyone take him seriously?

#

To be honest about this, Jon Ellch has lost credibility. It hardly matters whether he is right or wrong, the way how he handled it was one which I do not want to accept. And<nobr> <wbr></nobr>... Unable to explain because he claims that people are too stupid to understand? They can not grasp the details of it?

Har har har. What an ironic joke.
I must wonder.... anyway

Good luck to him, I think his comment qualified himself as being very stupid.

#

Judging from the decidely untechnical comments on this issue on this site and many others, I'd say he's right. Many, MANY people are fooling themselves into thinking they actually know what is going on.

I saw one comment where someone said "the term ring0 is now archaic; we all call it 'kernel space' now." I was floored. This is just stupid. One guy on THIS blog says he doesn't know why you need a UDP listener to make the exploit work, and, as I told him, this is actually step 1 (or step 0) or any remote exploit, having something that listens for packets. The same guy mistakes the memory heap for the memory stack. That's a very common problem for beginning students in Computer Science classes. I suspect that this guy just googled his information.

Stephen Colbert used the term "wikiality" to describe what seems to be happening around this issue. I liked that term.

#

"...
One guy on THIS blog says he doesn't know why you need a UDP listener to make the exploit work, and, as I told him, this is actually step 1 (or step 0) or any remote exploit, having something that listens for packets. The same guy mistakes the memory heap for the memory stack. That's a very common problem for beginning students in Computer Science classes. I suspect that this guy just googled his information."

Johnny Cache actually said this in his blog... "1) set up a netcat udp listener on the victim centrino box. (Why you actually need a listener is beyond me, but it seems to help)"
<a href="http://www.802.11mercenary.net/slashdot/" title="11mercenary.net">http://www.802.11mercenary.net/slashdot/</a 11mercenary.net>

#

Actually, John Ellche himself, over on <a href="http://www.802.11mercenary.net/slashdot/" title="11mercenary.net">http://www.802.11mercenary.net/slashdot/</a 11mercenary.net> says that he doesn't know why you need a udp listener to make the exploit work, so this comment seems odd, to say the least. Or maybe the slashdot comment isn't really Ellche and the paranoids are right.

#

Start laughing, use older wireless cards and disable apple's built in cards. Just think of it as wake on lan for the wireless world, the interface is never really off.....

Buy a roll of copper screen and line your laptop bag.

#

Are you aware that the UDP packet issue to which you refer was an attack against the Intel Centrino Drivers and is not talking about the MacBook exploit which is actually far more reliable?

#

Ellch then breaks down the elements of the vulnerability and possible exploits, but in the context of Intel drivers rather than Apple's, asking and then answering the obvious question of why he did so when he wrote: "Why am I switching the subject from Apple's bug to Intel's? Because it's patched, and Secureworks has no influence over what I say regarding this one."
Here he clearly states AGAIN that he has the exploit for the MacBook that he "hacked" on video at the conference...

#

then ask him to show us the prize. The hacked MacBook that Gruber promised him. Nothing more need said, nothing less.

#

So far I've seen them taint the media by focusing on Apple. The same day it was debunked that this was a *hardware driver* issue, and affected multiple platforms. Now one of the wonder twins declares Apple users ignorant in the same piece that he describes a) it's not all Apple's problem, and b) the exploit itself is a "plug'n'prey" exploit that may only *sometimes* work. So, not only would Apple users not understand the exploit, but we might ridicule him for a hit'n'miss exploit, as it would appear that *he's* not even sure how the expliot truly works.
I love how this is either an Apple or Intel issue, though distributions of Linux as well as Windows are directly related as well. If anything I would say that this is *his* attempt at a smear campaign against *Apple*....because as it stands it appears to be total vapor'sploit.<nobr> <wbr></nobr>:)

#

You prove his point almost completely in showing a complete misunderstanding of his posting. His "plug and prey" exploit as you refer to it is for a completely different chipset (Intel Centrino) and totally unrelated to the for more reliable macbook exploit. Did you pay any attention while you were reading?

#

How can you say the so called macbook exploit is "for [sic] more reliable" when the details of it haven't been released. Did *you* pay attention while you were reading or are you simply inferring something that has never been stated? I have to agree with the original poster you replied to. They started this with a grudge against Apple (remember, they thought Apple users were so "smug", so they tried to make a point by going out of their way to make Apple the target). Now it's time for them to put up or shut up and eat crow. So far, they're eating crow. How about we wait until all the details come out before conclusions are drawn.

#

I can say it because I know infinitely more about it than you do. its not my job or Ellch and Maynor's job to satisfy your curiosity, it is Apple's job to patch the problem. If these guys had released their exploit before Apple released a patch you would be the same people condemning them for irresponsible disclosure. You can't have it both ways. If you want responsible disclosure then get Apple to come clean. The exploit exists, quit trying to force irresponsible disclosure.

#

The exploit was made using a non-Apple wireless card (external USB adapter, which may or may not have shipped as a Retail "Mac Adapter"). The exploit was made using undisclosed, non-Apple drivers.

So what is it that Apple should patch?

A driver for wireless chipset they may not use that they didn't write and don't ship?

You're kidding right?

It might be somewhat different if Apple laptops didn't all come with built-in wireless.

#

I'm the "original poster" of this thread....

And yes, I have read, and I do understand...

But the problem here lies in vapor. These 2 guys...the only 2 in the world that have reproduced this, right? I ain't buying it...the OpenSource community should be able to reproduce the exploit based upon what little information has been provided. We know it's not just an Apple issue (so your point about Apple releasing a patch is kinda misdirected). And whether you know it or not, Centrino is a BRAND NAME for a set of features, not a chipset, not a logicset, but a BRAND NAME. My Intel Centrino notebook uses the SAME EXACT BROADCOM chipset as my Intel Mac Mini. My buddy's Gateway uses a different WiFi chipset, but is still labeled as a Centrino device. The point here is that you know SOOOOO MUCH about a friggin BRAND NAME, yet you continue to give us the same treatment as the egotistical Wonder Twins.

My point in the original post is that if they found something, be up front about it...show it as a proof of concept, introduce it to the OSS community, and either let the Linux guys start working on a patch and allow it to trickle down, or start sending your findings to the only people that can change the affected drivers....the manufacturers, which according to other reports I've read, has not happened yet. This is part of the reason Apple is collectively pissed, as aside from a press release and proof of concept, the Wonder Twins have done nothing more than blow hot air to keep the smoke screen moving forward.

As for them releasing it altogether and "most of us" getting worked up over it, I have one thing to say.....

If you know the flu is going around work, you may want to take a day or two off in order to avoid it. If you don't, you may want to call your insurance company to make sure you're covered for a vaccination....in other words, turn off your WiFi when you're roaming until the "doctor" has a vaccine available.

#

I really don't care what chipset your mac mini uses. The Macbooks under discussion uset the Atheros AR5006EX chipset which last time I checked was not part of the Intel Centrino family, so get your facts straight.

You have enough information to know that the flu is going around. It is your choice not to believe it. Leave your wireless enabled if you dont believe. You all seem to want to rewrite what is traditionally called responsible disclosure just to ease your minds. Will you then apply appropriate pressure to Apple to get a patch out quickly? I dobut it. Will you then feel like Apple left you hung out to dry since they have known the details for some time? I would hope so. Are you screaming at companies like Eeye that indicate they have remote code execution on Windows (<a href="http://research.eeye.com/html/advisories/upcoming/index.html" title="eeye.com">http://research.eeye.com/html/advisories/upcomin<nobr>g<wbr></nobr> /index.html</a eeye.com>) but fail to release details? If not why not? What is the difference? Get over it, this is the way things are done in the vulnerability discovery business.

#

Read about the Microsoft, RIAA, MPAA, infiltrators of linux here:

<a href="http://distrocenter.linux.com/distrocenter/06/09/01/149211.shtml" title="linux.com">http://distrocenter.linux.com/distrocenter/06/09/<nobr>0<wbr></nobr> 1/149211.shtml</a linux.com>

Browse down to the comments.

#

The answer is: "Yes. However it's only interesting and convincing if you can easily reproduce it and do some mischief with it."

Elch: "In the case where I successfully overwrote eip (Extended Instruction Pointer), the UDP packet was 1400 bytes."

If you overwrite eip, this means you're exploiting a buffer. Here is a rough general description on buffer exploits and race conditions.

A buffer / heap is just a management facility for most of the memory that applications use.

When an application (such as Mozilla, your command shell, word processor, and so on) needs some memory, it will typically take this memory from the heap. The heap is responsible for handling these requests, which involve handing out chunks of memory when requested, and freeing the chunks when the application is finished with them.

A problem can arise when programs don't make correct use of the memory that they receive from the heap - if they write before (buffer underrun) or past (buffer overrun) the chunks that they're given, they can corrupt information that the heap implementation uses to manage the chunks, and this can result in code execution exploits by fooling the heap into doing things by carefully crafting this management information. This is what Elch claims he did.

In the advent of 64-bit extensions to x86 in AMD64(at least in 64-bit mode) general purpose registers are now truly general purpose and they can be used interchangeably. The x86 general purpose registers further subdivide into registers specializing in data and others specializing in addressing. The general Adressing Registers contain: Stack pointer (used to hold the top address of the stack), Base pointer (used to hold the address of the current stack frame), Source index (used for string operations. It has a one-byte opcode for loading data from memory to the accumulator), Destination index(used for string operations. Has a one-byte STOS instruction to write data out of the accumulator) and the Extended Instruction Pointer (EIP) which holds the current instruction address.

To hack a system things a hacker must do:

1. find/invoke/invent a bug within some (important) part of the system (with a lot of permissions)
2. craft some instructions and put them in memmory.
3. make the eip point to that address. If you mess a little bit with applications (for example by using unexpected input) some (unknown) bugs may occur. Some of those bugs might be due by sloppy memmory management of the programmer.

Elch described the most important part (1) educative messing around with the system until some interesting bug pops up.

This bug invloves a by race condition. Race conditions are flaws in a process whereby the output of the process is unexpectedly and critically dependent on the sequence or timing of other events.

"There is a race condition inside the centrino driver. Unlike most straightforward ring0 exploits out there, this one is intimately related to timing. I also never bothered to reverse the driver because it seemed so unlikely that I would
actually figure out the cause of the bug that it wasn't worth it. Instead I just took a black
box approach. After many hours of staring at packet dumps I came to the conclusion that the
bug wasn't related to specific bytes/ordering of the packets, but the relative times. Triggering the race condition is fairly easy.

1) set up a netcat udp listener on the victim centrino box. (Why you actually need a listener
is beyond me, but it seems to help)

2) start blasting udp packets at it from a machine. sleeping for about 4000 microseconds
between packets seems to be a good start.

3) start flooding the victim machine with disassociation requests. A BSOD should follow very shortly. A delay of 5000 microseconds between packets seems useful.

If you're lucky, your UDP packet will end up on the stack. If you're less lucky, a beacon packet from a nearby network will end up on the stack. In the case where I successfully overwrote eip, the UDP packet was 1400 bytes.

The reason this bug takes two cards to exploit is that the race condition you are trying to win seems to be so small that a single card can't win it. Every attempt to trigger the race condition by sending disassociate packets, followed up by a flood of data packets out of the same card failed to land a data packet on the stack. This does not mean that the bug cant reliably be exploited. I suspect that a linux box patched with the appropriate real time patches required could hit this like clockwork. In the most extreme case one could put the exploit into kernel-land itself."

All hat's might question:
1. Is it indeed easily producable?
2. What possibilities does it give to the intruder?

#

It's a lot of fuss to exploit but if there is found some way to easily reproduce it, you get value for your effort, because you can then play with the most priviliged processor levels of the protected mode of your prey-machine.

Modern operating systems (such as OS-X) run in so-called protected mode. In protected mode, 4 different processor privilege levels (also called rings) are available, ring 0 being the most privileged one and ring 3 the least privileged one. Kernels of operating systems run in ring 0 whereas userspace code runs in ring 3. The set of operations available to ring 3 code is restricted by hardware-enforced security mechanisms such as segmentation, paging, and I/O privilege restrictions. A few security-critical assembly language instructions are also restricted to ring 0 operation.

Most software security techniques (PaX on Linux, W^X on OpenBSD, and so on) heavily rely upon protected mode enforced mechanisms.

"One Ring to rule them all,
One Ring to find them,
One Ring to bring them all and in the darkness bind them."
Lord Of The Rings

see: <a href="http://www.securityfocus.com/columnists/402" title="securityfocus.com">http://www.securityfocus.com/columnists/402</a securityfocus.com>

#

The heap is different from the stack. You wrote a lot of moderately technical stuff there and I'm not really sure if you know what it means. This isn't just "semantics" either. Heap overflows are signficantly different from stack overflows, and were not employed in this attack.

You don't know why you need a listener for UDP packets? This is step 1 (or step 0) of any remote exploit. If nothing is listening then you'd never have a remote exploit. You can substitute the generic netcat listener with any program that listens for UDP packets, apparently. The program layer is not involved in this particular exploit.

#

Nevermind my comment above about the UDP listener. I see that the argument that you mangled was actually that of Mr. Ellch himself? As some other sites have pointed out, the exploit in question in raw form requires no listening processes. However, it appears Mr. Ellch, in this instance went about setting up the exploit in the easiest way he could find, which is very common. Oftentimes it is not even necessary to exploit a certain process directly to know what an exploit is possible.

However, get the heap and the stack mixed up around anyone besides Mac zealots and you'll get laughed out of the room. I stand by my previous insinuation that you're an idiot (whoever you are).

#

That link is completely irrelevent to the wireless issue, thanks for the waste of time.

Do you people read at all??? The "simialr [sic] exploit in the MacBook" relates to the fact that the third party USB card used in the video demo is also an Atheros based card. It has nothing to do with the race condition problem that Ellch is descripbing on Daily Dave.

#

anyone that's messed with the OSx86 Project, or any Linux USB-WiFi drivers will attest that USB != PCI. What works for a PCI (or MiniPCI card for that matter) may not work with USB. The point here is that the exploit could depend on the actual USB drivers and not every Atheros WiFi driver.

#

I have a root level exploit for every system with an ARM processor, e.g. your washing machine, mobile, pda. Can't talk about it because of the IP of my company and several NDAs I had to sign. And obviously if I say anythin, they'll all sue me, because this exploit is HUGE

Mr. Money-Making-Blackhat-In-For-Free-PR

PS: I will supply a video soon, just need to wait for my Finalcut to arrive

#

"So much so that i'm releasing non-apple bugs to convince people that we do in fact know what we're talking about"...when we're...erm...talking about...erm...non-apple bugs, that is. Yeah.!

Also, we're not going to tell you if there is an apple bug or not until Apple release their patch...you know, the patch for the bug that we're not going to tell you whether it exists or not, because we're not allowed to tell you whether it exists...or not. So wait until Apple release their patch to find out if this bug exists or...erm...not.

#

From most of what I've read here, you people are simply incredible.
You write as if you actually know what your talking about. Truth is, most of you are flat out incompetent.
The condescendence of your posts gives your lack of any semblance of understanding away. Acting as if he wanted you to believe he saw a ghost.
I don't know these people, but I do know what I've seen and this is just the tip of the iceburg.
You all are in for quite a suprise.

AR for now.

#

It's like you're all pissed off at him for refusing to be a martyr for all of you. Based on your comments, you turds are the last people I'd give up my job for. Ingrates.

It's so ironic that you're pissed at him and defending Apple. Idiots. It's probably because of Apple's sitting on their skinny, vegan, holier-than-thou asses and refusing to patch the code in the first place.

Why lose his job over some stupid exploit on some shitty piece of Mac hardware? For you guys? Give us all a f***ing break already. Zealots.

#

Every blog I've seen has suffered the wrath of a few bad Mac zealots. I truly did not know what it could get this bad. This is "smugness" defined.

The ZDNet postings are the worst. Mac zealots are just plain going off at some George Ou guy. They claim that since they haven't seen any evidence, it must not exist. They go on to make lame, faux-intellectualist comments like "the term ring0 is archaic," and "I don't know why you need a UDP listener...." Weird.

#

Somebody said that Ellch and his companions "do not know how the exploit really works." However, the symptoms that he describes are typical of ALL buffer overflow exploits. They work differently under any given state of the program on the processor. Typically, crashing the program is the easiest thing to do, and only sometimes can you redirect the flow of a program into to the code of your choice. If you're off by a few bits or nibbles with your code, you just crash the program. This is, in fact, where the artistry of hacking comes into play.

Also, there is a VERY GOOD reason that the group did not perform this exploit live at the hackers convention, and instead chose to show a video of it. This is because the multitudes of very good hackers in the room would immediately fire up their favorite wireless packet capturing devices and dissect the exact nature of the attack by lunch.

All security companies are bound by various creeds to keep their attacks under wraps until the affected company has had time to fix the problem. Thus, neither of the guys is allowed to take on that crazy Mac zealot's challenge yet, nor they probably even care about getting a free Mac.

Finally, even though Ellch and company are losing the PR battle (who wins against bloggers anyway? that's the beauty of them, really), they probably only chose a Mac for the attack because knew EVERYONE at the convention would find it funny. The recent Mac commercials make real hackers sick to their stomachs, so this is what Apple gets for their "smugness," as the duo put it.

#

This fuss is incredible, the guy's absolutely right, many Mac fans are incredibly proud, ignorant, smug, and now fearful.

I have over 20 years' experience in most every level of programming, hardware and drivers writing, and I do know what I'm talking about.

Such bugs (race conditions) can and do happen and are often very hard to find or reproduce willfully or accidentally, a lot of trial-and-error will have been involved in finding the right timing to make this one happen.

Everything about what they guy says seems perfectly reasonable to me and I see absolutely no reason to think he's lying.

The mac zealots are insane for mocking him, he's just being a [nice/legally prudent] guy by keeping his mouth shut and not releasing anything like a ready-rolled exploit. I have absolutely no idea why mac owners are so terrified of the concept that some software in their machines has subtle bugs.

Please grow up - just because it's painted white, comes in a nice box and has an extra zero on the price tag doesn't have anything to do with low level software engineering. Some engineer at some company long ago who wrote that part of the wireless driver missed a subtle and hard-to-reproduce bug. It's just a bug, get over it. If you knew how hard programming was you'd probably have a bit more humility yourselves.

The fact that it's a bug with such severe security implications is merely bad luck. Count yoursleves lucky it's not leaked yet and some teenager's written a remote-mac-HD-formatter (which is both possible and not difficult if the attack he describes works, and I assume it does)

#

Like Adidias says "Impossible Is Nothing". It's the duplicable results that counts, otherwise it is just a miracle.

Remember "Cold Fusion"? It might be possible but not the ways those guys had them, so that made them visionaries? Or "X file" fodders?

Theories everyone has one. Show us the beef!

#

In terms of security hole, it appears almost irrelevant since they put third party wireless hardware in a Macbook. That seems odd to me since all of Apple's portables come with wireless hardware built-in

Uh, dude, exactly whose wireless hardware do you think you'll find in your MacBook? Oh, wait, could it be... Intel! Doh!

Now, I wonder who wrote the drivers for those lovely Intel WiFi cards. Could be Apple, or maybe it was their new buddies at, say, Intel?

but maybe it's for those pre-N cards or something else. So that part of the big joke was kind of lost on me too.

Well, that's a given. Next time you don't understand the issues, try shutting your pie-hole.

#

It was not the built in wireless chips that they were exploiting. Next time *you* don't understand the actual issue, please refrain.

#

I'd fall out laughing if this ended up to be all true. While I personally don't think it has high confidence of being real, it would still be a trip if it were.

#

Here I thought there was actually a real scoop!

Ahh well...

#

"Ellch notes that a crash caused this way doesn't guarantee a successful exploit, saying "If you're lucky, your UDP packet will end up on the stack. If you're less lucky, a beacon packet from a nearby network will end up on the stack. In the case where I successfully overwrote eip (Extended Instruction Pointer), the UDP packet was 1400 bytes." does that mean it is or it isn't an exploit? Is he aware that there's a free MacBook with his name written on it waiting for him? <a href="http://daringfireball.net/2006/09/open_challenge" title="daringfireball.net">http://daringfireball.net/2006/09/open_challenge</a daringfireball.net> [daringfireball.net]

#

where is the beef?! Why all these hot air. He should just do it. Take on Gruber, thank him for his MacBook and shut everyone up. No disclosure, no nothing.

this may or may not mean anything.

<a href="http://lists.immunitysec.com/pipermail/dailydave/2006-September/003465.html" title="immunitysec.com">http://lists.immunitysec.com/pipermail/dailydave/<nobr>2<wbr></nobr> 006-September/003465.html</a immunitysec.com>

#

It just appears that they were showing off for Defcon, which is always fun. However, their purpose at least in part was to show up all of those blind Apple lovers out there. Since I'm a developer who happens to use a PowerBook to code on, I don't know many of those blind Apple people so their big joke was kind of lost on me.

In terms of security hole, it appears almost irrelevant since they put third party wireless hardware in a Macbook. That seems odd to me since all of Apple's portables come with wireless hardware built-in, but maybe it's for those pre-N cards or something else. So that part of the big joke was kind of lost on me too.

In terms of media, I think it was irresponsible for the media to play up the fact that it was an Apple security hole. I think it's also irresponsible for the media to play up the whole worm or virus PROOF OF CONCEPT as being proof that despite the 76,000 viruses out there for Windows, Apple's OS and Windows should be considered equals for some reason. Their argument is always somehow that if more people had Apple's OS, there would be 76,000 viruses written for it or something.

I just think it was a good choice on Apple's part to go with a fairly rock solid foundation of BSD to build on, though they could have left out the default case-insensitivity in their HFS filesystem, but I digress.

#