> Hundreds of thousands, if not millions. The nature of the device has been heavily redacted to protect the guilty. This is rather annoying, and sort of the whole point of responsible disclosure. Disclose the vulnerability to the company, and at some predetermined amount of time later spill the beans, including the vendor. If the company does not want to fix it, the people using the products deserve to know that and…
Cryptographic failures in RF encryption allow stealing robotic devices
11–18 of 18 posts
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#12So are they talking about the Donkey car project? That's the only one that I'm aware of that aligns with what is said in the article.
I suppose they could be talking about any of a variety of drones. They suggest up to millions of affected devices.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#13Earlier quoted context omitted.
I suppose they could be talking about any of a variety of drones. They suggest up to millions of affected devices.
ArduPilot then? Or they are just inventing theoretic vulnerabilities to drum and panic/business. On a second read it feels more like the latter.
A reasonable first approximation would be that all writeups about new vulnerabilities are intended to drum up something, so that's just about the least interesting thing you could say about a post like this.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#14Earlier quoted context omitted.
ArduPilot then? Or they are just inventing theoretic vulnerabilities to drum and panic/business. On a second read it feels more like the latter.
None of these vulnerabilities are "theoretical" (they're maybe a bit stale, is the worst you could say about them). A reasonable first approximation would be that all writeups about new vulnerabilities are intended to drum up something, so that's just about the least interesting thing you could say about a post like this.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#15Earlier quoted context omitted.
None of these vulnerabilities are "theoretical" (they're maybe a bit stale, is the worst you could say about them). A reasonable first approximation would be that all writeups about new vulnerabilities are intended to drum up something, so that's just about the least interesting thing you could say about a post like this.
Theoretical in the sense of actually existing in a widely deployed product such that it can't be responsibly disclosed.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#16Earlier quoted context omitted.
Theoretical in the sense of actually existing in a widely deployed product such that it can't be responsibly disclosed.
I have seen all of these vulnerabilities in widely-deployed products of varying sorts (this was my day job for many years). I don't know who these authors are, I'm just saying that the bugs aren't theoretical.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#17Disclaimer: I happen to work at the same company as authors, not involved in writing this, but I was witness to all research that led to this post. I have seen huge internal arguments on how much and how should be disclosed, given the context (see below), prior to this article being written.
1. I can attest that all these bugs are found in one physical device. I have seen it. Which is really widely used to this day. Moreover, this device has more relatives than we could easily enumerate, some of them potentially vulnerable to a subset of the bugs identified as well. The "vendor" is aware and nothing is changing for a while, in some ways getting worse (blast radius increases over time). This is result of economic reasons, rather than negligence,- "the vendor" in this case is a mixed bag of responsibility between several parties, not all of them commercial, not all of them actually existing to this very date, I believe.
2. In a normal situation, responsible disclosure path, instead of what you've been reading in a post, would be a right way to go. However, context matters in this case: authors happen to live in a country which is at war now (takes like 5 seconds to figure out, looking at the website), so their ability to talk about security vulnerabilities is a bit different to your expectations for reasons that are not very hard to understand. They use vague language, distort a few important details and focus on frivolous illustrations to avoid unnecessary damage.
Pointing out practical exploitability vectors publicly in a way that is understandable to anyone related to the field of practice is sufficiently helpful:
* Some people will now have explanations why their toy cars were stolen and consider changing their supplier of toy car equipment.
* Some people conducting engineering risk analysis will understand that this is not a "potential theoretical vulnerability", looking at their toy car and some of its settings, and consider alternatives.
Consider blog post and examples to be didactic material for an ongoing discussion about some hardware among field practitioners. Authors needed something to point their fingers at and say "this is how X can be exploited to do Y", without reading 2 hours lecture on cryptographic bugs that have been obvious 15 years ago.
3. Why not point out vendor and device list? Consider the context again, please.
It's easy to wave your hand and say "if people are idiots using hardware and devices that are known to be vulnerable, we should let them screw themselves", disclose the name of the vendor, and go on with your life. However:
* Being pointed out directly, these vulnerabilities could easily lead not only to "market levelling out discrepancies" (which does not always happen harmlessly, as we all know). It could lead to more physical damage and deaths immediately happening around authors of this post because exploitation is so easy.
* Not making it would lead to these devices being used over and over again, and obvious cryptographic bugs being dismissed as "theoretical threats", because remote toy car community is full of "Internet of Stuff" people who are dismissing cryptographic vulnerabilities on basis of "it's crypto, who knows how to exploit it, we've got more important stuff to worry about right now".
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#18> Hundreds of thousands, if not millions. The nature of the device has been heavily redacted to protect the guilty. This is rather annoying, and sort of the whole point of responsible disclosure. Disclose the vulnerability to the company, and at some predetermined amount of time later spill the beans, including the vendor. If the company does not want to fix it, the people using the products deserve to know that and…
A valid point. But responsible disclosure in the world of un-patchable devices that actually move and can cause physical harm once pwned feels a little bit different. While we've done things to mitigate a blast radius, publicising guilty names would still lead to lots of damage because you know, these are toy cars.
The only reason not to release names after a reasonable responsible disclosure timeframe is because the researchers somehow think they are the only ones that will ever find that flaw. Pure hubris. Some malicious person will eventually find those same flaws, and then I'm fucked without being given the opportunity to evaluate whether or not I want to risk getting fucked.