Don't worry about those 40 Linux USB security holes. That's not a typo The Linux kernel USB subsystem has more holes than a donut shop. On Monday, Google security researcher Andrey Konovalov disclosed 14 Linux USB flaws found using syzkaller, a kernel fuzzing tool developed by another Google software engineer, Dmitry Vyukov. That's just the tip of the iceberg. In an email to The Register, …
> Hmm... Wasn't that the primadonna maintainer which could not stand Linus blowouts? That figures.
Given Linus's track record, the maintainer was probably punished for pointing out and trying to fix security holes. Linus is famous for his disrespect of security researchers, considering them no better than "masturbating monkeys" - his words not mine.
He also thinks that people who displease him should have the brake lines on their cars cut. He's pretty sick like that.
Linus's apathetic attitude to security concerns is a tax that every computer user gets to pay - every time another Linux-enabled piece of IoT crapware DDoSes the 'net to oblivion.
"It will be interesting to see how long it takes for this to be cleaned up"
USB has long been one of those things where switching it off in its entirety is good if you can do it.
There are many, many sub-drivers for different esoteric bits of little used USB kit in the kernel tree, that any USB device could bait into life then perhaps blindside. I like to prune the kernel build around here.
However, I don't think any of the other major OS's want to throw stones round here either. Does MS sandbox its squillion USB device drivers? Doesn't Apple's connector allow the device to DMA arbitrary RAM?
Interesting. Mass quantities of downvotes... and he's perfectly right. Linus does have an odd attitude towards security. He did call security researchers 'masturbating monkeys'. https://www.cio.com/article/2434264/open-source-tools/torvalds-calls-openbsd-group--masturbating-monkeys-.html
And he did advocate cutting the brake lines of those who annoy him. https://www.theregister.co.uk/2013/09/11/torvalds_suggests_poison_and_sabotage_for_arm_soc_designers/
Ah, well, let's see how many downvotes this gets...
"He did call security researchers 'masturbating monkeys'."
And then you add a link in which he doesn't call security researchers 'marturbating monkeys'.
Actually, the link itself show who he is calling that but, of course, reading that much is too much effort.
You do know that "Linus is famous for his disrespect of security researchers (all of them?)", if it was true, which it's not, does not mean "Linus's apathetic attitude to security concerns". That you did invent yourself, and is a dumb thing to write.
As far as I can remember he has suggested the real experts, the "mean hackers", should become good citizens, from black to white, sort of, as they are the real experts as they tend to be a step ahead.
Linus has stated in public that he does not consider security vulnerabilities any different from other bugs. That's a pretty apathetic attitude to security concerns in my book...
And he has basically told real experts trying to improve the security of the Linux kernel to go fuck themselves (probably not literally - I'd expect him to use much more creative insults than that). See refusal to interact with the Grsecurity guys in any meaningful way, for example, and the half-assed Kernel Self Protection Project that followed public pressure to improve the situation (which, by the way, is most certainly not composed of 'real [security] experts')
Plus, black hat kernel security wizards are paid handsomely for their efforts at doing black hat kernel security stuff nowadays. You can't just ask them nicely to start doing work for free instead and expect anything but a chorus of laughs.
"Linus has stated in public that he does not consider security vulnerabilities any different from other bugs. That's a pretty apathetic attitude..."
Your statement is insecure due to it having a vulnerable logical assumption in it.
Feature request: Post icon of Baldrick holding an iron.
"Linus has stated in public that he does not consider security vulnerabilities any different from other bugs. That's a pretty apathetic attitude to security concerns in my book..."
Only if you assume that all bugs are treated apathetically.
Maybe he was just saying that, by definition, a security vuln is a bug, ie something is not behaving as expected and since bugs are usually treated with varying degrees of urgency, it kinda makes your claim look a bit silly.
Dear Brits, next time, before you write "cut off your nose to spite your face", please do it, try it out first. There are dumb sentences in every language, one has to assume, but this takes the top one I can think of in English. Perhaps you could provide better to prove I don't know the language that well, which of course is a fact.
Somehow I have this feeling it has suddenly again appeared due to the Brexit rhetoric. The worst sentence, in any language, I can think of is "self hating Jew" and how it is used. And no I am not. Any better contenders and yes "The Mood" is like this.
The secure boot "golden key" was found a year ago as reported by this very esteemed organ.
"The secure boot "golden key" was found a year ago as reported by this very esteemed organ."
You might want to read what you linked to "These skeleton keys can be used to install non-Redmond operating systems on locked-down computers.". They don't compromise an installed / encrypted OS...
> Unless of course it runs say Secure Boot with Bitlocker.
Well accept if the PC boots, automatically bitlocker is already decrypting stuff so the PC is still susceptible to plug in device attacks. I've just "updated" a W10 box from a vendor's encryption system to bitlocker and was horrified to see that it just boots before taking me through the security checks before being able to access the disk.
Lets face it, Windows doesn't have a great track record when it comes to security.
"so the PC is still susceptible to plug in device attacks."
Of which there are none unpatched that I am aware of. And of which those that I am previously aware of all required a valid local login first...
"Lets face it, Windows doesn't have a great track record when it comes to security."
Neither does Linux...
"I seem to recall that the Scott expedition (I think) did not fancy the real article so very much. Oily and fishy.".
They might have stayed alive if they had had some oily to burn and some fishy to eat. I am not, however, sure there was any penguins in that hopeless effort. The sorry British effort to downplay Roald Amundsen was to point out that they shared a few dogs, between them and the dogs, as they had planned. (it's still around).
Poor Scott and his men had nor penguins nor dogs, just morphine for those dreadful last hours, and his dog rescue team did not reach them in time.
See what you did here Palpy, penguins means Linux not polar expeditions (or dogs).
PS. if you find an USB stick on the grass, preferable under some leaf, and you cannot, as we all know, stop your self from finding out, if perhaps, it contains something of great importance to somebody, but certainly not meant for you.
Then do like I always do, there back in that corner lies an old laptop with Linux but no internet and apart from that there lies a stick with an Linux iso on it. Into such a laptop you stick that USB you just found and then you get disappointed and format the damned thing or then you just dump it for the next person to find out, according to the mood you are in. And then you boot that old laptop with the Linux iso USB iv it and it's all fine again what ever was on that USB, I think.
That would be 'beware of the High Sierra' now, which doesn't work so well.
Oh? Just installed it after it had its first update (10.13.1) and apart from an unwillingness to auto-mount external drives if they are encrypted (hand-mount through Disk Util or command line) it appears to work reasonably well.
That said, WTF did they do in APFS that makes filesystem checks take THAT long?!? I checked a 500GB SSD in repair mode to see what it would do, and that clocked in at 10 full minutes (twice, because I thought I'd made a mistake and fired it up again before I got myself a coffee and watched it). Ugh.
Imagine if the disk is encrypted, no user is logged in and/or the screen is locked, and you can't do a cold-boot attack. Now the ability to execute code by plugging stuff into various orifices (on the computer, not on yourself) suddenly becomes a very, very relevant security issue.
Not to mention various kiosk-mode systems with exposed USB ports...
Or perhaps you ever plug in USB sticks that have been used on another system? Then this also suddenly becomes a security issue. A wormable security issue, even.
As is publicly known to have been done against Windows systems in the past - see Stuxnet for the most famous example. I wouldn't be surprised if these and other vulnerabilities have been exploited against Linux as well, just not made headlines in doing so... or perhaps never even been discovered by the victims.
but for the less paranoid person-in-the-street might be inclined to think "Finders keepers, losers weepers," not considering that perhaps their finding it was no accident.
The massive number does suggest there is a vacancy in the Linux kernel regular development roster with a full list of stuff to do right now.
"conduct dropped-drive attacks – leaving a booby-trapped gizmos in a parking lot"
I believe this is how the Stuxnet worm was spread. Get a USB stick with the corporate name and logo for where you want to target and either post it in to a random employee, or just leave it dropped in the reception area, car park etc.
Unless the company have a really cautious and security minded sysadmin who it gets handed to it will probably be plugged in to their systems without anyone considering the consequence.
But in the scenario that the original article talks about it is much more likely to be plugged into a Windows box unless you target a specific person/company that you know have a large number of Linux machines.
Yes the holes need to be plugged and the number is high. But I give the researchers credit for an enjoyable fuzz job.
Some perspective though... let's say I'm feeling a little evil:
If I want to steal your data I will just grab the HDD. Max 30sec. If I first just do a recon to figure out your make and model then replace like for like on second pass... will you really notice the change or will you just assume the HDD failed? Does your org track serial numbers? I do. Data at rest encryption is your friend here but it is not perfect.
If I want DoS whats to stop me from hacking a usb plug and mains plug into a plug of death adapter? Your motherboard will not survive mains being applied from USBP to USBM. Time to attack? Seconds. Platform independent.
What if I want deniability? Shell of USB stick in parking lot. Guts replaced by photoflash cap charger, cap, spark gap. Either label it as pr0n or an official software install disk. Costa a few bucks and needs only technician skills.
Or what about a kilo mixture of potassium permanganate and glycerine inside... heck, anything you want to experience a Viking funeral (DONT do this at home, kids).
Point is that if someone wants to do you in and they have access, how much can their OS help?
Like I have explained, there are also lots of scenarios where an attacker DOES have physical access but it's either not complete (like just having access to the screen, keyboard and some USB ports), the attacker only has a small amount of time (walking past a computer and sticking a USB stick into it vs. having to take the damn thing apart or atleast rebooting it), or simply that the disk is encrypted, the console locked, and you need to get the encryption key from memory to be able to access the data.
The whole "you're screwed if an attacker has physical access" near-truism simply doesn't apply for all values of "physical access", "attacker" and "screwed".
If it was universally true, there wouldn't be any reason to use full-disk encryption. The entire purpose of that is to protect against attackers with physical access, after all.
Or even the real classics like screen lockers, console login prompts, BIOS/bootloader passwords, or lockable computer cases. Much less tamper-resistent hardware or such where you can actually make a calculation for how much time/money is needed to bypass it.
Threat models and layered defense, you know...
There may be forty vulnerabilities, but they have already been a long time languishing in obscurity -- and even now they have come into the light, they will just be fixed, and life will go on going on pretty much as normal.
Not that this will stop the haters from gleefully making invalid comparisons (security bugs in Caged software are typically found by post-mortem analysis after they have already been exploited by the bad guys; security bugs in Free software are typically found by analysis of the Source Code, and fixed before they get exploited).
Remember what happened last year? No?
A Linux kernel bug that's been in there for 10 years was fixed. Because it was caught in the wild. Turned out Bad Guys <TM> had been using it for many, many years until finally their luck gave out...
Gazillions of people had read the vulnerable code, but noone except whoever wrote that exploit ever spotted it before.
Very few people are good at finding security vulnerabilities in software, even with full source code availability. Even fewer are willing to do this painstaking work for free. Open source might have an inherent advantage when it comes to the really simple stuff you can basically 'grep' a codebase for (simple overflows and such), but that's not very relevant for any major software these days.
Apart from kernels, the most attacked software is probably web browsers. Firefox and Chrome (both open source) bugs are certainly caught in the wild with some frequency. Edge/IE bugs are certainly not more frequent in the wild, though comparisions are hard because of their different popularity and usage patterns (Chrome has bigger market share, Edge/IE probably higher % of interesting targets because lots of enterprises are stuck on them).
And most bugs that are discovered by "good guys" in those are found by fuzzing, not reading the source code.
In case you don't know (since you obviously has no software security background whatsoever considering the statement you just made), fuzzing is not dependent on having the source code. Admittedly it does help somewhat because it means you can build with ASAN et al., but apart from that it only helps with root causing which is only relevant if you are either an attacker or trying to fix the bug.
@ patrickstar, no up or down votes from me, but this sentence makes no sense:
"Open source might have an inherent advantage when it comes to the really simple stuff"
How do you want to expand that, like "Close source might (or has) an inherent advantage (or dis-advantage) when it comes to really complicated (or simple) stuff".
Does not compute no matter how you turn it, to put it simply "the advantage of open source is that it is open source". Closed source is an other world.
Bug are bugs, and sometimes they steer you right in the face but you just cannot see them, and sometimes, just before you fall asleep, they reveal themselves in all their nakedness.
I haven't done any real programming for ten years but still I sometimes dream I am in some program trying to make sense of it.
What I meant to say was that if you write software without any regard for security - with things like basic overflows in unbounded string operations (strcpy strcat sprintf et al.), spawning external processes in insecure ways, etc - chances are the bugs will go undiscovered longer if its closed than if its open source. While they are normally pretty easy to find by fuzzing, firing up grep (or whatever) on the source tree is still less effort than implementing whatever protocol it speaks in a fuzzer.
But that's not the kind of bugs that plague any major software today.
Any argument that either open or closed source is inherently more or less secure is, of course, totally bogus. But you can definitely draw the conclusion from today's vulnerability landscape that there's no inherent all-encompassing advantage for open source projects.
And to elaborate on my previous argument a bit: I really, really doubt there's significantly more people studying Chrome or Firefox than Edge source for security vulnerabilities before a version hits production. You simply can't rely on people doing this kind of work for free. And these projects are basically entire universes of their own - you need to have lots of experience with each particular project to be able to audit them in any meaningful way.
Regardless of the source code availability or distribution model you need to have a solid security team that are actually in the loop about all the internals.
You can't rely on the mythic "lots of eyeballs" because there's simply not gonna be a lot of people reading that kind of source code at all, let alone people who are good at finding vulnerabilities in it. And you need solid exploit mitigations in place because there ARE gonna be vulnerabilities that gets discovered by 'bad guys' long before any 'good guys' as long as you stay within current software development paradigms.
Google has clearly understood this, probably Firefox too.
For the record, I hate Google with a passion and avoid their products like the plague, but atleast their security efforts are pretty good when it comes to Chrome... Certainly a lot better than many open source projects AND commercial closed source vendors (not MS on a good day though).
This post has been deleted by its author
While the discovery of 40 Linux USB security vulnerabilities is concerning, it highlights the open-source community's commitment to robust cybersecurity. Swift collaboration and patching efforts will fortify Linux systems, ensuring user safety. It's a testament to the community's resilience and dedication to maintaining a secure computing environment.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
