Chrome OS To Block USB Access While the Screen is Locked (zdnet.com)

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.

Comments

Macs had this for years

[williamyf]

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

[war4peace]

So if you have a locked screen and the keyboard stops functioning, plugging a new one in the USB port will not work?

Re: Macs had this for years

[Anonymous Coward]

oh SO generous of you Google!

Re:Macs had this for years

[Anonymous Coward]

Right. Because a keyboard is a storage device.

Re:Macs had this for years

[PsychoSlashDot]

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.

Re:Macs had this for years

[Anonymous Coward]

And yet, there are ways to trick the USB firmware into misclassifying a device trivially.

Re: Macs had this for years

[Anonymous Coward]

Well it checks a web page at google and if the web page is unavailable then it might be tricked, well, at least until the next hardware update which is due any time (see what I did there?)

Re: Macs had this for years

[Anonymous Coward]

A USB device is whatever it CLAIMS to be, not what it actually IS.

Re: Macs had this for years

[Anonymous Coward]

That's great. So a USB can claim to be a keyboard, but really is a storage device. What difference does it make? It won't work as a storage device or a keyboard if it does that.

Re: Macs had this for years

[Anonymous Coward]

Thatâ(TM)s what imbeciles tend to think

Re:Macs had this for years

[Anonymous Coward]

