Lock up your top-of-racks, says Cisco, there's a bug in the USB code It's 2015, and the right stuff on a USB stick can still crash a substantial switch. Cisco hasn't yet worked out how to fix this vulnerability, and as a result, the details it offers in the advisory are sparse. What we can glean from the note is that the crash can only be triggered by a local user. Here's how Cisco explain the …
Ummmmm, do we need to bring up the vulnerability of a ethernet cable being unplugged when it is out in the open? It is 2015 folks and most of us have been locking equipment in special closets or in data centers for years. Anyone who has their stuff open to the world is just asking for trouble.
It's 2015, and there are still far too many hardware manufacturers that naively trust anything that can be plugged in, read from, or sent to their devices. We live in a world where all developers from the low-level device I/O guys to the top-level app developers need to assume that someone somewhere at some point try to send malicious data to them, and code appropriately.
It's a bad bad world out there. Assume malicious intent from any data you receive.
“The vulnerability is due to insufficient handling of USB input parameters. An attacker could exploit this vulnerability by sending crafted USB parameters to be processed by the kernel of an affected device”
What exactly does the buzzword bingo mean? It could be read as the drivers are garbage.
Sanity validation should be performed at all stack layers from devices up to applicatin services. All input should be considered likely to be invalid from network, USB, and any other input device, peripherals...
Failure to do so encourages impossible to diagnose "unknown error" code, and exposes a risk of both malicious and simply rubbish code to cause confusion, delay, and exploitation.
/EndRant
"unknown error"
This one always gets me. Is an unknown error better or worse than a known error?
On the one hand, how does the software know there's an error if the error's unknown?
On the other hand, if the error's known, why didn't the developer fix it before shipping the software?
>can you tell us a foolproof way of ensuring that all inputs every are always checked for every possible invalid value
First of all, do not -- repeat *not* -- automatically execute code from anything plugged into a system. Second, if you're using a 'proper' OS disable automatic mounting of an external drive.
Third, particularly important for embedded systems, is that all input data needs to be checked for off-the-wall values. If its configuration data that's legal but could cause improper operation of the unit in its target environment then you need to control who gets access and why.
Simple stuff. Routine for programmers -- at least it should be. Unfortunately we're plagued with people who only know Windows like end user systems, who think its natural for USB sticks to automatically mount themselves and run code because they're USB sticks. Its time to learn the truth -- all storage, USB sticks included, is harmless unless you use the data on it.
Reading the data may not be necessary to hit the problem - from the description it sounds more like a vulnerability in either the USB protocol code or the filesystem driver, so the exploit would involve a USB stick with customised firmware on its microcontroller, or a custom filesystem creator to write wacky stuff into filesystem metadata.
Dear armchair developers, can you tell us a foolproof way of ensuring that all inputs every[sic] are always checked for every possible invalid value so we can prevent this from happening again?
Sure thing. Check for valid values instead and discard anything else.
Yes, yes, I know that's not always a simple task, but I do think many software vulnerabilities could be avoided if developers were in the habit of always checking that input is exactly the type of input expected before acting on it in any way.
If you're expecting a record containing 3 fields, it's much better to verify it really contains 3 fields before you go on to the next step, instead of hoping to catch the error when something goes wrong because it contained 2 or 4.
Dear armchair developers, can you tell us a foolproof way of ensuring that all inputs every are always checked for every possible invalid
Yes, we could - but you Real People out there in the "Real World(tm)" wouldn't be able to understand it and why should you; you know every truth there ever was already.
PS:
Inverse the the problem, your proposed "Check all Possible States of the Universe" becomes "Only handle what "you" *know* *how* to handle and reject everything else". Compilers work like that and everything plugged into the live Internet does too.
PSPS:
It's not an arm chair that I have here, it's a massage chair. Leather. Details matter.
. . . but people do inadvertently pick up the wrong stick, forget what they MEANT to do/WERE doing, not realise that they've picked up some malware, etc. etc. The information doesn't provide any information that specifies associated user actions which implies that just inserting the USB stick may be enough.
The person doesn't need to be malicious for bad things to happen.
Covertly setting up eavesdropping on installed gear, or installing backdoors during maintenance or equipment delivery... these are both things that happen:
https://www.techdirt.com/articles/20140124/10564825981/nsa-interception-action-tor-developers-computer-gets-mysteriously-re-routed-to-virginia.shtml
So, what they are saying is that, given physical access, someone with a specially crafted USB key can cause a denial of service. What about just pulling the power cord? Denial of service achieved, and much less time-consuming than going to the lengths of creating that magic USB key.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
