“A bug in the Caiaq USB driver, which could be used to execute arbitrary at the kernel level has been reported by Rafael Dominguez Vega of MRW InfoSecurity. The device drivers are vulnerable to buffer overflow condition when an USB device with an unusually long name (over 80 characters) is connected to the machine.”
is there any fix coming? has this been fixed yet?
Yes
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git&a=com…
It was fixed on Feb. 14 2011
Heh, we have been fixing a ton of issues like that in Haiku recently – Coverity picks them up like a champ
Nice, thanks.
USB device with an unusually long name (over 80 characters) who the f*** uses 80+ characters to name a usb drive?
The person attacking the computer.
so this guy must have access to my pc and insert a 80+ characters named usb drive in order to exploit it? It’s not like if i have a usb drive with a huge name my computer can be exploited by a hacker half way around the world. I’ll restrict my usb drives to less characters, just in case.
It may not affect you – but something like this is indeed bad. For example, what prevents a Kiosk running Linux from being pwned. Think: digital picture processing kiosk at the drug store.
It’s even more disturbing after reading the recent report on what governments have been up to with HBGary:
http://arstechnica.com/tech-policy/news/2011/02/black-ops-how-hbgar…
On the other hand, considering how easily he got owned how good can he actually be and how much should we trust what he says he has done?
Well, if you follow the story, HBGary Federal was owned, HBGary was collateral damage. They apparently do have some decent technology, including unreleased 0day exploits…
But the important bit is: The U.S. government is knowingly hiring firms to exploit via hardware ports such as USB and PCMCIA.
Why hire someone to break in when you can just pay the coder to not lock the door?
Or so he says. To be honest, reading that article it feels like the wet daydreams of some loser who has watched too many spy movies. Like some cyber version of Jonathan Idema.
I would not expect anything less.
Edited 2011-03-08 20:13 UTC
Thank you for sharing, that post is very interesting.
For example, what prevents a Kiosk running Linux from being pwned. Think: digital picture processing kiosk at the drug store.
I have seen one of the picture processing kiosk at a local drug store and the kiosk if I remember correctly was from Kodak or Fuji film. They were actually running Windows. And with the help of my humble memory some of articles or comments on this site was saying those kiosk commonly running Windows instead of Linux. Since this is Linux bug I doubt it would affect many of those kiosk.
Sure, maybe now – but with shit like this:
http://it.slashdot.org/story/10/07/06/0019234/Photo-Kiosks-Infectin…
How long before they realize Windows is the wrong solution?
Can we just stick to the subject of this article?
Sure, because sticking a USB stick into a kiosk running a vulnerable operating system is soooo off topic eh?
Ummm, never?
They don’t *WANT* a great solution. They want something that they don;t feel they have to reinvent the wheel err… compile from source and insert kernel modules… etc.
Yeah, I know. I’ve had Linux Kiosks running for a Coffee House Locally for almost 4 years. Worst thing that happened is some person’s web e-mail tried to write to C:\Windows\something\something\blahblahblah
Plus running from an Optical Drive is nice.
What’s funny is that just the other day, I walked in front of one of those things in Walgreen’s. It was prominently displaying the Blue Screen of Death on its screen. It’s not the first time–I’ve seen them display standard Windows errors (including crashes) and BSODs more times than I care to remember…
At this rate, I think that as long as those things are running Windows and are inoperable a large portion of the time as a result, people are “relatively” safe from digital picture kiosks. LOL.
Let me spell it out for you: a malicious person.
What is it ? Is it actually a widespread device ? Never heard of that.
I looked into it, but the module is running on my install (Ubuntu 10.10). Not sure what hardware is it hooked to.
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
Sound card?
Looks like it
http://caiaq.com/index_en.html
http://www.globalsecuritymag.com/Vigil-nce-Linux-kernel-buffer,2011…
(Putting some memory regions on W and X access privileges at the same time… Them fool… DEP is not here for nothing !)
Edited 2011-03-08 20:56 UTC
The title promises a lot – it sounds like some rather general exploit on the Linux kernel, when it is nothing more than a buffer overflow bug in a particular driver.
I wouldn’t be that surprised to see that on Slashdot – and then promptly tagged there with the “notnews” tag – but I don’t think that it is really much of an event (I think, without having seen statistics about it, that dozens, if not hundreds, of such bugs are found and fixed each year.) – at least not enough of an event to warrant a place on OSAlert.
I downloaded a recent kernel source bundle and did: grep -IR ‘\<strcat\>\|\<strcpy\>’ *|wc -l
This found 3558 lines. While many of them are in the form `strcpy(foo, “string literal”);` I think usage of these functions should be generally forbidden. All these function calls should be replaced with strlcat/strlcpy.
Edited 2011-03-08 21:20 UTC
Well, Ulrich Drepper does not like strlcat/strlcpy so they won’t be in glibc anytime soon.
The kernel can just use its own implementations of strl{cat,copy} until they are standardized, no?
Nice in theory. Linux kernel does have strncat and strncpy and problem back in history they leaked a little memory. So to avoid that problem some drivers changed over to strcpy so leading us todays problem.
Historic chain of failure. Hopefully this is close to the last bit of it.
These functions will never be standardized. c1x – the next C standard – will include the IMHO inferior but good enough(certainly better than str* and strn*) str*_s by Microsoft.
This has little relevance though, given that the Linux kernel doesn’t use glibc and it *does* include strlcat and strlcpy.
So do glib, KDE and Samba, for example. Basically everyone but that Drepper guy has got them.
http://www.youtube.com/watch?v=ovfYBa1EHm4
Never been a fan of Nautilus.
This is Linux of course black list the driver,
http://www.cyberciti.biz/tips/avoid-linux-kernel-module-driver-auto…
Problem solved. Insert infected device as much as like after that is done its worthless.
Yes the hotfix to the issue.