Bad vs. Less Bad Security Reporting: CoreML vs. Ships
As I was flying home from a meeting today I read two security stories that highlighted the differences between bad and less bad ways to report on security issues. Before I go into them, here is how I evaluate articles related to either stunt hacking or super-popular technology: Is there a real vulnerability? Is it exploitable, and to what degree? What are the actual, known, demonstrable consequences of exploitation? Would other controls or the real-world ecosystem limit either exploitation or impact? Who is writing the article or giving the presentation, who are their sources, and why are they talking about it? How did the vendor/target/whoever respond to the situation, and how is this reflected in the article? These are actually the same criteria I apply to original research reports and conference presentations. Now on to the articles: First, a contact at Apple pointed me to this article by Lily Hay Newman in Wired on “privacy risks” with CoreML. (Let’s be honest: I am known to have a real sore spot for this kind of article – the pointer wasn’t accidental. I’ll save you some time by summing it up: CoreML enables machine learning in apps. These apps can have access to your photos (with permission). Machine learning is hard, so bad actors can sneak in code to do things like find nudies or which products you have in the background of photos. This is against the App Store guidelines, but no one really knows whether Apple would detect it. There’s one small quote at the end from an actual security researcher admitting that such an app could just upload every photo to the cloud if it had this permission anyway. Here is how I’ve been summarizing these kinds of pieces, since basically the start of Securosis: There is a new technology getting some decent attention. Hypothetically someone might be able to do bad stuff with it. Let’s put “iPhone” or “critical infrastructure” in the headline so we get lots of clicks. (This list is growing, though – today I would add cars, airplanes, home automation, electronic toys, and robots/drones). Let’s barely mention that multiple other vendors or product categories have the same capability and often worse security controls. Because iPhones! I want to contrast Wired’s piece with a different piece at BleepingComputer on a backdoor in a satellite Internet system heavily used in shipping. The reason this article is a good contrast is because it starts with a similar premise – a researcher finding an issue and taking it to the press (in this case clearly to get some media coverage). I’m not convinced this basis for articles is usually a good thing because a lot of companies push their researchers for “big” findings like this to get attention. But some are legitimately important issues which do need coverage that vendors or whoever would otherwise try to cover up. In this case: Most ships use a popular satellite Internet system. There is a backdoor (literally named backdoor) in the system, plus another vulnerability. The system is at end-of-life, still in wide use, and will not be patched. The system is for Internet traffic only, not ship control, and the networks are separated. Exploiting this is hard but possible. Although you can’t get into control systems, it could be used for tracking or economic malfeasance. It is at least partially patched, and the vendor warned everyone. The key differences: This was a real exploitable vulnerability, not purely hypothetical. The article clearly defined the scope of potential exploitation. The piece was quickly updated with a statement from the product vendor that indicates the issue may not be even as bad as reported by the security vendor. Or an issue at all any more (but the update should be called out at the top, because it totally undermines the rest of the piece). Now, is this article great? No – the headline and section titles are more hyperbolic than the actual text – editors often do this after a writer submits an article. Also I think the refining statement should be at the top. According to Inmarsat’s statement (after release) the exploit requires physical access and remote exploitation is blocked on shoreside firewalls. The positives of the article are that it mostly balances the risk, highlights a really stupid mistake (the backdoor was insanely easy to exploit) and was based… on reality. Do you want to see a similar situation that involved a real exploit, real risks, a horrible vendor response, and resulting widespread action? Check out this article on a pacemaker recall due to exploitable vulnerabilities. It even highlights issues with how it was handled by both researchers and ÷vendors. Share:
