Code Execution Bug In Broadcom Wi-Fi Driver

QUARANTINE by LiquidCoooled · 2006-11-11 23:11 · Score: 0, Offtopic

Is this the same airborne virus that is attacking the skinjobs in Battlestar galactica?
If its attacking base stations, maybe we can get rid of the rest of the skinjobs and toasters while we are at it.

--
liqbase :: faster than paper

Thanks by SnowZero · 2006-11-11 23:19 · Score: 5, Funny

Thanks for mentioning the affected operating system(s). Oh wait, you didn't...
Here, I'll help:
Code Execution Bug in Broadcom Wi-Fi Windows Driver

Re:Thanks by Anonymous Coward · 2006-11-12 15:20 · Score: 0

is there even a broadcom wifi driver for linux?

Well crap. by Merc248 · 2006-11-11 23:23 · Score: 5, Funny

Checklist for today:

Eat
Rant on Slashdot
Change SSID from "omgomgomgomgomgomgomg" to "omgomgomg"
Sleep

--
"Hegelians, who love a synthesis, will probably conclude that he wears a wig." - Bertrand Russell

So... by radu.stanca · 2006-11-11 23:27 · Score: 4, Insightful

...the BlackHat presentation this Johnny Cache gave was not just FUD, he really did find bugs in wireless drivers.

Re:So... by Gideon+Fubar · 2006-11-12 00:03 · Score: 1

It pissed me off at the time that so many people were jumping on the anti-anti-apple bandwagon, without knowing John's credentials.

It was never about apple, kids. That's what he (and guys like him) do. Just be greatful he's on your side, not just his own.

--
http://www.xkcd.com/354/
Re:So... by masklinn · 2006-11-12 01:08 · Score: 2, Interesting

Yeah. In third party drivers for a third-party wireless adapter. He still hasn't disclosed any information on a bug in apple-supplied wireless drivers for apple-supported wireless devices, even though he was offered stuff for actually proving what he'd said (John Gruber, for example, offered to give him two brand-new fresh-out-of-the-box macbooks if he managed to hack them)

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:So... by dfghjk · 2006-11-12 01:51 · Score: 3, Interesting

Still sensitive are you? The claim was that many platforms were vulnerable, not just macs.

"He still hasn't disclosed any information on a bug in apple-supplied wireless drivers for apple-supported wireless devices..."

Nor are they obligated to. Odds are that the presentation had the desired effect and there was no need to proceed further.

"...even though he was offered stuff for actually proving what he'd said (John Gruber, for example, offered to give him two brand-new fresh-out-of-the-box macbooks if he managed to hack them)"

No, here's the link:

http://daringfireball.net/2006/09/open_challenge

Gruber challenged them to hack a macbook (not two) with many stipulations. The challenge was to be videotaped and the conditioned were not under the control of the hackers. If the challenge was not met, the hackers would have to pay for the machine. The results of the videotaping were the property of John Gruber.

There are plenty of reasons for not accepting the challenge. They may have felt that there would be too much risk that they didn't want to accept, they may have not given a shit about John Gruber (likely), they may not have wanted to contributed to his pro-Apple site, or they may have had no interest in the lame reward offered. A macbook may be exciting to you and John Gruber but probably not to them.

Just because additional details were not provided on demand to Apple loyalists does not mean that vulnerabilities didn't exist. IMO the test configuration was chosen because it was the easiest one to demonstrate the flaw. That doesn't mean it's the only one that contains the flaw though Apple apologists have always insisted otherwise.
Re:So... by Anonymous Coward · 2006-11-12 01:57 · Score: 0

"It pissed me off at the time that so many people were jumping on the anti-anti-apple bandwagon, without knowing John's credentials."

Actually, thats why so many people jumped on him.

He knows what he's doing, but he's put out unsubstantiated bullshit in the past, and was proven wrong on those.

And then he does the same thing about the Mac, using smoke and mirrors, edited video, hidden cards, scripts running on BOTH machines (identified by a video grab) and follows it up with a Sometimes I Want To Stick A Cigarette In The Eyes Of All Those Smug Cappuccinos Drinking Mac User That Get Many More Girls Than A Nerd Like Me, Johnny Cash, I Mean Johnny Cache, I Mean John Ellch I Mean Just Because I'm A Dick, You Should Love Me, Even When I'm Full Of Shit.

It was the credentials that made everyone jump on him. He's lied before the mac incident to create a sensation, he lied during the mac incident and he'll lie again. He just happened to do so with a crowd that doesn't put up with idiots and they outed him. It doesn't matter how many times he's actually found something, you just never know with this guy.
Re:So... by tunjin · 2006-11-12 02:17 · Score: 1, Informative

i would not be so fast to claim his story false - maybe you should read through the description of this airport update: http://docs.info.apple.com/article.html?artnum=304 420
...A heap buffer overflow exists in the AirPort wireless driver's handling of scan cache updates. An attacker in local proximity may be able to trigger the overflow by injecting a maliciously-crafted frame into the wireless network. This could lead to a system crash, privilege elevation, or arbitrary code execution with system privileges. This issue affects Intel-based Mac mini, MacBook, and MacBook Pro computers equipped with wireless....
http://roman.studio78.at/
Re:So... by Anonymous Coward · 2006-11-12 03:20 · Score: 0

I wonder if John Gruber realizes he's just the kind of cunt in whose eye you'd want to stub out a cigarrette?
Re:So... by node+3 · 2006-11-12 11:00 · Score: 1

There are plenty of reasons for not accepting the challenge.
The primary reason being that they couldn't do it.

Their problem is that they made ambiguous claims, and were given many chances to clarify their claims. Specifically, do they have a working exploit that can take over a clean, up-to-date MacBook with no user-intervention other than that the AirPort card be enabled? They've never directly answered that question. NEVER. And they've been given multiple opportunities. Gruber's challenge was mean to financially/materially motivate them to put up or shut up.

A macbook may be exciting to you and John Gruber but probably not to them.
They could just return it for full value minus the restocking fee.

If they truly have an exploit, they have severely damaged their reputation by not being forthright. On the other hand, if they have no working exploit, they have more notoriety than they deserve (notoriety which would be severely damaged by being shown to be frauds). Of the two possibilities, which most closely fits with their actions?
Re:So... by dfghjk · 2006-11-12 12:20 · Score: 1

"The primary reason being that they couldn't do it."

Only they know the answer to that, not you. I figure they don't consider themselves circus animals and don't have any interest in jumping through hoops on orders from a clown like Gruber. It's also conceivable that they may have had some sort of agreement in place that restricted what they could publicly disclose.

"Their problem is that they made ambiguous claims, and were given many chances to clarify their claims."

Who gave them these chances? Anyone they concerned themselves with or respected? You think they care what a grandstander like John Gruber says?

"They've never directly answered that question."

They haven't answered a million questions. So what? Furthermore, they voiced their disrespect for Apple fanboys at the time, so what makes you think they care about the peanut gallery? You act like mac fanboys like Gruber are at the center of the universe here. They aren't.

"Gruber's challenge was mean to financially/materially motivate them to put up or shut up."

No it wasn't. Gruber's challenge was designed to gain Gruber personal exposure on an issue where he had nothing else to offer.

"They could just return it for full value minus the restocking fee."

Who knows what value they placed on the reward but it clearly wasn't enough to tempt them. When you consider that they may have profited hansomely in consulting fees (perhaps in exchange for nondisclosure) I would expect them to laugh at Gruber's pitiful offer.

"If they truly have an exploit, they have severely damaged their reputation by not being forthright."

I doubt it. Their reputations aren't related to the opinions of people like those found here. We have no idea what has really happened behind the scenes. The fact that they chose a mac to run the demo on was simply a side benefit for them. They claimed all along that many hardware configs and many OSes were vulnerable. Curious that no one but mac zealots like Gruber called them out.

"Of the two possibilities, which most closely fits with their actions?"

The one where they have an exploit seeing's how they demonstrated it. They did not demonstrate the exploit on every possible config, but so what? Curiously, Apple released updates a short time later even though they insisted they had no problem. Which is more likely, that Apple coincidently discovered very similar though unrelated issues in a code audit that just happened to take place at the time as this announcement, or that Apple found problems when they looked into this issue (with or without specific assistance) and simply lied about it to the public? I'm going with the second myself. You can delude yourself all you want.
Re:So... by node+3 · 2006-11-12 12:59 · Score: 2, Insightful

You can delude yourself all you want.
In what way am I deluding myself? In every conceivable way, the hackers in question have failed to give me any reason to believe they actually had an exploit against Apple's AirPort drivers.

Sure, it's *possible* they really had an exploit, and they just don't care if anyone believes them. But given they've not given me a reason to believe them, why on earth should I?

Even worse, they've never even made it clear EXACTLY WHAT their claim is. In other words, they've never stated, clearly, that they actually had a working exploit against Apple's AirPort drivers.

What makes you want to so strongly defend such an ambiguous claim that has such little evidence?
Re:So... by Gideon+Fubar · 2006-11-12 15:44 · Score: 1

So you'd prefer total disclosure so that someone can write a tool any kiddie can use to gain kernel mode access to your machine? Or perhaps you work for a company that has been disadvantaged by a security researcher and you'd like them to disclose so that you can sue them into the ground?

You clearly have a fine understanding of the job that is being done here.

--
http://www.xkcd.com/354/
Re:So... by masklinn · 2006-11-12 16:06 · Score: 1

Still sensitive are you?

Not really, I don't even own a laptop let alone a mac.

Nor are they obligated to. Odds are that the presentation had the desired effect and there was no need to proceed further.

So you acknowledge that it was a stunt and a lie. Good.

Gruber challenged them to hack a macbook (not two) with many stipulations. The challenge was to be videotaped and the conditioned were not under the control of the hackers.

Uh yeah? His conditions seemed pretty standard stuff it you look at it from a scientific standpoint.

Plus in a later post he offered a second macbook, because there were 2 people on the stage when the stunt was done.

If the challenge was not met, the hackers would have to pay for the machine.

Looks like a good way not to waste his time and money (remember that Gruber would've had to buy the macbook right before the try in the first place)

they may not have wanted to contributed to his pro-Apple site

How would they have "contributed", had they shut up his mouth by performing what they claimed they could?

A macbook may be exciting to you and John Gruber but probably not to them.

A standard macbooks can be refurbished for just under $1k, whatever the excitement they could get out of a macbook, $1k for about 5mn of work (if their claim were true) is not something many people can pass on like that.

[...] Apple loyalists [...]
[...] Apple apologists [...]

Dude, as I said I don't own a mac, and I never have owned one...

IMO the test configuration was chosen because it was the easiest one to demonstrate the flaw.

Yeah, let's demonstrate a flaw against an obscure configuration involving third-party stuff, because god forbid we did it against the main, default, standard configuration of the machine even though we claimed we could.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:So... by masklinn · 2006-11-12 16:12 · Score: 1

So you'd prefer total disclosure so that someone can write a tool any kiddie can use to gain kernel mode access to your machine?

Or so that the company involved can and has to update it's flawed drivers and patch the flaws.

Yes.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:So... by masklinn · 2006-11-12 16:14 · Score: 1

If their hypothetic flaw is now patched, why don't they demonstrate their attack on an unpatched macbook unless "because they didn't find a flaw in the first place"?

You know, scientific method 101 says it's not ours to disprove that they found a flaw, it's theirs to prove they found one in the first place, which they've never done.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
Re:So... by Gideon+Fubar · 2006-11-12 16:59 · Score: 1

Obviously, submitting data to the vendor is a good idea if you want the problem fixed, but there are numerous cases of vendors taking legal action against researchers who do. It may be that they felt that going public without releasing specific details would shield them from harm. The vendors can either claim that they are incorrect and that the bug doesn't exist OR they can sue. But not both.

I don't think that playing showpony for John Gruber amounts to submitting data to Apple, and i'm glad they didn't take up his (stupid, loaded) challenge.
I'm also not sure who to believe regarding the actual submission of the exploit data to Apple, since Apple mouthpieces have been quoted saying that they recieved nothing regarding the exploit, but released a security patch for a near-identical flaw in September.

--
http://www.xkcd.com/354/
Re:So... by dfghjk · 2006-11-13 01:46 · Score: 1

"If their hypothetic flaw is now patched, why don't they demonstrate their attack on an unpatched macbook unless "because they didn't find a flaw in the first place"?"

There you go proclaiming the reasons for things you don't understand. Who says they haven't demonstrated it? They just haven't demonstrated it to you.

"You know, scientific method 101 says it's not ours to disprove that they found a flaw, it's theirs to prove they found one in the first place, which they've never done."

The scientific method says nothing of the sort. I makes no comment on what blowhards like you should or shouldn't do.
Re:So... by dfghjk · 2006-11-13 02:04 · Score: 1

"So you acknowledge that it was a stunt and a lie. Good."

I acknowledge that what you just said was a stunt and a lie.

"Uh yeah? His conditions seemed pretty standard stuff it you look at it from a scientific standpoint."

Sure, videotaping and having the camera controlled by john gruber is part of the scientific standpoint. I'm sure that offered plenty of encouragement. Offering a measly reward worth, at best, a small fraction of what they could have gotten from Apple, was part of the scientific standpoint as well.

"How would they have "contributed", had they shut up his mouth by performing what they claimed they could?"

By increasing its exposure leading up to the event. Are you really that stupid?

"A standard macbooks can be refurbished for just under $1k, whatever the excitement they could get out of a macbook, $1k for about 5mn of work (if their claim were true) is not something many people can pass on like that."

You have no idea how much work it would take or how long it would take, but it's certain that it would take longer than 5 minutes when you consider the hour or two minimum it would take waiting on the production crew. Furthermore, that thousand dollars doesn't mean much if it means the sacrifice of a $100K contract they may have had with someone else that included a non-disclosure. It's clear that you can't understand such complicated concepts.

"Dude, as I said I don't own a mac, and I never have owned one..."

So you said.

"Yeah, let's demonstrate a flaw against an obscure configuration involving third-party stuff, because god forbid we did it against the main, default, standard configuration of the machine even though we claimed we could."

Unless, of course, they'd already done that and been paid for their consulting work in exchange for an agreement not to demonstrate that configuration.

The fact is that you have no idea what actually went on behind the scenes but that doesn't stop you from declaring them as frauds. Just who is the liar here?
Re:So... by dfghjk · 2006-11-13 02:12 · Score: 1

"In every conceivable way, the hackers in question have failed to give me any reason to believe they actually had an exploit against Apple's AirPort drivers."

In every conceivable way? The fact that they demonstrated the flaw and said it existed in many configurations including Apple's isn't conceivable to you? You live in a fantasy land where Apple can do no wrong.

"But given they've not given me a reason to believe them, why on earth should I?"

They did give you a reason to believe them but you chose do deny it. The fact is that they really don't care whether you believe them or not.

"Even worse, they've never even made it clear EXACTLY WHAT their claim is. In other words, they've never stated, clearly, that they actually had a working exploit against Apple's AirPort drivers."

Never made it clear to you perhaps. Funny that Apple released updates shortly after their demonstation however.

"What makes you want to so strongly defend such an ambiguous claim that has such little evidence?"

I don't. I argue against the groundless attacks levied by people like you. I have no idea what really went on besides what they said and did publicly and what I observed afterward. Unlike you, I keep an open mind as to what they said. What possible purpose would they have in saying things that were untrue?
Re:So... by dfghjk · 2006-11-13 02:17 · Score: 1

Who says they didn't? Full *public* disclosure isn't necessary for that. Considering that Apple did, in fact, update their products shortly afterward suggests that there was sufficient disclosure for that to happen.
Re:So... by dfghjk · 2006-11-13 02:22 · Score: 1

John Gruber is a grandstander who attempted to turn the spotlight onto him. His offer couldn't possibly match what the researchers hoped to gain (and most certainly did gain) through consulting on the issue. There were reasons why the researchers presented the flaw and chief among then certainly wasn't to increase attention for an Apple cheerleader's blog. Odds are that they wanted to get paid (and I don't mean with a single MacBook).
Re:So... by node+3 · 2006-11-13 07:52 · Score: 1

"What makes you want to so strongly defend such an ambiguous claim that has such little evidence?"

I don't.
Yes, you do. You're doing it right now.

You live in a fantasy land where Apple can do no wrong.
Straw man, I've stated nothing of the kind.

Funny that Apple released updates shortly after their demonstation however.
Gee, with all the attention on the drivers, funny that Apple would go through and look at them! However, the update *DOESN'T ADDRESS THE SAME ISSUE IN QUESTION*. Funny that doesn't seem to matter to you.

The two hackers have not shown a *single piece* of evidence that they hacked the Apple drivers. All they've done is hacked a third-party driver, and implied their hack would work on Apple's drivers. There's absolutely no reason someone should believe them. They have *NO* credibility.
Re:So... by dfghjk · 2006-11-13 08:40 · Score: 1

"Yes, you do. You're doing it right now."

I have not. All I've done is consistently counter the claims by you and others that the researchers were frauds who failed to support the claims of flaws on the mac platform. I've never defended them other than to support that that could have been right and I've offered reasons to explain non-response to public criticism. It is you that is making indefensible claims here, not me. I have no position one way or another on their claims other than I take them at face value. No one has given me reason to believe that they were motivated to lie and I don't assume that they did.

"Straw man, I've stated nothing of the kind."

No, but you've demonstrated it through meritless attacks.

"Gee, with all the attention on the drivers, funny that Apple would go through and look at them! However, the update *DOESN'T ADDRESS THE SAME ISSUE IN QUESTION*. Funny that doesn't seem to matter to you."

That's certainly what Apple said though the description of some of the fixes looked suspiciously familiar. Since we don't know for certain exactly what the vulnerability was (or as you might put it, what the lie perpetrated by the frauds claimed to be) Apple will have plausible deniability at least to the public. At least you recognize that public attention likely caused Apple to review the code in question and issue an update. You would think that an open-minded person might see that as legitimizing the researchers' claims. Instead, you would take Apple's statement at face value while calling the reseachers liars. If anyone doesn't know you to be a fanboy, I can't imagine how they don't get it now.

"There's absolutely no reason someone should believe them. They have *NO* credibility."

And that's where you are wrong. They demonstrated a vulnerability and said that the problem was not solely limited to one hardware or software platform. Events that followed (software updates from vendors) lended further credibility to their claim. Only people in denial, such as you, see it otherwise.

It's interesting to note that Windows was also identified as being vulnerable yet no one has ever claimed that the researchers were liars for having claimed that and not offered proof. Since you claim to not be a mac fanboy, why aren't you outraged over that crime?

But which OS!? by Idaho · 2006-11-11 23:31 · Score: 4, Informative

I mean, it's bad enough that people always talk about "Computer viruses" instead of "Windows viruses" and so on, but come on, can we please include *some* information in the post itself?

Admittedly, the article to which this newspost links also doesn't mention this until the third or fourth paragraph or so.

At first I thought the article was about the Linux kernel, in that case I would have wanted a (global) list of the OS's/versions affected as well, because my laptop might have been vulnerable in that case!

So, I assume it's just Windows XP SP2 (and probably older SP's), or other versions as well?

--
Every expression is true, for a given value of 'true'

Re:But which OS!? by Anonymous Coward · 2006-11-11 23:39 · Score: 2, Funny

I read the summary just a few seconds after it was posted, and you can imagine the effect it had on me to read this on a laptop using EXACTLY that card, in a wave phyiscs lecture...

Please never scare me again like this, for a moment i thought Windows was more secure than Linux...
Re:But which OS!? by Ghardak · 2006-11-12 15:34 · Score: 1

If I am not mistaken - every expression is true (see http://en.wikipedia.org/wiki/Curry's_paradox
Re:But which OS!? by cthulhu11 · 2006-11-12 22:55 · Score: 1

What's even worse is when people talk about "Windows" instead of "Microsoft Windows".

Johnny Cache by davro · 2006-11-11 23:31 · Score: 1, Funny

Quote
"Microsoft's Windows operating system is exploitable without the existence of an access point or any interaction from the user.
The card's background scan of available wireless networks triggers the flaw," the group said.
eWEEK.com Special Report: Mac Security"

The bug was first discovered by wireless security guru Jon "Johnny Cache" Ellch, the researcher who was embroiled in a controversy with Apple over similar bugs in the Wi-Fi driver that ships with the Mac OS X.

Checklist for today:

1. Eat
2. Rant on Slashdot
3. Change SSID from "omgomgomg" to "omgomgomgomgomgomgomg"
4. Wait for the muppets to connect.
5. Profit !

Kind of makes me glad I've got homeplug.. by Channard · 2006-11-11 23:35 · Score: 2, Interesting

I was tempted by wireless, but given I don't have a laptop, I grabbed a couple of these twenty quid each Homeplug devices which plug into a mains socket and send data around the house's main circuit. It not be as 'go anywhere' as Wireless, but in the light of this I guess it's more secure.

Re:Kind of makes me glad I've got homeplug.. by UncleTogie · 2006-11-11 23:56 · Score: 1

{I was tempted by wireless, but given I don't have a laptop, I grabbed a couple of these twenty quid each Homeplug devices which plug into a mains socket and send data around the house's main circuit. It not be as 'go anywhere' as Wireless, but in the light of this I guess it's more secure.}

Does your house have any external outlets? ;)

--
Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
Re:Kind of makes me glad I've got homeplug.. by inio · 2006-11-12 00:01 · Score: 1

Do you have stairs in your house?
Re:Kind of makes me glad I've got homeplug.. by Jacco+de+Leeuw · 2006-11-12 00:59 · Score: 1

I saw some powerline adapters with 56-bit DES encryption. That's not terribly secure. Your security is mostly based on the fact that the bad guys cannot plug into your mains. Which is probably good enough for home use.

--
-------
Warning: Slashdot may contain traces of nuts.
Re:Kind of makes me glad I've got homeplug.. by Psiren · 2006-11-12 01:44 · Score: 1

How do these things work on different ring mains? Given that the first floor of my house is on a different ring main (not unusual obviously) to the ground floor, how would I be able to communicate between them? The fusebox is the only place they come together. Can the RF make the jump between them?
Re:Kind of makes me glad I've got homeplug.. by Channard · 2006-11-12 02:45 · Score: 1

I've got two circuits, and it works fine. If you have two different meters it won't work, but I can turn my upstairs circuit and downstairs circuit off separately and there's no problem there.
Re:Kind of makes me glad I've got homeplug.. by Svartalf · 2006-11-12 03:36 · Score: 1

In fact, I do. But relying on HomePlug to "protect you" much better than WiFi
is a little bit of folly. No, you can't have the article's attack made on you.
But as the parent poster has pointed out, you're not as protected as you think-
someone can snoop in on your traffic if they've got their own home plug and can
tap into either phase of the two-phase 220v circuit comng into your house.
With clever enough hardware they wouldn't even need to do that- it emits enough
RF-like signal...

Fixed wiring Ethernet is probably the most secure of the lot- HPNA and HomePlug
suffer from people being able to tap in (in the case of HPNA, all someone has to
do is splice into your demarc- there's no barriers other than distance that protect
you from snooping/attack...). WiFi and other wireless tech...heh...

--
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Re:Kind of makes me glad I've got homeplug.. by Svartalf · 2006-11-12 03:40 · Score: 1

Fusebox is one place. Power meter's the other. I suspect that most PLC implementations
for home have relied on the meter to handle the cross-over between phases, etc. If you've
got two meters, I suspect you'd need a bridge of some type like the X10 booster bridge for
homes to bridge them all without mixing the power from each feed.

--
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Re:Kind of makes me glad I've got homeplug.. by Psiren · 2006-11-12 04:03 · Score: 1

Good point, hadn't thought about the meter. Thanks :)
Re:Kind of makes me glad I've got homeplug.. by Lorkki · 2006-11-12 12:35 · Score: 1

Fixed wiring Ethernet is probably the most secure of the lot- HPNA and HomePlug suffer from people being able to tap in

Meh. If you're worried about someone having the resources and motivation to tap into your wired network, you might as well go straight for fibre optics. Putting switching and routing equipment behind locked doors and in places that are rigged to alarm you when anyone goes in might be a good idea too.

For your basic home networking, just putting the WLAN AP outside the firewall will do plenty.

What about those phone-home laptops? by IchBinEinPenguin · 2006-11-11 23:36 · Score: 1

You know, the ones that supposedly 'home home' using any available channel in case they're stolen.
The feature is supposed to be impossible to turn off (for obvious reasons).

How long before someone finds a bug ion one of those? Won't that be fun, a vulnerability you cannot turn off :-)

Broadcom neglegance by Anonymous Coward · 2006-11-11 23:36 · Score: 2, Insightful

They either 1) dont run static analysers or 2) run them but punted the bug

Which is it Broadcom? Either way it is neglegance. Im tired of developers spouting hot air about being Accountable, Responsible and Reliable etc blah blah and especially practicing good engineering and hearing design patterns yawn. I hear it every day, I worked as a dev and left it as its the same old shit every day day in day out, same for test.

We have tools, run them, we have practices, use them.

If those are not good enough, retool and reorg.

Oh wait, its business not engineering, sorry my bad :)

Engineering is a blue collar job today, it should not be called "science" it is not science. Wise up.

Re:Broadcom neglegance by Anonymous Coward · 2006-11-12 00:25 · Score: 1, Insightful

They probably don't even Thread Model their products or run injectors and fuzzers.

More fool them. Its pure and simply, bad engineering, product design and management.

Re:NDISWrapper by Anonymous Coward · 2006-11-11 23:38 · Score: 3, Informative

Don't forget about people using NDISWrapper, which is the only way to get such cards working on Linux at all unless someone has written a driver recently.

well that was expected? by tunjin · 2006-11-11 23:43 · Score: 0

why should apple be the only manufacturer who bought buggy drivers ;)

http://roman.studio78.at/

Ndiswrapper? by Anonymous Coward · 2006-11-11 23:48 · Score: 0

Are you using Ndiswrapper? If so, you are using the Windows driver, and your machine may still be vulnerable, although it's likely that attacks designed to work against Windows will just crash your machine.

Dammit, why is it so hard to write secure Wi-fi drivers?

Linux by utopicillusion · 2006-11-11 23:59 · Score: 1

Does my "reverse engineered" linux driver have this bug. I guess not. Why is it that a bunch of people who don't get paid come up with bug-free solutions? I guess, either they love their job very very much, or its just the development philosophy or both :)

Re:Linux by cheater512 · 2006-11-12 00:14 · Score: 1

Well they are doing it for free and in their spare time so I think they would actually *care* about it.
Plus they are generally better than the Broadcom devs because they dont have the chip manual infront of them while they are writing the driver.
Re:Linux by Anonymous Coward · 2006-11-12 00:17 · Score: 0

Plus they are generally better than the Broadcom devs because they dont have the chip manual infront of them while they are writing the driver.
How does that help to write better code? Am I missing something? Wouldn't they write even better code if they had the manuals and doesn't that contradict your statement?
Re:Linux by Proud+like+a+god · 2006-11-12 00:33 · Score: 1

Less assumptions made about how the thing works? Trial and error should still find the rare conditions that might be stated in such a manual, and also find those that are not.
Re:Linux by oesj · 2006-11-12 01:24 · Score: 1

...or people spend(waste) less time looking for their bugs?
Re:Linux by Anonymous Coward · 2006-11-12 01:53 · Score: 0

I don't get it. How can it possibly be better to have a blackbox device and no documentation than a blackbox device and the vendor's idea of its operation? If the thing has bugs you will find them faster by comparing its operation to the docs.

Without docs you have nothing but poking around in the dark. With the docs you have at least a basic idea.

I'm all for hacker's curiosity and discovering things, but that doesn't mean there will be cleaner and more robust code as a result. The best drivers come from hackers who have proper docs.
Re:Linux by Anonymous Coward · 2006-11-12 04:44 · Score: 0

I think the gp is right. By using trial and error, the devs have an intimate understanding of exactly what is going on in the HW. The broadcom folks, however, just hired some guy for $10/hr out of community college, gave him some docs and held his hand through the tough part. You've never dissassembled something, have you?
Re:Linux by Anonymous Coward · 2006-11-12 05:59 · Score: 0

Yes, your linux system with reverse engineered bcm43xx driver seems to be vulnerable.

If I understand correctly, the bug is in firmware, not in OS driver itself. Your reverse
engineered linux driver still needs the firmware from bcm*.fw files in /lib/firmware
directories.

Of course I might be wrong, didn't really RTFM.

Re:NDISWrapper by cheater512 · 2006-11-12 00:10 · Score: 2, Interesting

I think I've seen the driver in the list.
Dont quote me. I dont have a Broadcom wireless.

Anyway the flaw wouldnt affect Linux systems. Why? Different kernel.

User space device drivers by camcorder · 2006-11-12 00:14 · Score: 4, Insightful

There's a discussion about having user space device drivers for usb wireless sticks and some other drivers as well for linux kernel. I hope this kind of attack vectors encourage kernel developers to go in this way. Keeping stuff in user space as much as it allows would again let Linux to be secure-by-design once again. Currently couple of tools (like wpa_supplicant) running in user space, and I wonder their situation in Windows kernel. If they are not (which I guess they are not -because microsoft is known to be putting huge code into kernel level) then that's a huge problem from security perspective.

Re:User space device drivers by TCM · 2006-11-12 01:32 · Score: 1

Congratulations, you just reinvented microkernels (poorly).

--
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
Re:User space device drivers by Anonymous Coward · 2006-11-12 02:09 · Score: 0

Congratulations, you just reinvented microkernels (poorly).

Why poorly, he pretty much described the basic thought behind microkernels. It's not his fault that microkernel implementations have sucked...

(Yeah I know you were just making a riff on Spencer quote - but you gave me a good feed line to dig at microkernels)
Re:User space device drivers by Anonymous Coward · 2006-11-12 13:32 · Score: 0

No he didn't. Microkernels suck, and they have sucked despite years of intense research too.
Monolithic as many drivers as possible in user space is compromise to get most of the security benefits of microkernels without the suckage. So fuck you.

Is this related to the by porkchop_d_clown · 2006-11-12 00:24 · Score: 0, Redundant

allegedly mythical (No it's not!) (Yes it is!) (No it's not!) Airport exploit for Macs?

I still haven't been able to figure out if they've demonstrated a real vulnerability or not...

--
Clear, Dark Skies

Re:Is this related to the by camperslo · 2006-11-12 01:51 · Score: 0

allegedly mythical (No it's not!) (Yes it is!) (No it's not!) Airport exploit for Macs?

I believe there is a strong possibility it is related. I've used a third-party wireless card with a Broadcom chipset in G3/G4 Macs before, and it was recognized as an Airport Extreme (b/g) card.

I've heard that Broadcom has been less than cooperative in providing specs for others to write drivers. Perhaps if they were more open they'd have a better scrutinized more secure product. (I can't provide specific links, but I believe my information about Broadcom chipsets came from discussions of supporting them in past versions of the wireless utility Kismac)

Re:NDISWrapper by ettlz · 2006-11-12 00:26 · Score: 5, Informative

Broadcom users on Linux should really be using the bcm43xx kernel module by now.

Anyway the flaw wouldnt affect Linux systems. Why? Different kernel.

NDISWrapper executes the Windows Kernel Mode NDIS driver in the Linux kernel's address space. So it might still result in code injection. It might even extend to FreeBSD when running bcmwl5.sys under its equivalent as well.

Re:NDISWrapper by Carewolf · 2006-11-12 00:27 · Score: 2, Interesting

There is such a driver in the most recent Linux kernels, but it still uses firmware extracted from Broadcom Windows drivers. So if the bug is in the firmware, it could even affect broadcom native linux drivers.

"BCMWL5.SYS" by The+Creator · 2006-11-12 00:27 · Score: 4, Funny

This is slashdot, you are supposed to guess the OS from the filename of the device driver.

--

FRA: STFU GTFO

Re:"BCMWL5.SYS" by Wonko+the+Sane · 2006-11-12 01:39 · Score: 2, Interesting

The bcm43xx driver included in the kernel can not function without the firmware contained within bcmwl5.sys. So there isn't any way to determine (from this particular article) if the bug affects linux or not.
Re:"BCMWL5.SYS" by mjg59 · 2006-11-12 05:28 · Score: 1

If the bug's in the firmware, it would be very difficult to exploit it to run code in the kernel. Not impossible, but very difficult. The description of the bug makes it sound extremely like the problem is in the driver, not the firmware.
Re:"BCMWL5.SYS" by Anonymous Coward · 2006-11-12 11:14 · Score: 0

... DOS?

More details at... by Wanker · 2006-11-12 00:41 · Score: 5, Informative

SANS has a concise summary:

http://isc.sans.org/diary.php?storyid=1845&isc=2e0 1b45094b0425b829255e39eb2f8d2

Or look at the Month of Kernel Bugs site itself:

http://projects.info-pull.com/mokb/MOKB-11-11-2006 .html

Separate stack by QuickFox · 2006-11-12 00:55 · Score: 1

Why do compilers put buffers on the subroutine-and-return stack? Why not have the compiler use a separate stack for composite data such as buffers, arrays, variable-size data, and all similar stuff, whenever the programmer puts such data on the stack? Wouldn't that stop stack-based code injection?

The added cost in processing time should be quite negligile, as long as simple, fixed-size data, such as integers, are still on the main stack.

--
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.

Re:Separate stack by miu · 2006-11-12 02:15 · Score: 1

This would make variable argument lists a real nightmare, this wouldn't just be a fire and forget change to the compiler.

--

[Set Cain on fire and steal his lute.]
Re:Separate stack by QuickFox · 2006-11-12 03:11 · Score: 1

Where's the complication? If you define simple, clear rules about what goes where, this has the same complexity as keeping track of the sizes of integers, floats etc, something compilers do all the time.

Depending on various considerations you might define, for example, that integers, floats, chars, booleans and pointers go on the main stack, along with all data types that have been defined to be implemented as these types. Everything else goes on the second stack. Thus, for example, all arrays go on the second stack, regardless of element type.

Then just stick to this rule everywhere, just like you stick to the rules about the sizes of integers, floats etc.

Of course it's not a matter of just writing a couple of lines and forgetting it. Much more work than that would be needed. But considering the huge amount of work spent on guarding against code injection, and the huge costs when code injection does occur, it seems worth the effort.

--
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.
Re:Separate stack by Anonymous Coward · 2006-11-12 03:37 · Score: 0

Where's the complication? If you define simple, clear rules about what goes where, this has the same complexity as keeping track of the sizes of integers, floats etc, something compilers do all the time.

This data is actually defined by the application-binary interface (ABI), not the compiler. In order for a program to use a shared library, both must use the same ABI. This allows you to use a library compiled with (say) gcc 3.4, with a program compiled with gcc 4.0.

The ABI also defines the rules for passing arguments. You cannot change any of these rules without also changing the ABI. If you do that, you'll have to recompile all the shared libraries and all the applications on your system, as all existing binaries will not work.
Re:Separate stack by QuickFox · 2006-11-12 05:18 · Score: 1

The second stack could be a special part of the heap space. What I mean here is the space where you get memory when you issue memory-allocation calls.

There would be a special part of heap space that would grow and shrink as a stack. This special area could be very similar to the ordinary heap, with the difference that allocation and deallocation is very much faster, since it grows and shrinks as a stack.

With this arrangement, dynamically linked modules don't necessarily need to be aware of the second stack. They can see the data as any other data on the heap.

Very often arrays are passed by reference, by a pointer to the data. Presumably the pointer is fixed-size, even if the data isn't. Then the pointer is suitable to be passed on the main stack.

This will not work in cases where an array is passed by value rather than by pointer, so that the function expects to find the elements of the array at a known and predefined place on the main stack. Isn't this unusual? If this happens at all, but is unusual, then you could treat this as an exception, putting the value on the stack in this particular case. You should still see great gains in security.

--
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.
Re:Separate stack by TheRaven64 · 2006-11-12 06:04 · Score: 1

Dovecot, the POP/IMAP server developed by one of the OpenBSD guys, uses this kind of system. At the library level, it has a separate data stack. Allocations on the data stack are cheap (because you just increment a pointer, rather than doing messy things with the heap), and the data stack can be pushed and popped independently of the control stack. This has some nice features like a sprintf analogue that allocates its own space on the data stack, but then doesn't pop it on return, so you don't need to worry about buffer lengths.
SPARC also does something like this, by providing register windows. The return value is stored in a specific register, so it can't be over-written by anything on the stack, and when you jump to the next function you get a new set of registers.

--
I am TheRaven on Soylent News
Re:Separate stack by Anonymous Coward · 2006-11-12 07:16 · Score: 0

Ok, so the new stack is really only used within a function, not for passing arguments. That'll work - you could certainly achieve that just by modifying the compiler, without breaking binary compatibility. With a bit of cleverness you could even do it without modifying the compiler at all: you could add macros for scope entry, scope exit and variable declaration. Cool.

Whether the new system would be much more secure, I don't know. Stack-smashing attacks are not the only sort of exploit. Certainly, other measures like making the stack segment non-executable don't prevent attacks.
Re:Separate stack by QuickFox · 2006-11-12 07:27 · Score: 1

Stack-smashing attacks are not the only sort of exploit.

Indeed. But I think that, among those exploits that have really severe consequences, this is one of the most frequent.

--
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.

Workaround for non-Linksys devices by Jacco+de+Leeuw · 2006-11-12 00:56 · Score: 5, Informative

George Ou at ZDNet has published a procedure on how to use the Linksys drivers with devices from other vendors such as Dell and HP. Of course this is not an ideal solution but if it works it's better than nothing.

--
-------
Warning: Slashdot may contain traces of nuts.

Re:Workaround for non-Linksys devices by kahunak · 2006-11-12 04:02 · Score: 1

You can also replace the bcmwl5.sys file, usually located at C:\WINDOWS\SYSTEM32\DRIVERS with the one provided by linksys, just download linksys drivers from here , extract them, disable your network adapter, copy the new bcmwl5.sys (make a backup of your own bcmwl5.sys just in case...) and activate the card again. It is a temporary solution but it's better than nothing and you don't change the name of your network card. Tested on a Dell MiniPCI 1300 WLAN and it works.
Re:Workaround for non-Linksys devices by enosys · 2006-11-12 05:21 · Score: 1

I just did this for my "Dell Wireless 1500 Draft 802.11n WLAN Mini-Card" and it works. The old driver was 4.80.28.5. It still says the version is that but if I go to driver details in device manager I see the file is 4.100.15.5.
Re:Workaround for non-Linksys devices by Zwaxy · 2006-11-13 07:45 · Score: 1

Are you sure that disabling the device and re-enabling it is enough to get Windows to use the replaced .sys file? I replaced the .sys file and did as you suggested, but upon rebooting, the new .sys file doesn't have its "last accessed" date updated, and the device manage still shows the old version of the driver as being active.

Other than downloading the exploit and trying it on out, is there any way to know for sure whether I'm now running the fixed version of the driver?
Re:Workaround for non-Linksys devices by Zwaxy · 2006-11-13 07:54 · Score: 1

Never mind, I ended up following the steps described in http://blogs.zdnet.com/Ou/?p=365 and that seems to have worked.

Re:NDISWrapper by Mathinker · 2006-11-12 00:58 · Score: 1

> Broadcom users on Linux should really be using the bcm43xx kernel module by now.

Out of the table of ten global "chip family id's" listed here, only 3 are currently listed as supported, the others are at best "unstable".

And personally, I didn't manage to get a BCM4318 "Air Force One"-based card (no, I didn't buy it, it was "inherited") working with the native module (Ubuntu Dapper). Sigh. Guess it's time to fish out the long cables until the Windows drivers get patched.

Will this help? by leehwtsohg · 2006-11-12 01:20 · Score: 1

It seems that the user who controls the wireless card will have access to the wireless card, and thus in this case you could potentially have a wireless virus.

In some cases it could be that the user would have access to all network cards, which would mean that from a virus/spam sending/worm point of view the computer will be usefull to the hacker, even if it is otherwise secure.

Maybe keyloggers will be prevented, and writing to the disc, i.e. malware surviving the next reboot. But in general it seems to me that in this case not much is gained from moving the driver to user space.

Re:Will this help? by Anonymous Coward · 2006-11-12 02:03 · Score: 0

Maybe keyloggers will be prevented, and writing to the disc, i.e. malware surviving the next reboot. But in general it seems to me that in this case not much is gained from moving the driver to user space. It really does help. Imagine that the wireless driver is a daemon, like sendmail, bind or Apache. Those daemons run as 'nobody' or a special low-privelege user on any sensibly configured system. They don't need root (or kernel access), so they don't have it. If someone manages to get sendmail to run arbitrary code, then they do have access to the network and they can (at least) run their own service on the sendmail port. But they don't get to corrupt other parts of the system (unless they can do so by using another exploit). The number of security problems that have appeared in wireless drivers recently is a good indicator that they should be running in user space. For some reason, it appears to be hard to write a secure wireless driver, so the potential damage of a security breach should be limited as far as possible.
Re:Will this help? by enosys · 2006-11-12 05:18 · Score: 2, Insightful

I'm not sure it's especially hard to write a secure wireless driver. It's more probable that they just didn't think very much about security when writing drivers.

bcm43xx by Jack+Malmostoso · 2006-11-12 01:21 · Score: 1

How does this affect the native bcm43xx linux driver, since the original firmware is used?
Thanks for any explanation.

Re:bcm43xx by Svartalf · 2006-11-12 03:42 · Score: 1

Probably at least a DoS attack will be possible since the vector of attack is through
the firmware layer for the device.

--
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas

Yawn by dangitman · 2006-11-12 01:32 · Score: 0, Flamebait

I guess "Johnny Cache" got tired of trolling for media coverage about his non-existent MacOS wireless exploit, and decided to publish the less sensational information about the OS and systems that it actually affects. So, instead of being a big bad boy who rocks the world by pwning Macs, it's just one more of thousands of boring Windows exploits.

By the way, what is this guy's name? I've seen it published as "Erlich" and "Elich" before, and now slashdot says it's Ellch. One thing's for certain. Anybody who calls themself "Johnny Cache" must be a total dick.

--
... and then they built the supercollider.

Please stop using C. by master_p · 2006-11-12 02:22 · Score: 1

C is the source of all these problems. Please stop using it.

(and please I do not want to hear 'but Linux is so safe', because it is not).

Link to previous post:

http://it.slashdot.org/comments.pl?sid=204783&cid= 16723899

Re:Please stop using C. by FireFury03 · 2006-11-12 03:21 · Score: 5, Insightful

C is the source of all these problems. Please stop using it.

It's not that simple. C is used in high performance code specifically because it's fast and compact. You get these improvements by avoiding needless length checking. Obviously there are cases where you _do_ need to length check buffers (and exploits are the result of not doing this), but you don't have to length check everything. If you ditch C in favour of a language that does the length checking for you then you will sacrifice speed and compactness since it will be checking _everything_.