So, any bug or feature in the USB stack in MacOS that can be triggered by a device that's not labelled as MSD can be triggered when a Mac is locked. ChromeOS sounds like they're going as far as effectively not-enabling *any* device plugged in while locked. So, that goes a lot further (presuming there's no bug in that code). Imagine if iPhones and iMacs originally had this features.

Re: Macs had this for years

[Anonymous Coward]

Imagine if you will from the comfort of your stupid little pillow

Re:Macs had this for years

[Anonymous Coward]

I would not be that worried about a mass storage device, no code is executed from it (unless it exploits a driver bug). A network adapter seems more dangerous, as it could offer a DHCP lease in the 0.0.0.0/0 network, causing all traffic to go through it, since it is link local. I have plugged in a usb->ethernet in my mac when it was locked and I seem to remember it worked (I SSH'ed to it)

Re:Macs had this for years

[war4peace]

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

Re:Macs had this for years

[tepples]

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

Re:Macs had this for years

[thegarbz]

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:Macs had this for years

[Anonymous Coward]

The REAL problem with Chromebooks is ...well...Chrome! Chrome is known to phone home pretty much any data that Google wants...which is pretty much all data! A Chromebook is really nothing but a vastly overpriced laptop, with a slow processor, not much memory, and little if any local storage. And so called "high end" Chromebooks are just as expensive as a premium laptop, but with less capabilities, and it still runs Chrome...which spies on you! There really is NO upside to Chromebooks. They were always just a bad idea that should have died before it was born.

Re:Macs had this for years

[Anonymous Coward]

"And as a result the mass storage device won't be able to do much more than send keystrokes back and forth." - Maybe.

Re:Macs had this for years

[Cmdln Daco]

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: Macs had this for years

[Anonymous Coward]

Or, you know, look up about Google's own USB Fuzzer efforts to realize that the Linux handling of URBs is questionable. Their move to UAS is actually broken on at least some devices (Seagate Enclosures come to mind) requiring quirks to revert usage, and while I can't verify it as true I have suspicions that issues I've personally experienced with the OOM killer on backing up to such a device when over half of memory is free may come down to either memory fragmentation or just heavy memory leaks.

Basically, USB has been for me on Linux one of the largest minefields of stability in the last 5-10 years. That's both good (in that it's isolated) and bad (in that it seems to have gotten a lot worse as greater feature support has been added). I do not have particular belief that Apple or Windows are fundamentally any better in their own development process to avoid issues, and I presume that being a physical attack vector it has been very much a low priority for most developers/users. Smartphones with encryption are somewhat changing this. I don't know if that will substantially mean something in the desktop/laptop space, though.

Re: Macs had this for years

[nospam007]

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

Re: Macs had this for years

[Anonymous Coward]

Yup. And expect a lot of support issues when trying to copy a large file/s to or from external storage due to device disconnects. Breaks autosynch, etc.

Re:Macs had this for years

[Solandri]

Actually, I suspect the real reason behind this is because Google wants you to use (their) cloud storage, instead of local storage. So rather than simply preventing ChromeOS from running executables located on external media (have to copy it to the Chromebook first), they made so a screen lock will prevent you from doing anything with external storage, like, say playing a music playlist located on a USB flash drive. Oh well, at least they made it optional.

Re: Macs had this for years

[Anonymous Coward]

Oops. Those videos you we're loading failed to copy over due to your screen time out. Now you gotta babysit it and hope your battery lasts long enough.

Re:Macs had this for years

[rtb61]

Well that depends upon how much you spent on your Chromebook, if these prices are anything to go by https://www.techradar.com/news..., 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:Macs had this for years

[war4peace]

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?

[FullCircle]

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?

[Anonymous Coward]

They refer to it internally as charge of the light brigade

Re:Why execute code on mount in the first place?

[munch117]

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: Why execute code on mount in the first place?

[Anonymous Coward]

No getting bye security

Re:Why execute code on mount in the first place?

[gweihir]

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:Why execute code on mount in the first place?

[gweihir]

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. And, realistically, an OS image targeted at non-expert should only come pre-hardened. Of course that causes a lot of user complaints, so the users get insecure configurations instead. Not good.

Re:Why execute code on mount in the first place?

[ZombieCatInABox]

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 ?

Re: Why execute code on mount in the first place?

[Anonymous Coward]

No getting bye security

Congrats, you misspelled a two letter word! The word you wanted is BY, asshole.

Re:Why execute code on mount in the first place?

[thegarbz]

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 the filesystem that was never "executed" and wasn't even a legitimate executable file.

Re:Why execute code on mount in the first place?

[gweihir]

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:Why execute code on mount in the first place?

[AmiMoJo]

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: Why execute code on mount in the first place?

[Anonymous Coward]

Enjoy your special brand of autism

Re:Why execute code on mount in the first place?

[Anonymous Coward]

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 if someone hit the machine with a hammer.

This is nothing but *security* *theatre* to grab a few headlines.

Re:Why execute code on mount in the first place?

[AHuxley]

Because new users are from the OS X and Windows side of computing.
Having to type and use the CLI to get USB working every time is distracting from viewing ads.

Oops! What Keyboard (or mouse)?

[Anonymous Coward]

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

[darkain]

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: Windows XP

[Anonymous Coward]

the ultimate solution (apologies for that phrasing!) is not to swap keyboards while the screen is locked

Re: Windows XP

[Anonymous Coward]

It is because they made em no good

Re:Windows XP

[Anonymous Coward]

Not zero way. Just attach a PS/2 keyboard. (I am talking about Win XP obviously)

Re: Windows XP

[gravewax]

and what about a keyboard that fails or has a drink spilled on it?

Re: Windows XP

[Anonymous Coward]

Isnt that a bit like kicking a man when he is down?

Re:Windows XP

[AmiMoJo]

The commit mentions that there is a whitelist of allowed devices, and presumably HID keyboards are on it.

Re:Windows XP

[darkain]

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:Windows XP

[Waccoon]

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.

Go back to PS/2 connectors.

[Anonymous Coward]

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+ years later there isn't a better solution than a good old text console for righting the wrongs of a computer system.

Re: Go back to PS/2 connectors.

[Anonymous Coward]

PS/2 keyboards do not work on google devices.

Re:Go back to PS/2 connectors.

[Anonymous Coward]

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.

Because they are a major security risk. Encryption reduces the risks of when someone gains physical access, however if the user can bypass everything using those keys than the computer has absolutely no security and any mounted encrypted devices are fair game.

Even 50+ years later there isn't a better solution than a good old text console for righting the wrongs of a computer system.

That's because most true innovation is dead. It's all about graphics and the churn to keep up with hardware support and the churn of formats. We could have a physical, password protected button that when pressed, accesses the CPU's management engine and dumps you into a password protected mini OS. Everything else on the device would be frozen and you'd be able to manually do whatever needs to be done. But no. Instead we have an unprotected set of shortcut keys which rely on the possible failed keyboard device path to be still functional. At a minimum those those shortcut keys should be password protected.

What

[Anonymous Coward]

So you can't copy/backup files unless you leave the computer unlocked? You can't leave it unattended for all that? I guess grab some coffee and settle in so you can watch a progress bar for a couple hours.

Re:What

[tepples]

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:What

[SurenEnfiajyan]

users can enable it by modifying the following Chrome OS flag: chrome://flags/#enable-usbguard

From my understanding, this is not shoved down the users' throats and can be toggled on/off.

Re:What

[Anonymous Coward]

You forgot USB mass storage device *facepalm*

Re:What

[tepples]

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 and a wired home Internet provider as a substitute for backups to USB mass storage.

Autoplay

[Anonymous Coward]

They had to do something in response to Autoplay on Windows. Clearly it's impossible for life to go on without this feature. What will chrome tech support do without all of the security issues this will cause? How will spies easily inject Trojans on victim devices? What will users do when they plug something in and there aren't any annoying popups to dismiss? You're not seeing the big picture here.

Re: Autoplay

[Anonymous Coward]

This a problem lots of big brands have: Mercedes, BMW, Jacuzzi, etc. They get too big for their britches and think they can do anything they want with no market response. Even the average used Mercedes dealer thinks their cars are worth so much because you know they are Mercedes

Re: Autoplay

[Cmdln Daco]

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: Trump

[Anonymous Coward]

Google also. They have CLEARLY worked really hard at being despised for a long time

Not sure what you are getting at there

[SuperKendall]

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:Not sure what you are getting at there

[war4peace]

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:Not sure what you are getting at there

[Anonymous Coward]

Don't bother quoting material information, Kendall doesn't read. I doubt he can but certainly he never would willingly, he's an ideological retard by choice. Reading would destroy his head-in-ass worldview instantly.

Just let him wonder aloud why devices spoofing their ID with underlying h/w driver commands might ever be a well-documented vuln, let the mystery take him to his grave. Reading about it would ruin the experience.

Re:Not sure what you are getting at there

[pushing-robot]

Which raises the question of why ChromeOS would be vulnerable to such an attack while the machine is locked.

Re:Not sure what you are getting at there

[93 Escort Wagon]

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.

Re: Trump

[Anonymous Coward]

I hope they go bankrupt

Yeah

[Anonymous Coward]

That's a no-brainer. All OSs should do that. It shouldn't have ever been a thought.

Re:Yeah

[tepples]

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:Yeah

[SurenEnfiajyan]

Maybe it disables only the USB devices inserted during the screen lock? Also the charger is usually connected via USB interface and I don't think it should (or even could, since it's just a power source) be disabled.

