I reversed the firmware of my Garmin Forerunner 245 Music back in 2022 and found a dozen or so vulnerabilities in their support for Connect IQ applications. They can be exploited to bypass permissions and compromise the watch. I have published various scripts and proof-of-concept apps to a GitHub repository. Coordinating disclosure with Garmin, some of the vulnerabilities have been around since 2015 and affect over a hundred models, including fitness watches, outdoor handhelds, and GPS for bikes.
Raise your hands if you’re surprised.
Any time someone takes even a cursory glance at internet of things devices or connected anythings that isn’t a well-studied platform from the likes of Apple, Google, or Microsoft, they find boatloads of security issues, dangerous bugs, stupid design decisions, and so much more.
I know many traditional developers hate to hear this, but once again a lot of these problems come down to the use of unsafe languages. Here C and C++ are a huge culprit and have been for decades.
Companies always say they take security seriously, but then internally they keep relying on the legacy languages and development practices that keep producing these vulnerabilities time and time again. In the 80s and 90s this may have been forgivable, but now it’s been clear for decades that a proportion of code written in unsafe languages will always contain vulnerabilities because human errors find their ways into code. Safer languages that prevent these flaws work, but the onus is on us to actually switch to them instead of continuing to use traditional workhorse languages like C, which is something most of us including myself continue to be guilty of. Unfortunately change is hard and it can be easier to go with the flow and keep doing things the wrong way than to switch. So much business continues to run on legacy solutions. I think old generations are going to continue to be driven by habit and the hope for any transition is going to lie with new generations taking over decision making and management jobs with new products, but it’s a very slow process.
Amen. What I find especially strange is that someone hasn’t managed to produce a language that is 99.9% syntactically identical to C and C++ but without all the memory unsafe-ness. I am sure that most of the code out there doesn’t rely on the memory unsafe-ness of C and C++ as a feature. I mean, is there a reason why an array should degenerate into a pointer when passed into a function in a modern C compiler? I am sure that a modern compiler can see when a pointer passed into a function is actually an array and rewrite the code to pass a size argument next to the pointer, and then do bounds checking against it. In addition, is there a reason to use malloc to allocate dynamic arrays in C today?
But I think I know the real answer: performance. Thanks to the dominance of C and C++, most CPUs don’t even have array bounds checking at the hardware level, it has to be done by the compiler itself by emitting instructions to do it, and in our world of performance-over-security, this is not acceptable.
This is why I recommend the Unix Hater’s handbook, even if you actually like Unix (and I do, despite my rants). It details how some architectural decisions made in the 70s and the 80s have consequences that are still with us today. Chief of which being the decision to create “next-gen” RISC processors without hardware-level array bounds checking, because C doesn’t have it as a feature (and by extension, most of Unix). Or why C++ doesn’t have garbage collection because it started out as a hack on top of the C pre-processor. Or why null-terminated strings didn’t die a well-deserved death with the PDP line of computers (modern computers have no reason not to use Pascal strings and allow you to choose between 1,2,3,4-bytes for the length value).
kurkosdr,
I’d actually prefer d-lang syntax to C personally. Unlike rust, the D syntax feels much more familiar, but they fixed many of C’s most common syntactic annoyances, like include files and declaration order dependencies, which I believe are universally despised even among C developers. Regardless, I hear what you are saying and I wholeheartedly agree.
Yeah, sometimes this is true, but the countervailing view is that skipping on checks like string and array bounds is directly responsible for code that causes vulnerabilities and invalid memory access. Most of the time I’d say it was not a deliberate choice to give up security for performance, rather it’s an unintentional oversight. These bugs are much more likely to be accidental than the result of overhead considerations. With this in mind, it becomes harder to argue that safety is a con compared to correct C code.
Another point worth mentioning is that sometimes the checks are free when correctness can be mathematically proven by a language at compile time instead of using traditional run time checks.
You got a chuckle out of me there 🙂
But I agree with your points.
BTW this raises several interesting questions:
1) Is a manufacturer legally obligated to fix security vulnerabilities?
2) What is the legal definition of a security vulnerability?
3) What counts as “fixing” a security vulnerability? Did Microsoft “fix” the security vulnerabilities in secdrv.sys by disabling the feature in Windows 7 and Windows 8.1 (you can enable it with a simple cmd command btw)?
4) For how long should a manufacturer be obligated to fix security vulnerabilities?
Your elected representatives will have to decide on those highly technical questions and pass (or not pass) legislation accordingly, despite being clueless on the matter.
—
Yes, yes, I know… the only internet-connected devices you personally have is your laptop/desktop and your phone. But soon, you won’t be able to buy “non-smart” devices. It’s already a reality with TVs, where all TVs are “smart TVs” with ads on the homepage. How do you know the internet-connected fridge you will have to buy eventually isn’t participating in a botnet network or listening to you via the mic?
Technology is quickly turning dystopian. Time for open-source hardware maybe? What does it take to replicate a LaserJet 4 and a fridge from 20 year ago? Will average Joes and Janes out there buy such hardware if it was available?
kurkosdr,
I’m not against IoT in principal. I’m actually a fan of IoT’s potential but I also worry that technology is headed in a dystopian direction where owners are increasingly taken out of the loop. Many of us have been calling for open hardware, but I feel it could be a case of wishful thinking. Those of us who feel this way simply don’t carry much weight in industry and meanwhile big tech companies prefer promoting technology that gives themselves power over their customers. This includes planned obsolescence, anti features like ads and tracking, vendor locked services, walled gardens, and not giving customers the means to take back control. My prediction is that these trends will continue to become the norm and regulators will do squat about it for decades.
Rejoice: https://en.wikipedia.org/wiki/List_of_open-source_hardware_projects
Spam.
Well, yeah. It’s not just security issues. Bugs of all kinds have always been a thing with Garmin watches. Not necessarily crippling bugs, but annoying ones that get half-fixed with new firmware releases only so new ones can be introduced.
More bad news: Garmin’s latest offerings are now firmly in Apple Watch pricing territory (except the most basic models such as the FR45/55, with bezels and pixelation straight out the 80s)
Even more bad news: Garmin is still probably the overall best we’ve got when it comes to sport watches. Pretty grim.