What language would you suggest is more suitable for writing high performance kernel code?

--
http://blog.nexusuk.org
Re:Please stop using C. by Anonymous Coward · 2006-11-12 03:21 · Score: 0

cars are involved in 100% of car crashes. please stop driving cars.

C is a tool. used well, its fine. used stupidly, it could be dangerous.

i think it would be more important to require financial responsibility to anyone who sells you code that allows your system to be compromised. i think that would be more affective than switching languages. code needs to be more like other commercial products, when the vendor screws up, there needs to be a real, financial burden placed on them.
Re:Please stop using C. by Anonymous Coward · 2006-11-12 03:32 · Score: 0

"C is the source of all these problems. Please stop using it."

==

"Computers are the source of all these problems. Please stop using them. . ."
Re:Please stop using C. by Anonymous Coward · 2006-11-12 03:41 · Score: 0

C is the source of all these problems. Please stop using it.

All right please keep your _BFM_ shut !!.
Re:Please stop using C. by Anonymous Coward · 2006-11-12 05:08 · Score: 0

You raise a good point - when it's time for hi-performance code, it's worth trading off safety for speed. And since this code is probably going to be carefully reviewed for every spare ounce of performance, it's less likely that stupid mistakes will live through anyway. However, I don't think a wireless driver falls into this category.

For the record, have you checked ou Cyclone?
Re:Please stop using C. by ettlz · 2006-11-12 05:15 · Score: 1

C is the source of all these problems. Please stop using it.
I'd like to see you try this out on the OpenBSD mailing list.
Re:Please stop using C. by romiz · 2006-11-12 05:44 · Score: 1

If you ditch C in favour of a language that does the length checking for you then you will sacrifice speed and compactness since it will be checking _everything_.

It should be possible to have both, and some languages have been designed with this in mind. It is the case for Ada, where string manipulation includes bound checking in the language by default, but it is possible to remove the related verifications with compilation options.

But then, the security trade off is still present - you have to choose which code is optimized, and which code is secure. But hopefully, this should at least avoid implementation bugs in the secure code.
Re:Please stop using C. by Viol8 · 2006-11-12 07:11 · Score: 1

"However, I don't think a wireless driver falls into this category."

So you don't think data throughput speed is important then?
Re:Please stop using C. by AVonGauss · 2006-11-12 09:09 · Score: 1

You are right about Linux (or Mac OS X) - it has the same concerns as Windows, maybe just different symptoms. However, stop using 'C' to write code? I am assuming that you are saying that another programming language should be used instead - just out of curiosity, you do realize that most other languages are written in C, right? On a different note, the article is pure sensationalism - they are saying that they can use a long SSID to "take control" of another computer - to use a technical term, that's bullshit. At best, you are going to cause the other machine with the affected driver to crash (or in the Windows world, BSOD). You are not going to start copying files from another machine or magically take control of the remote machine's console. Common sense is a lost art...
Re:Please stop using C. by Anonymous Coward · 2006-11-12 09:22 · Score: 0

If you ditch C in favour of a language that does the length checking for you then you will sacrifice speed and compactness since it will be checking _everything_.

You're underestimating the power of static analysis. Array bounds checks can be elided where it can be proven that they will not be overrun. (And it could be the user's choice whether other cases are marked as warning, errors, or checked at runtime.) Here's a trivial (and common) example that would not even require language changes:
bucket_t *hashtable[HASHENTS]; ... for (int i = 0; i < HASHENTS; i++) { bucket_t *bucket = hashtable[i]; ... }
The sort of static checker that is now becoming popular can prove that "hashtable[i]" will always be valid. If the "i < HASHENTS" were changed to "i <= HASHENTS", these checkers would note the mistake.

Unfortunately, it is not as easy to detect this when the array is dynamically-sized. The most practical way seems to be a modification of the language.

What language would you suggest is more suitable for writing high performance kernel code?

I know of no existing suitable language. That does not mean it is impossible to create one.
Re:Please stop using C. by master_p · 2006-11-12 23:42 · Score: 1

I do not see how bounds checking can really affect performance of a Wi-Fi driver. It is not that we are talking about something that getting 0.1% speedup is crucial.

But since you asked, there are two solutions:

1) use Cyclone. It outputs C code anyway, and the language provides enough mechanisms to identify where it does not need to do bounds checking.

2) use Ada. It also outputs C code, and its range types are a good solution to the problem.

3) use C++ as C on steroids: simple template value classes for arrays that can do bounds checking where it is needed. C++ can also output C code.

Re:Please stop using C. - Duh by mustafap · 2006-11-12 03:23 · Score: 1

>C is the source of all these problems. Please stop using it.

Thats like saying guns kill people.

Stupid people are the problem, not the tools.

--
Open Source Drum Kit, LPLC deve board - mjhdesigns.com

Re:NDISWrapper by flydpnkrtn · 2006-11-12 03:30 · Score: 1

The FreeBSD equivalent of NDISwrapper is "Project Evil" if anyone's wondering...

--
Here's to the crazy ones

What about ndiswrapper and bcm43xx kernel driver? by kahunak · 2006-11-12 03:46 · Score: 1

Are they affected? Ndiswrapper directly uses routines from BCMWL5.SYS so I suppose it is also affected and the bcm43xx module needs the firmware from it so maybe it is also affected. Any idea??

It has to be said... by Anonymous Coward · 2006-11-12 03:57 · Score: 2, Insightful

As the number of cases of these driver-flaw attacks mounts, I think it is fair to say the OpenBSD stance on proprietary driver 'blobs' has been fully vindicated. When they took this stance, a fair number of Slashdot posters were publically knocking them as unrealistic-paranoid-idealists. Well here you have it -- deep-fried crow ... yum.

Re:It has to be said... by dmaynor · 2006-11-12 09:39 · Score: 1

This wasn't in the blob, its in the actual driver code.
Re:It has to be said... by Andy+Dodd · 2006-11-13 03:26 · Score: 1

Where are my mod points when I need them.

With the exception of the Atheros HAL (which, while semi-closed, has a decent number of people outside of Atheros looking at it - Most of the Atheros HAL ports are done by non-Atheros volunteers who have signed NDAs for the source), pretty much all other binary "blobs" only execute on the card itself. Whether the blob has a bug or not, as long as the code interfacing with the card that runs as part of the OS kernel itself is open-source and secure, a firmware blob that runs on the card itself cannot cause a host machine compromise.

Remember here that I am talking about binary firmware "blobs" and not the complete driver solution (which usually involves firmware on the card combined with kernel code in the host OS). As long as the host OS portion is open source and properly written, one should be immune from host machine compromise.

--
retrorocket.o not found, launch anyway?

It's a design decision... by Svartalf · 2006-11-12 04:00 · Score: 1

In reality, C's behavior (and a lot of other languages, really) are governed by behaviors within the CPU hardware
they were originally intended for. In the case of C, the machines in question only had one hardware stack, so they
intermingled the subroutine return state with the parameters, etc. for speed's sake. Implementing a second stack
in software would have been problematic because it would have added extra performance issues and ate into the
register store (you want to probably reserve a register for the parameter pointer...). Since most of the Algol derived
languages (C's in that bunch...) do this very thing, there's been no need, no desire to change the underlying machine
that the language sees, nor has any of the X86 vendors had a reason to "fix" the problem of register store space.

While it's syntax is difficult to initially grasp (esp. if you've been doing Algol based languages...), Forth's
machine model is one like you suggested. Obviously, on machines that it has the ability to execute operations
against the contents of the artificial data stack or where it actually HAS two data stacks, the code excels in
speed. Comparable to C or better than C without as many of the risks (though it WILL cut your throat in other
ways- just not that one...). Otherwise, while it makes for very compact code, it does so at the expense of some
performance on machines without such support. In those cases, it's best is just at C's peak performance on the
same task and something like 10-20% slower otherwise. It's still around because it can fit a high-level
programming solution into the smallest space in memory possible without overly sacrificing speed at the same
time- obviously a good thing in an embedded system.

In the end, it's more about how careful you code things. Internally, when you know what's going to be passed in
and can control things, it's probably "okay" to not check for potential buffer overruns. It's not okay otherwise.
Because it's a major performance hit, I know why someone would be inclined to not do any checks or to overdo
the avoidance of doing them- it doesn't make it right, but I understand the why behind it and the problem in question.

--
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas

Re:It's a design decision... by QuickFox · 2006-11-12 05:41 · Score: 1

Do modern processors have such a small number of registers? I haven't looked at processors for quite a while, the last processor I knew well was the Motorola 68000. That one had eight address registers and eight data registers. In that one you could easily have spared one address register for a second data stack. Do modern x86 processors have so much fewer suitable registers?

