Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Code Execution Bug In Broadcom Wi-Fi Driver

Zonk posted more than 7 years ago | from the catch-that-insect dept.

Security 157

2U*U2 writes to mention an EWeek article about an entry in the Month of Kernel Bugs. John Ellch has discovered a critical vulnerability in the Broadcom wireless driver: a driver used in machines from HP, Dell, Gateway, and eMachines. From the article: "[The bug] is a stack-based buffer overflow in the Broadcom BCMWL5.SYS wireless device driver that could be exploited by attackers to take complete control of a Wi-Fi-enabled laptop. The vulnerability is caused by improper handling of 802.11 probe responses containing a long SSID field and can lead to arbitrary kernel-mode code execution. The volunteer ZERT (Zero Day Emergency Response Team) warns that the flaw could be exploited wirelessly if a vulnerable machine is within range of the attacker."

cancel ×

157 comments

Sorry! There are no comments related to the filter you selected.

QUARANTINE (0, Offtopic)

LiquidCoooled (634315) | more than 7 years ago | (#16812626)

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.

Thanks (5, Funny)

SnowZero (92219) | more than 7 years ago | (#16812652)

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:NDISWrapper (3, Informative)

Anonymous Coward | more than 7 years ago | (#16812730)

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.

Re:NDISWrapper (2, Interesting)

cheater512 (783349) | more than 7 years ago | (#16812848)

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.

Re:NDISWrapper (5, Informative)

ettlz (639203) | more than 7 years ago | (#16812914)

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 (1)

Mathinker (909784) | more than 7 years ago | (#16813038)

> 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 [berlios.de] , 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.

Re:NDISWrapper (1)

twaltari (217837) | more than 7 years ago | (#16815290)

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.

Re:NDISWrapper (1)

flydpnkrtn (114575) | more than 7 years ago | (#16813762)

The FreeBSD equivalent of NDISwrapper is "Project Evil" [pingwales.co.uk] if anyone's wondering...

Re:NDISWrapper (1)

MLease (652529) | more than 7 years ago | (#16814572)

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

The bcm43xx driver doesn't work (1)

Viol8 (599362) | more than 7 years ago | (#16815202)

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

Re:NDISWrapper (2, Interesting)

Carewolf (581105) | more than 7 years ago | (#16812922)

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.

Re:NDISWrapper (1)

Foktip (736679) | more than 7 years ago | (#16814918)

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

"BCMWL5.SYS" (4, Funny)

The Creator (4611) | more than 7 years ago | (#16812928)

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

Re:"BCMWL5.SYS" (2, Interesting)

Wonko the Sane (25252) | more than 7 years ago | (#16813186)

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" (1)

mjg59 (864833) | more than 7 years ago | (#16814524)

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.

Zonk only uses Windows and Hates SONY (1)

Mongoose (8480) | more than 7 years ago | (#16814894)

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

Well crap. (5, Funny)

Merc248 (1026032) | more than 7 years ago | (#16812666)

Checklist for today:

  1. Eat
  2. Rant on Slashdot
  3. Change SSID from "omgomgomgomgomgomgomg" to "omgomgomg"
  4. Sleep

So... (4, Insightful)

radu.stanca (857153) | more than 7 years ago | (#16812676)

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

Re:So... (1)

Gideon Fubar (833343) | more than 7 years ago | (#16812828)

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.

Re:So... (0)

Anonymous Coward | more than 7 years ago | (#16813264)

"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... (2, Interesting)

masklinn (823351) | more than 7 years ago | (#16813072)

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)

Re:So... (3, Interesting)

dfghjk (711126) | more than 7 years ago | (#16813242)

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 [daringfireball.net]

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... (2, Informative)

tunjin (664226) | more than 7 years ago | (#16813364)

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 [apple.com]
...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/ [studio78.at]

Re:So... (0)

Anonymous Coward | more than 7 years ago | (#16813706)

I wonder if John Gruber realizes he's just the kind of cunt in whose eye you'd want to stub out a cigarrette?

But which OS!? (4, Informative)

Idaho (12907) | more than 7 years ago | (#16812692)

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?

Re:But which OS!? (2, Funny)

Anonymous Coward | more than 7 years ago | (#16812734)

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...

Ndiswrapper? (0)

Anonymous Coward | more than 7 years ago | (#16812774)

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?

Johnny Cache (2, Funny)

davro (539320) | more than 7 years ago | (#16812694)

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.. (2, Interesting)

Channard (693317) | more than 7 years ago | (#16812708)

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.. (1)

UncleTogie (1004853) | more than 7 years ago | (#16812804)

{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? ;)

Re:Kind of makes me glad I've got homeplug.. (1)

inio (26835) | more than 7 years ago | (#16812822)

Do you have stairs in your house?

Re:Kind of makes me glad I've got homeplug.. (1)

Svartalf (2997) | more than 7 years ago | (#16813796)

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...

Re:Kind of makes me glad I've got homeplug.. (1)

Jacco de Leeuw (4646) | more than 7 years ago | (#16813042)

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.

Re:Kind of makes me glad I've got homeplug.. (1)

Psiren (6145) | more than 7 years ago | (#16813206)

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.. (1)

Channard (693317) | more than 7 years ago | (#16813514)

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.. (1)

Svartalf (2997) | more than 7 years ago | (#16813818)

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.

Re:Kind of makes me glad I've got homeplug.. (1)

Psiren (6145) | more than 7 years ago | (#16813996)

Good point, hadn't thought about the meter. Thanks :)

What about those phone-home laptops? (1)

IchBinEinPenguin (589252) | more than 7 years ago | (#16812716)

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 (2, Insightful)

Anonymous Coward | more than 7 years ago | (#16812720)

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 (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16812908)

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.

well that was expected? (1)

tunjin (664226) | more than 7 years ago | (#16812758)

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

http://roman.studio78.at/ [studio78.at]

Linux (1)

utopicillusion (843168) | more than 7 years ago | (#16812820)

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 (1)

cheater512 (783349) | more than 7 years ago | (#16812866)

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 (0)

Anonymous Coward | more than 7 years ago | (#16812876)

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 (1)

Proud like a god (656928) | more than 7 years ago | (#16812950)

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 (0)

Anonymous Coward | more than 7 years ago | (#16813246)

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 (0)

Anonymous Coward | more than 7 years ago | (#16814236)

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 (0, Troll)

MicrosoftRepresentit (1002310) | more than 7 years ago | (#16813408)

Fucking hell I thought Mac zealots where bad, but you Linux hippies are just unbelievavble...theres not shortcoming in Linux where you can't find some twisted logic to help yourself believe that its a Good Thing, is there?

Re:Linux (1)

oesj (1018208) | more than 7 years ago | (#16813130)

...or people spend(waste) less time looking for their bugs?

It works because it's free and it can, Re:Linux (2, Interesting)

twitter (104583) | more than 7 years ago | (#16814558)

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.

Re:Linux (0)

Anonymous Coward | more than 7 years ago | (#16814726)

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.

feature (-1)

Anonymous Coward | more than 7 years ago | (#16812858)

It's not a bug, It's a feature!

User space device drivers (4, Insightful)

camcorder (759720) | more than 7 years ago | (#16812868)

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.

Will this help? (1)

leehwtsohg (618675) | more than 7 years ago | (#16813112)

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? (0)

Anonymous Coward | more than 7 years ago | (#16813296)

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? (2, Insightful)

enosys (705759) | more than 7 years ago | (#16814444)

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.

Re:User space device drivers (1)

TCM (130219) | more than 7 years ago | (#16813166)

Congratulations, you just reinvented microkernels (poorly).

Re:User space device drivers (0)

Anonymous Coward | more than 7 years ago | (#16813328)

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)

Is this related to the (0, Redundant)

porkchop_d_clown (39923) | more than 7 years ago | (#16812900)

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...

Re:Is this related to the (0)

camperslo (704715) | more than 7 years ago | (#16813238)

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 [kismac.de] )

Separate stack (1)

QuickFox (311231) | more than 7 years ago | (#16813022)

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.

Re:Separate stack (1)

miu (626917) | more than 7 years ago | (#16813352)

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

Re:Separate stack (1)

QuickFox (311231) | more than 7 years ago | (#16813652)

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.

Re:Separate stack (0)

Anonymous Coward | more than 7 years ago | (#16813802)

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 (1)

QuickFox (311231) | more than 7 years ago | (#16814438)

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.

Re:Separate stack (0)

Anonymous Coward | more than 7 years ago | (#16815278)

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 (1)

QuickFox (311231) | more than 7 years ago | (#16815394)

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.

It's a design decision... (1)

Svartalf (2997) | more than 7 years ago | (#16813954)

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.

Re:It's a design decision... (1)

QuickFox (311231) | more than 7 years ago | (#16814614)

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!)

Re:Separate stack (1)

TheRaven64 (641858) | more than 7 years ago | (#16814758)

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.

Workaround for non-Linksys devices (5, Informative)

Jacco de Leeuw (4646) | more than 7 years ago | (#16813026)

George Ou at ZDNet has published a procedure [zdnet.com] 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.

Re:Workaround for non-Linksys devices (1)

kahunak (40974) | more than 7 years ago | (#16813988)

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 [linksys.com] , 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 (1)

enosys (705759) | more than 7 years ago | (#16814468)

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.

bcm43xx (1)

Jack Malmostoso (899729) | more than 7 years ago | (#16813122)

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

Re:bcm43xx (1)

Svartalf (2997) | more than 7 years ago | (#16813834)

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

Yawn (0, Flamebait)

dangitman (862676) | more than 7 years ago | (#16813168)

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.

Please stop using C. (1)

master_p (608214) | more than 7 years ago | (#16813386)

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 [slashdot.org]

Re:Please stop using C. (5, Insightful)

FireFury03 (653718) | more than 7 years ago | (#16813712)

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?

Re:Please stop using C. (0)

Anonymous Coward | more than 7 years ago | (#16814366)

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. (1)

Viol8 (599362) | more than 7 years ago | (#16815226)

"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. (1)

romiz (757548) | more than 7 years ago | (#16814638)

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.

Puh-lease. (4, Informative)

Inoshiro (71693) | more than 7 years ago | (#16814708)

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 [wikipedia.org] . Or even use a whole OS [washington.edu] 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.

Re:Puh-lease. (1)

Viol8 (599362) | more than 7 years ago | (#16815252)

"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.

Re:Please stop using C. (0)

Anonymous Coward | more than 7 years ago | (#16813716)

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. - Duh (1)

mustafap (452510) | more than 7 years ago | (#16813722)

>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.

This is foolish (0)

Anonymous Coward | more than 7 years ago | (#16814440)

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 (1)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#16814514)

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.

Re:Please stop using C. (0)

Anonymous Coward | more than 7 years ago | (#16813774)

"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. (0)

Anonymous Coward | more than 7 years ago | (#16813830)

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

All right please keep your _BFM_ shut !!.

Re:Please stop using C. (1)

ettlz (639203) | more than 7 years ago | (#16814414)

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.

What about ndiswrapper and bcm43xx kernel driver? (1)

kahunak (40974) | more than 7 years ago | (#16813862)

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... (2, Insightful)

Anonymous Coward | more than 7 years ago | (#16813922)

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.

What, no snarky comment... (0)

Anonymous Coward | more than 7 years ago | (#16813960)

...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.

buffer overflows... (1)

hitmark (640295) | more than 7 years ago | (#16814116)

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

Re:buffer overflows... (1)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#16814526)

'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... (1)

hitmark (640295) | more than 7 years ago | (#16814618)

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.

Re:buffer overflows... (1)

TheRaven64 (641858) | more than 7 years ago | (#16814818)

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).

Someone please enlighten me... (1)

93 Escort Wagon (326346) | more than 7 years ago | (#16815040)


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?

Re:Someone please enlighten me... (1)

93 Escort Wagon (326346) | more than 7 years ago | (#16815068)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?