What unattended Chromebook?

[tepples]

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: "Remember: Chrome OS devices are not general-purpose PCs."

Formally verified file system

[tepples]

You just made me curious about whether formal verification 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:Formally verified file system

[gweihir]

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:Formally verified file system

[tlhIngan]

You just made me curious about whether formal verification 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.

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 on a bus driver to provide the physical access to a device (e.g., USB, Firewire, Thunderbolt, SATA, NVMe/PCIe, etc).

It's a whole pile of drivers, any of which may have a vulnerability that can be exploited directly or through a chain.

And for some filesystems, they can be complex, as can be some block drivers and bus drivers.

How you gonna do it?

[tepples]

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: How you gonna do it?

[Anonymous Coward]

Ok that was funny

NSA will nobble the compiler again

[Anonymous Coward]

so it just pretends its working.

Just more crap for Chrome OS

[Anonymous Coward]

Lately I have noticed that Chromebooks especially the educational targeted ones are becoming dog slow. In fact some schools have pretty much abandoned Chromebooks as simply reaching end of usable life far too soon. Not sure if Google is simply pushing premium aspect to business now but they clearly have bloated a otherwise very lean OS into being something other then what it started out as.

Block charging too!

[dohzer]

I don't want those dangerous potentials and currents getting to the battery if I've locked my phone.

keyboard vs storage

[DrYak]

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 inside the full linux container you installed atop of ChromeOS)

- if chromeOS only blocks USB mass storage, like the Apple Mac OS X mentioned above:
you've found/received/etc. a nice USB stick. you plug it into your chromeOS netbook: storage shows up. you're happy with new acquisition and fetch a beer to celebrate. while you away, the screen locks... ...except that this isn't a garden variety plain normal usb mass storage. it's a "Bad USB" (the controller isn't a simple flashtranslation controller, bud a complex CPU running a nefarious software):
while you're away, the micro-controller inside the stick detects the absence of activity, and suddenly exposes a new USB HID device. because that one is a HID and not the forbidden mass storage type, chromeOS happily adds what it thinks looks like a keyboard (even while locked), but is infact the nefarious software in the stick. the Bad USB stick starts to autonomously hack your laptop.

- if the laptop/miniPC/etc. 's port is badly isolated :
you've found/recieved as a present/stole/etc. some nice USB stick.
you plug it in....
except this one is a USB Killer (a batch of high voltage capacitors hidden in the shell of a USB Drive)
your laptop is fried.
its cheap Chinese knock off lithium battery catches fire.
your house get burned.

storage keyboard

[DrYak]

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

Re: storage keyboard

[Anonymous Coward]

Fir? Nothing is Coming up when I search for âoefir bad usbâ

Dr Pedantic here...

[Anonymous Coward]

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

should be

"The way this security feature is meant to work is by preventing the operating system from reading or executing any code when the screen is locked and a USB-based device is plugged in"

Yes, there is a difference.

Re:Dr Pedantic here...

[Herve5]

For me, the way both sentences are written actually means the system *fully halts* when you plug the USB.
I leave it to you to further evolve the text :-D

Yes exactly

[SuperKendall]

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

An USB device can claim to be different things

[Herve5]

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/...
(disclaimer : I am not related to the device or its designer, but I own two, and they have worked fluently for two years on. I decided to buy them when, in the same week, US customers looked at me like a witch when I offered them my data on a company USB stick, and russian ones handed me a nice russian-decorated stick for doing the same...)
R. Fisk is preparing an USB2 version in parallel to this original USB1.

H.

Searches

[DrYak]

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, 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" another relevant keyword to search for is "Rubber ducky"

how about always enabling it?

[sad_]

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.