(I wish the PC had been based on the MC68000 architecture, it was so much better in so many ways!)

--
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.
Re:It's a design decision... by hughk · 2006-11-12 10:08 · Score: 1

If memory serves me right, C first came about on a PDP-11. You had a program counter, PC or R7, the main stack, SP or R6. You also had five other general purpose registers (but you could do arithmetic on R6 and R7 as well), and the instruction set being nicely orthogonal, although the return address always went on the stack, any register could be used as the argument list pointer. Note that towards the end of life, the later 11s even implemented seperate I and D spaces which made it impossible to stick code on the stack and force its execution. The killer for multiple stacks though was the limited address space, 64K per process.
The thing is that although C primitives mapped onto the PDP-11 instruction set very well, C was designed as a system programming language, so it was intentionally quite lean.

--
See my journal, I write things there
Re:It's a design decision... by niteice · 2006-11-12 13:08 · Score: 1

x86 basically has 8 general-purpose registers (though it probably isn't possible to use all of them at once). AMD had the brilliant foresight, however, to add 8 more registers for long mode.

--
ROMANES EUNT DOMUS
Re:It's a design decision... by Douglas+Goodall · 2006-11-12 15:53 · Score: 1

Its not about the hardware architecture. It is about the binary compatiblity standard that is used to define how objects and executables work so that unix programs, for instance, can run on different versions of Linux (with a little luck). It also has to do with creating a run time envoronment that allows debuggers to operate. Automatic variables (on the stack) are a clever was to create short term allocations for temporary use (like within the scope of a routine. C++ uses this extensively when you instantiate classes instead of using "new". I admit that code nees to be written with security in mind. But Microsoft's Trusted Computing solution is not the answer.

What, no snarky comment... by Anonymous Coward · 2006-11-12 04:00 · Score: 0

...about wanting to jab a lit cigarette into the eye of all those HP, Dell, Gateway, and eMachines users? Are you feeling okay, John?

Oh, right... they're not smug about having secure systems-- they're accustomed to desperately applying patches, like a guy in a leaky life raft.

If anything, this demonstrates that OS X really is more secure than Windows: Why?
Exploiting wireless bug on OS X machine: you can cause a kernel panic and force the user to reboot.
Exploiting wireless bug on Windows machine: total pwnage of Windows machine.

Re:What, no snarky comment... by dmaynor · 2006-11-12 07:54 · Score: 1

Unless I am mistaken it was David Maynor that made the comment about the lit cigarette, not Jon Ellch. It was also David Maynor who made clear at Defcon that the reported took that comment out of context and he was refering to the characters in the commericals. It seems Apple agreed with Maynor since they just fired the Mac guy in those commericals.

buffer overflows... by hitmark · 2006-11-12 04:27 · Score: 1

why is it that these keep being the single biggest remote security problem?

--
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm

Re:buffer overflows... by Beryllium+Sphere(tm) · 2006-11-12 05:28 · Score: 1

'cause heap overflows are harder to exploit?

Are they even the biggest remote security problem these days, with cross-site scripting and SQL injection running rampant?
Re:buffer overflows... by hitmark · 2006-11-12 05:42 · Score: 1

i would say so because they hit not only web servers but potentially every computer out there thats connected to the net and running the problematic code.

--
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Re:buffer overflows... by TheRaven64 · 2006-11-12 06:13 · Score: 1

No idea. OpenBSD has been immune to most of this kind of vulnerability for ages (they can cause crashes, but not compromises). They use a variety of techniques, including a variable size gap between stack frames (making it very difficult for an attacker to put the jump in the right place) and a canary value next to the return address (so that a modified canary shows that the return value is broken).
I believe some of these changes have made their way into the main branch of GCC, although I don't think any other OS yet supports W^X protection on i386 (without hardware page-level protection).

--
I am TheRaven on Soylent News
Re:buffer overflows... by hitmark · 2006-11-12 09:10 · Score: 1

hmm, that reminds me that supposedly there is some memory address randomization stuff in vista.

and isn't there supposedly something similar in linux to?

heh, maybe i should consider going openbsd (heh, nice name for such a secure bsd).

hell, why i have yet to go linux atleast i don't know...

--
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm

This is foolish by Anonymous Coward · 2006-11-12 05:18 · Score: 0

People who use the "it's just a tool!" argument are unfathomably arrogant in this regard. Oh yeah? Guns kill people? Then why put a safety on a gun? Would you advocate for leaving a gun out at all times, or keeping it locked up someplace? Yeah, guns kill people...but it's pure idiocy to intentionally deprive oneself of safety. There are a dozen languages out there that are just as fast as C and much more secure. Security doesn't always cost speed - sometimes a language is just better designed for security over other things.

Re:Please stop using C. - Duh by Beryllium+Sphere(tm) · 2006-11-12 05:25 · Score: 1

You don't have to be stupid to screw up in C, that's the problem. The only way to be safe is to write your own string handling functions and ban all others, in which case you've changed the language: you've made it so fascist that it's not-C.

It works because it's free and it can, Re:Linux by twitter · 2006-11-12 05:35 · Score: 2, Interesting

Does my "reverse engineered" linux driver have this bug?

Probably not. If it does, it will be fixed soon.

Why is it that a bunch of people who don't get paid come up with bug-free solutions?

It gets fixed because it's free and therefore it can be. Non free software writers put up with NDA's and code they can't share even if they wanted to. Their code is owned and so their effort and good will is likewise owned. Free software writers are free to share their tools as well as their improvements, so it's much easier to help your friends.

By the way, there's no law against being paid to write free software. With all the tools available, free software writers can get the job done faster and for less money. That's something worth paying for and many people do. The vast majority of software jobs are in house, so GPL distribution conditions never take effect and are not an issue. It would be better to share the work with others if you can, but you don't have to and often can't under those circumstances and there is therefore no difference at all between your choice of tools besides the lower cost of the free tools.

--

Friends don't help friends install M$ junk.

Re:NDISWrapper by MLease · 2006-11-12 05:37 · Score: 1

Broadcom users on Linux should really be using the bcm43xx kernel module by now.

I tried (with Fedora Core 5 and 6, on my HP Pavillion zv6000 with built-in AirForce One), but after many hours of research and tinkering, I gave up and went with NDISWrapper. I did manage to get to a state where it would work for about 15-20 minutes, and then quit. If you know of a foolproof way to get the native module/driver to work, please enlighten me.

-Mike

--
I'm sorry; I don't know what I was thinking!

Puh-lease. by Inoshiro · 2006-11-12 05:57 · Score: 4, Informative

We've come a long way in the past 30 years in compiler theory and language design. We can do better than C without losing speed. Or even use a whole OS in a restricted language. You can do compile-time checking of your pointers, as Spin proves.

C is, essentially, portable assembly language. I love it -- it's one of the languages I know the best, and I continue to work in it. However, I'd love to see the use of Cyclone or special compile-time checked languages for the essentials. I think most device drivers could be easily rewritten to be bullet-proof (stack overflow) this way, and such languages are easier to do state machine analysis on (since most device drivers are simple pieces of software that control the state of the hardware). Provably correct operating system design is not a theory, but no one seems to be interested.

--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.

Re:Puh-lease. by Viol8 · 2006-11-12 07:14 · Score: 1

"Provably correct operating system design is not a theory, but no one seems to be interested."

Possibly it has something to do with formal proofs only being realistic on toy systems.
Anyone can formally prove a 1 line Hello World program will work to spec but try
to formally prove the 20 odd million lines of code in a modern OS and your descendents
will still be doing it 3 generations from now.

Zonk only uses Windows and Hates SONY by Mongoose · 2006-11-12 06:27 · Score: 1

You get it now? You have to read using the 'editor' name as context. =)

Re:NDISWrapper by Foktip · 2006-11-12 06:31 · Score: 1

The only native Broadcom drivers for Linux are for non-wireless devices (and this problem is with their wireless cards).

Someone please enlighten me... by 93+Escort+Wagon · 2006-11-12 06:48 · Score: 1

Their day one bug was an exploit of the old Apple Airport - Broadcom - wireless drivers. This day eleven exploit is of Broadcom's Windows wireless drivers. I realize the OS has changed, but is this more or less the same exploit? Or is this leveraging some issue that's actually in the chipset?

--
#DeleteChrome

Re:Someone please enlighten me... by 93+Escort+Wagon · 2006-11-12 06:53 · Score: 1

Man that's what I get for posting before I've had my coffee. The old Apple wireless was Orinoco - the newer chipset is Broadcom. Should've been blindingly obvious this is related to the Johnny Cache dog and pony show, I guess.

I'll go make a pot before I come back.

--
#DeleteChrome
Re:Someone please enlighten me... by spinja · 2006-11-12 08:01 · Score: 1

I wonder what happens if you use the new Broadcom exploit on a new Intel Mac that does not have Apple's September security update... :-)
Re:Someone please enlighten me... by wolrahnaes · 2006-11-12 12:41 · Score: 1

The cards in the Intel Macs (at least the Macbook and MBP) are Atheros, not Broadcom. IIRC the 24" iMac has a Broadcom Pre-N card, but the rest are Atheros.

--
I used to get high on life, but I developed a tolerance. Now I need something stronger.

The bcm43xx driver doesn't work by Viol8 · 2006-11-12 07:09 · Score: 1

At least not for my HP pavilion laptop. I have to use ndiswrapper.

Re:The bcm43xx driver doesn't work by Anonymous Coward · 2006-11-12 08:22 · Score: 0

the bcm43xx driver crashes my kernel every 24 hrs, more if i have loads of connections. am i hit?
Re:The bcm43xx driver doesn't work by LordWoody · 2006-11-13 09:51 · Score: 1

I have a one-year-old HP zd8000 (17" model w/P4) and the bcm43xx works fine for me. It also works on our two-year-old zd7000 models.

--
Never meddle in the affairs of dragons,
for you are crunchy and good with catsup.

Re:NDISWrapper by twaltari · 2006-11-12 07:17 · Score: 1

Same here with Linksys wpc54gs. With lots of tweaking I was only able to get bcm43xx on Dapper work with WPA for a short while. After a reboot, I always had to go through the same tweaks again. I upgraded to Ubuntu Edgy Eft and now Wi-Fi works reliably.

64-bit version? by mikeron · 2006-11-12 08:02 · Score: 1

Question: Does anyone know if this affects the 64-bit driver? I have the firmware extracted from BCMWL564.SYS, and I'm not too concerned, but you never know... I guess I'd better be wary about booting into XP (32-bit).

Re:NDISWrapper by Carewolf · 2006-11-12 08:13 · Score: 1

No. There is a new one for broadcom wireless. It's called bcm43xx

Re:NDISWrapper by cheater512 · 2006-11-12 08:41 · Score: 1

Possibally yes but nothing will happen if a attack wasnt specifically targetetted at Linux machines.

Re:NDISWrapper by blackest_k · 2006-11-12 09:55 · Score: 2, Informative

The BCM4318 in native mode ie using the linux driver will only work at reduced speed and transmit power.
currently I think its officially listed as unsupported (11Mbs and 18Dbm)in ubuntu. Using ndiswrapper the driver forces the card from mode0 to mode2 and the card works reliably at 54Mbs and transmits at 25Dbm.
whats mode0 whats mode2 you could ask broadcom but they don't answer. Personally I would boycott Broadcom products and go for a more linux friendly companys chipset such as ralink, unfortunately with laptops its harder to avoid broadcom the wireless is minipci but the bios locks out non hp approved cards however
http://stachon.webpark.cz/ipw-eeprom.html might help with that.

--
Blarney Quality Restaurant, Plants

Re:NDISWrapper by jguthrie · 2006-11-12 10:23 · Score: 1

It's been months and months (more than a year, as I recall) since I ran the NDISWrapper driver for the wireless interface in my HP laptop. When using the native driver (which I have not had a lick of trouble with since it got included in the stock kernels those months and months ago) I can do things, like run Kismet, or change the SSID without rebooting, that were impossible, or at least appeared impossible, with NDISWrapper.

Re:NDISWrapper by ydrol · 2006-11-12 10:36 · Score: 3, Informative

Broadcom users on Linux should really be using the bcm43xx kernel module by now.

They want to , but bcm43xx is still unstable in long term use for some chips. It will work happily for a few hours, or even days and then something bad happens (ranging from dropped connections to panics). A lot of people have blacklisted this driver and gone back to Ndiswrapper , (eg new installs of Mandriva 2007, Ubuntu 6.06).

I personally had the bcm43xx drivers cause system instability with two very different machines and different broadcom chipsets. Going back to ndis made things stable again.

But Kudos to the bcm43xx developers, I hope they get this cracked. although in the future, I'll make more of an effort to steer clear of Broadcom, both because of their lack of co-operation in supporting Linux AND this recent news.

Broadcom can join Canon on my shit list.

What Century Will It Be by Master+of+Transhuman · 2006-11-12 11:07 · Score: 1

...when programmers FINALLY learn to stop producing buffer overflow conditions?

How many years now have they known this is a no-no?

When the hell are programmers going to be adequately trained in proper coding procedures?

When the hell are humans going to stop taking pointless shortcuts contradictory to their end goals? Or start using computers to CHECK FOR their stupid mistakes instead of using them to MAKE their stupid mistakes?

I've just switched back to Opera 9 because Firefox 2.0 is so riddled with stupid bugs - not to mention a new security problem just about every week. It was like using IE 5.0.

Get your heads out of your asses, geeks.

--
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!

Re:Please stop using C. - Duh by mustafap · 2006-11-12 11:31 · Score: 1

Higher level tools might be great for the kids of today, writing social web sites.

The kids of today however don't have a clue about the programs on which this internet is based on. The routers, the switches, the firewalls. Do you thing they are all written in C++ or Java?

C powers this world. You just don't know it.

--
Open Source Drum Kit, LPLC deve board - mjhdesigns.com

ndiswrapper by Alban · 2006-11-12 11:41 · Score: 1

Is the threat still in effect if the broadcom driver is used under linux with ndiswrapper?

Re:NDISWrapper by Anonymous Coward · 2006-11-12 15:50 · Score: 0

Did you follow the instructions found on ubuntuforums.org? the have detailed instructions on what driver to use, and how to extract thefirmware from bcmwl5.sys with the bcm43xx-firmwarecutter utility.
after that just copy them to the /lib/firmware/ folder. Make sure to onload ndiswrapper from the kernel before reloading bcm43xx.ko. My laptop with bcm4318 wireless uses the driver just fine, the only bug is that you have to pass 'iwconfig wlan0 ap any' to get it to see the acess point.
cheers.
Re:NDISWrapper by ncc74656 · 2006-11-12 18:30 · Score: 1

Don't forget about people using NDISWrapper, which is the only way to get such cards working on Linux at all unless someone has written a driver recently.

There is a native driver, but neither it nor ndiswrapper work worth a damn with my AMD64 Gentoo install. For the time being, I've given up on getting Linux WiFi working and just hang a Linksys WTR54GS off the network jack when I need to connect to someone's wireless network.

--
20 January 2017: the End of an Error.
Re:NDISWrapper by pwizard2 · 2006-11-12 18:56 · Score: 1

I have a broadcom wifi device in my HP notebook and not even ndiswrapper could get the damn thing working under Kubuntu. To get wifi working at all I had to make the notebook a dual-boot.

--
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."
Re:NDISWrapper by Zwaxy · 2006-11-13 06:32 · Score: 1

The exploit is available for metasploit, so I'm guessing it wouldn't be too hard to attach a Linux payload to it.

Fix Available by Gastrobot · 2006-11-12 14:18 · Score: 1

I believe Microsoft has an optional hardware upgrade available for download on Windows Update.

Re:Fix Available by Slashcrap · 2006-11-12 22:17 · Score: 0

I believe Microsoft has an optional hardware upgrade available for download on Windows Update.

Hardware updates from Windows Update have a nearly 100% record of completely hosing my systems. Has anyone else experienced this or am I just unlucky?
Re:Fix Available by Gastrobot · 2006-11-13 17:22 · Score: 1

I think that you're just unlucky. I find that they work consistently.

coders, mod parent up. by Gideon+Fubar · 2006-11-12 15:50 · Score: 1

i'd just like to say that this is a great idea. That is all :P

--
http://www.xkcd.com/354/

This is a 64-Bit driver by xenoarch · 2006-11-12 16:15 · Score: 1

This driver is a 64Bit driver so its only effects Windows 2003 64Bit and and Windows XP 64Bit (which is just win 2003 with XP UI) and maybe Linux 64 bit that uses it if the NDIS windows wrappers work on 64bit. but i'm not 100% sure on that.

32 bit os's with broadcom chipsets should be using a different driver anyways.

Re:This is a 64-Bit driver by xenoarch · 2006-11-12 16:22 · Score: 1

oops sorry that was the 32bit driver.. i swore i saw 64.sys at the end of the file name. Gues i been testing too many 64 bit drivers lately :)

64-bit Linux with ndiswrapper by timbo234 · 2006-11-13 01:03 · Score: 1

I'm using the 64-bit Windows driver with ndiswrapper on Mandriva 2007 x86_64, does anyone know if I'm affected?

--
Pre-canned Evolution Links for all those Slashdot holy wars.

Slashdot Mirror

Code Execution Bug In Broadcom Wi-Fi Driver

157 comments