Chrome OS To Block USB Access While the Screen is Locked (zdnet.com) 91
Google will add a new security feature to Chrome OS, the company's web-based operating system that powers its Chromebooks devices, it announced this week. From a report: The new feature, named USBGuard, will block access to the USB port access while the device's screen is locked. According to a Chrome OS source code commit spotted by Chrome Story earlier this week, the new feature is currently available in Chrome OS Canary builds and is expected to land in the stable branch of Chrome OS soon. Once this happens, users can enable it by modifying the following Chrome OS flag: chrome://flags/#enable-usbguard . The way this security feature is meant to work is by preventing the operating system from reading or executing any code when a USB-based device is plugged in, and the screen is locked.
Macs had this for years (Score:1)
At least, as Mass Storage Devices is concerned.
If you insert a mass storage device in a mac while locked, it will not be recognized or mounted.
So, welcome ChromeOS
Re:Macs had this for years (Score:4, Interesting)
So if you have a locked screen and the keyboard stops functioning, plugging a new one in the USB port will not work?
Re: (Score:2)
"That's great. So a USB can claim to be a keyboard, but really is a storage device. What difference does it make?"
You mean besides it storing all the passwords you type in and those awful, disgusting porn search terms you enter?
keyboard vs storage (Score:2)
Three bad scenario.
- if the new version of chrome OS blocks *all* USB peripheral, like the summary implies:
you try to wake up your chromeOS powered mini PC/smart appliance/etc. but you can't unlock past the password prompt, because the keyboard is dead (battery of wireless empty, keyboard is physically fried, water dammage because spilled beer, etc).
you try plugging another USB keyboard, but it's blocked. You can't type your password, you need to hard reset, all your unsaved data is lost (including the one
Re: (Score:2)
A keyboard-shaped peripheral may contain a composite device that supports both HID class (for keyboard use) and mass storage class (for reading and writing, say, microSD cards).
storage keyboard (Score:2)
this one is the benign version.
the malicious version is the otherway around:
a USB Stick shaped device that suddenly exposes a USB HID device while you're away and uses this simulated keyboard to start hacking your computer.
(look fir "Bad USB", there are even tutorials explaining how to make one out of a Raspberry Pi Zero).
Searches (Score:2)
Fir? Nothing is Coming up when I search for âoefir bad usbâ
...writes the guy who also uses a smartphone to type /. posts too.
You know "âoefir" and "usbâ" search keywords won't bring much neither~~
(Not even auto-correct will help against for/fir mistypes, being a perfectly valid english word [wikipedia.org], even a current season relevant one. If you find a "Bad USB" under your Christmas fir tree, you know Santa hates you).
BTW: beside "Bad USB [duckduckgo.com]" another relevant keyword to search for is "Rubber ducky [duckduckgo.com]"
An USB device can claim to be different things (Score:2)
You can definitely plug something that declares itself a keyboard then turns itself into something else.
There are many applications, for instance my Nitrokey Storage declares itself a simple USB read-only key when plugged, and then turns itself into many other things (simultaneously) when I ask the right questions.
You can check that, and also how you can protect you, hardware side : https://github.com/robertfisk/... [github.com]
(disclaimer : I am not related to the device or its designer, but I own two, and they have wo
Re:Macs had this for years (Score:5, Informative)
So if you have a locked screen and the keyboard stops functioning, plugging a new one in the USB port will not work?
The parent to your comment specifically said "mass storage", which human interface devices are not. The summary also refers to not being able to read or execute code while locked and USB inserted, which sounds similar... since key-presses/mouse-clicks aren't code.
I suspect someone smarter than both you and I thought about this before implementing it.
Not sure what you are getting at there (Score:2)
And yet, there are ways to trick the USB firmware into misclassifying a device trivially.
Yes, and?
I mean, I suppose you COULD misidentify a keyboard as a mass storage device and it would not work.
Or you COULD misidentify your external USB drive as an input device and it would do exactly nothing, unless it had the password to unlock your system.
Re: (Score:2)
From TFA:
”Google took this precaution to prevent Rubber Ducky-type of attacks. A Rubber Ducky is a well-known term used to describe a malicious USB thumb drive that when plugged into a computer mimics a keyboard and runs malicious commands.”
Re: (Score:2)
Which raises the question of why ChromeOS would be vulnerable to such an attack while the machine is locked.
Re: (Score:2)
Most OSes seem dependent on the integrity of the lock-screen program when it comes to blocking keyboard access to the OS. I seem to recall a problem related to this with an early iteration of the Gnome screensaver (not Xscreensaver)... and I think there was one with Mac’s screensaver component some years ago.
Yes exactly (Score:2)
Which raises the question of why ChromeOS would be vulnerable to such an attack while the machine is locked.
That's exactly what I was getting at - on OSX you can type all you like once the system is locked, unless you know the system password (as I said) you aren't doing anything.
So what the hell is going on with ChromeOS that typing actually matters when the system is locked??
Re: (Score:2)
And yet, there are ways to trick the USB firmware into misclassifying a device trivially.
And as a result the mass storage device won't be able to do much more than send keystrokes back and forth.
The risk and malware vector you're describing it mis-classifying a functioning device while a second loads in the background with a different classification. This would still prevent miss-classifying as an attack vector when the screen is locked.
Re: (Score:2)
I suspect someone smarter than both you and I thought about this before implementing it.
Well, unlike most people here I have been reading TFA and lookie here:
Google took this precaution to prevent Rubber Ducky-type of attacks. A Rubber Ducky is a well-known term used to describe a malicious USB thumb drive that when plugged into a computer mimics a keyboard and runs malicious commands.
So what happens when you plug in a regular keyboard? My guess is "nothing". So there might be a problem when you want to troubleshoot a machine which is supposed to run unattended (NAS, video monitoring, etc).
What unattended Chromebook? (Score:2)
So there might be a problem when you want to troubleshoot a machine which is supposed to run unattended
A Chromebook is not "supposed to run unattended". From the horse's mouth [chromium.org]: "Remember: Chrome OS devices are not general-purpose PCs."
Re: (Score:2)
Re: (Score:1)
They need to be cracked so they can be turned into GP computing devices. Then again, that's a lot of work for essentially a netbook.
Re: (Score:2)
Well that depends upon how much you spent on your Chromebook, if these prices are anything to go by https://www.techradar.com/news... [techradar.com], if you keyboard stops working, toss it in the bin and buy a new one, though I suspect that the $35AUD price tag might not be quite accurate ;D.
Re: (Score:2)
You missed the point entirely, congrats. It's not about the value of the keyboard, it's about the inability to access your machine in case the connected keyboard stops working.
Why execute code on mount in the first place? (Score:5, Insightful)
Isn't that the real issue?
If I mount a filesystem, I don't expect it to start executing random files on it at all.
Re:Why execute code on mount in the first place? (Score:4, Interesting)
On the other hand, you do expect it to start executing file system driver code. So if you can trigger an exploitable vulnerability in a driver using a specially crafted file system image, that'll do the trick.
Of course that applies to any driver, not just a file system driver. Perhaps the idea is that without a mass storage device it becomes harder to load an attack payload. Not a very convincing idea, I admit; there are certainly ways around that.
Re: (Score:2)
On the other hand, you do expect it to start executing file system driver code.
Well, I expect it to have exactly the filesystem drivers I compiled in. But you are correct that many pre-packaged OSes include a lot of filesystem and other drivers that are not strictly needed and, to make it worse, will load them automatically if they detect the respective filesystem or device. Linux was a while vulnerable via some very old and obscure driver for some MAC OS fs, for example. That is why in any system hardening you remove all drivers that are not strictly needed, not only for file systems
Re: (Score:1)
Well, I expect it to have exactly the filesystem drivers I compiled in.
And you're 100% certain, beyond the shadow of a doubt, that the file system drivers you compiled in contain no vulnerabilities at all ?
Formally verified file system (Score:2)
You just made me curious about whether formal verification [wikipedia.org] has ever been applied to file system drivers distributed to the public as free software. Because if so, then one could prove beyond reasonable doubt that a file system driver has no vulnerabilities.
Re: (Score:2)
Hahahahaha, no. There are formally verified protocols than then was found to be vulnerable because somebody successfully attacked it. The thing with formal verification is that you _always_ need to be make assumptions and they can have errors. Also, you cannot (due to effort) formally verify the compiler and the CPU and the rest of the system (e.g. DMA unit), so formal verification does very much not give you that "beyond a reasonable doubt" either.
Re: (Score:2)
The problem is it's not just a file system driver. The filesystem driver relies on potentially a multi-block device driver to provide fault tolerance support, which relies on block device driver(s) to implement a block interface. That block driver relies
Re: (Score:2)
Why would I need that? Expecting 100% security is a noob mistake. This is risk-management and that is not a beginner's game.
The only thing I need is that I am reasonably sure they are well-maintained, current and actually fs drivers I regularly use.
Re: (Score:1)
Fuck a duck. If you have physical access to the machine, stopping access to the USB ports is going to give you FUCK ALL extra security. What next? Disable charging on the intelligent power port on the device because it's USB-C or some other fucking communicative DC jack in case there's a vulnerability? Ban the WiFi or ethernet socket on screen lock? You know what that's called? The fucking power button.
This reminds me of a CVE for OpenBSD a long time ago which complained an unpatchable DoS vulnerability
Re: (Score:1)
It's common knowledge that Mercedes vehicles that are out-of-warranty are high risk purchases and quite inexpensive. Because the steep maintenance cost makes them mostly not worth having. So you can get 'nice' older Mercedes sedans for $8-10K because the cost of servicing them is out-of-this-world, and they're complex fusty machines that need said service regularly.
Re: (Score:2)
It is a real issue in the sense that the people creating configurations that do this demented thing are real. If we only had sane people doing default configurations, most security problems would go away. But there is a lot of people that do not get it and are unaware of that and hence mess it up. Dunning-Kruger effect at work.
Re: (Score:2)
If I mount a filesystem, I don't expect it to start executing random files on it at all.
Who is talking about mounting filesystems?
What about a HID device that captures keystrokes or inserts its own?
What about a network device that captures packets while the device is locked, or overrides your settings to send your data elsewhere?
And when we start talking about mounting filesystems then you have to remember that most attack vectors don't rely on "executing random files" as much as use existing bugs in software that would legitimately look at the mounted filesystem. Stuxnet spread via a file on
Re: (Score:2)
I think TFA is confused. Chrome OS does not execute code from flash drives at all. It only runs apps you install, it doesn't run anything that wasn't installed.
What they are actually doing is spotting the OS driver even enumerating USB devices when the screen is off/locked. That prevents attacks on the USB stack itself.
Re: (Score:2)
Having to type and use the CLI to get USB working every time is distracting from viewing ads.
Oops! What Keyboard (or mouse)? (Score:1)
... because you know they're going to block *everything*, even if they only do it by accident.
And woe be those servers that use an internal USB port as a secure boot device.
And finally, all those programs that use a USB dongle as part of a two-factor security system.
Windows XP (Score:5, Interesting)
Microsoft already had this in the initial release of Windows XP a long ass time ago. They removed it with the very first SP. Why? Because if there are ANY keyboard issues, you cannot add another one at all. Windows XP Pre-SP USB device detection only happens AFTER login. You run the risk of literally be locked on the password screen with zero way to enter a password. Things may be different with attached keyboards and touch screens now, but I still like the idea of the safety net of being able to attach a keyboard during trouble shooting.
Re: (Score:2)
Go back to PS/2 connectors. (Score:1)
Or at least PS/2 emulating usb subsystem for the primary console.
Linux has this same problem under certain types of lockups/crashes. The USB subsystem can freeze keeping you from rebooting the system or getting to a console to fix the issue, while a PS/2 keyboard can ALT-SYSRQ to freedom.
Unfortunately most modern linux distros lock out those sysrq keys by default, even though they can sometimes allow a power user to solve hardware/software issues without a full system reset.
captcha was 'teletype'. Even 50+
How you gonna do it? (Score:4, Funny)
PS/2 keyboards do not work on google devices.
Heck, a PS/2 keyboard doesn't even work on a PlayStation 2 despite the name.
Re: (Score:2)
The commit mentions that there is a whitelist of allowed devices, and presumably HID keyboards are on it.
Re: (Score:2)
That's really good to know, thanks! I'd hate to have a repeat of the WinXP days. Thats was annoying as hell. Only solution back then was to hopefully still have a PS/2 keyboard in stock and the mobo having a port for it, otherwise it required either hacking the OS via boot media to remove the password, or a full reinstall.
Re: (Score:2)
This is particularly true since waking computers up from sleep mode does tend to cause input devices to stop responding. Hell, I've had plenty of wake-up problems on both PCs and Macs for over 20 years, so it's obviously a problem that's not easy to solve, either technically or politically.
Re: (Score:2)
First, the featured article is phrased in such a way as to imply that the USB Guard feature isn't even turned on by default. Second, how would USB Guard block backing up your files to a public or private cloud, unless perhaps you're using a USB network interface?
Re: (Score:2)
Optimist: Ideally, USB Guard in Chrome OS could be configured such that if a USB device is seeing substantial block traffic in the seconds prior to unmounting, it'll stay mounted until the traffic dies down.
Pessimist: Google wants Chrome OS users to subscribe to both Google One [google.com] and a wired home Internet provider as a substitute for backups to USB mass storage.
Re: (Score:2)
From my understanding, this is not shoved down the users' throats and can be toggled on/off.
Re: (Score:2)
All OSs should do that. It shouldn't have ever been a thought.
I don't see it applying quite as easily to a desktop computer. If USB is disabled until you authenticate, through what interface would you authenticate?
Re: (Score:2)
Block charging too! (Score:2)
I don't want those dangerous potentials and currents getting to the battery if I've locked my phone.
Re: (Score:2)
For me, the way both sentences are written actually means the system *fully halts* when you plug the USB. :-D
I leave it to you to further evolve the text
how about always enabling it? (Score:2)
ok, i get it, if you're not near your computer and somebody plugs in a usb stick your computer can get hacked without you knowing it.
but, if you, while working, plug in a usb stick with malware on it yourself it will still execute?
how about not executing anything at all when inserting a usb device, sounds like a much better idea.