Slashdot Mirror
Medtronic Locks Down Vulnerable Pacemaker Programming Kit Due To Cybersecurity Concerns (theregister.co.uk)
AmiMoJo shares a report from The Register: The U.S. Food and Drug Administration (FDA) is advising health professionals to keep an eye on some of the equipment they use to monitor pacemakers and other heart implants. The watchdog's alert this week comes after Irish medical device maker Medtronic said it will lock some of its equipment out of its software update service, meaning the hardware can't download and install new code from its servers. That may seem counterintuitive, however, it turns out security vulnerabilities in its technology that it had previously thought could only be exploited locally could actually be exploited via its software update network. Malicious updates could be pushed to Medtronic devices by hackers intercepting and tampering with the equipment's internet connections -- the machines would not verify they were actually downloading legit Medtronic firmware -- and so the biz has cut them off.
We're talking a device which when it malfunctions, kills (or could kill) someone. And still the manufacturer didn't get the basics of security correct: using signed software updates.
How can we believe that IoT devices, which are manufactured with much less profit overhead, will be more secure? (Unless somehow regulated -- which also didn't for for those FDA-approved pacemakers).
cease fire stand down.. extrapolate along,, https://www.youtube.com/watch?v=T-6FmYqIeps
The federal deficit has soared 17 percent in the president’s first fiscal year. Other people's money is running out again, "conservatives"? - https://www.huffingtonpost.com...
Never mind that, just keep repeating the line that trump is the best thing ever and eveything is better than it ever has been as everything will be just fine, the truth is irrelevant.
The original company stops making updates available.
Before that, a hacker could impersonate the update server (probably using a MITM attack) so the device received a hacked firmware, not the legit one. But if no hacking occurs, the device receives a legit update.
After the change, if a hacker impersonates the (unavailable) update server, the device can only find the hacked firmware, never the legit one.
How is this exactly improving security?
From the article:
The security bugs are not present in the implants themselves, but rather in Medtronic "programmers," which doctors and medics connect to patients' implants during and after surgery, allowing them to check battery levels, monitor heart rhythms, and adjust any settings.
So -in this case- it's not patients' pacemakers etc at risk, but the equipment that monitors those pacemakers & perhaps adjust their settings. I'd imagine that as a hacker, you could (perhaps) still do some damage like adjust settings to the point where a pacemaker becomes ineffective. But this is rather different from upload-compromised-firmware-to-implant, which the summary might suggest to some.
there is "certainly a potential health risk".
I worked for a competitor to Medtronics that manufactured pacemakers in the 90s. The "state of the art" communication with the IC was an antenna that used PWM to talk. As long as you knew the handshake you could program it however you wanted. But if you wanted to be malicious you didn't even need to go to that much trouble. Many remember the signs posted in convenient stores that had microwave ovens because the stray noise from them could literally wipe out the programming on a pacemaker.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Free Software developers of the world, open your eyes! Our communities are being raped, our work pillaged.
Detestable villains - thieving, mean spirited, belligerent, racist, unprincipled - are using underhanded tricks to force hypocritical "Codes of Conduct" on the projects we built.
These petty-authoritarian CoCs are always imposed anti-democratically. There is never free debate, and usually no public discussion at all. They are imposed by force without a vote. If the CoCs were put up for a fair democratic vote by project contributors, they would always lose by a landslide.
The purpose of these CoCs is to allow social activists, who have contributed nothing to the project, to conduct witch hunts against anyone who opposes their hate-driven agenda. Thereby they plan to steal our work for their shadowy corporate paymasters.
You can readily tell these CoCs are not about "just being nice" - because they are ALWAYS supported by the very LEAST NICE, most aggressively mean and shamelessly bigoted people you can imagine. Look how the CoC-mongers treat anyone who disagrees with them as subhuman.
If a project to which you contribute has been raped by CoC-mongers there is a simple solution: WALK AWAY. Never contribute again. If you have a patch almost ready, count the time you spent on it as a loss and throw it away. If you see a security issue, remain silent and do nothing. IT'S NO LONGER YOUR PROJECT. YOU ARE NOT WELCOME THERE.
If you are evaluating new software, don't even consider any projects burdened under the tyranny of a CoC. Their technical attributes do not matter - just don't consider them. Never be openly political, always make up a technical reason for rejecting CoCed projects.
Don't argue in public about the CoC. Doing so only exposes you to needless risk. You might be dis-employed, blackballed, and even set up for a #MeToo purge. Just stay far away. If you resign from a project that gets CoCed, try to do so on the same day the CoC is imposed. But give "spend more time with friends & family" or "pursue other interests & projects" as your reason for resignation. Protect yourself!
Comrades: Individually we are powerless, and easily crushed beneath the iron boot of Corporate Social Just-Us. But together in solidarity we are millions and we are strong. The Internet itself depends on our collective labor. If we stop working, the internet stops working.
Free Software developers, save yourselves and save your communities! Just WALK AWAY from any project with a CoC. Without our labor they are nothing.
Sign the code with a private key and compare a hash. Secure devices have been doing this for some time.
https://www.fsf.org/associate/support_freedom
There are no "security" problems in these devices. Read the articles properly people and stop adding your "interpretation".
As usual this is all overblown bullshit by the likes of marxists who want to force companies to "open source" there products to protect the feelings of snowflakes.
Now that grandpa can't be overclocked, who's gonna play football with me.
I wish I could say I'm surprised, or I'm shocked ... but the reality is, most consumer electronics have shit security, and from what I've heard most medical devices have even less.
There's only one solution to this ... companies bear full legal liability for the security of their products. None of this "oh, we tried but we're just too stupid", but full legal liability leading to huge fines and sanctions.
The less actual security you had, the higher the penalties, so that all of those default passwords and backdoors should lead to a company being crippled financially. If you're a medical device company and someone dies because you had little or no security, your CEO is criminally liable.
Until this happens, shit security written by morons at the encouragement of greedy assholes will be the norm.
This is why the overwhelming majority of network connected things are complete and utter garbage, and not something I will buy. Until most consumer electronics companies demonstrate actual abilities to implement security, I'm going to keep assuming most of it is shit, and not waste my money on it.
And we're a long way from that changing.
I write embedded firmware for a living. Someone mentioned using keys/certificates. I don't see how such a small device with limited power can deal with the heft of full digital security.
Further, it's a pacemaker! It does the same thing as they did decades ago, no? Why are there even post-factory updates?!
I write embedded firmware for a living.
I write embedded firmware for a living too. I can't think of a microprocessor made in the last 10 years that doesn't have hardware crypto instructions.
Maybe you should update your skills.
...medical device maker Medtronic said it will lock some of its equipment out of its software update service, meaning the hardware can't download and install new code from its servers. That may seem counterintuitive... Malicious updates could be pushed to Medtronic devices by hackers intercepting and tampering with the equipment's internet connections -- the machines would not verify they were actually downloading legit Medtronic firmware -- and so the biz has cut them off.
If this is right, locking them out of the service on the server side doesn't do a damn thing. You need to tell the devices to stop "looking for updates". All this does is let's me know that if I got an update after the shutdown then it's fake.
Cutting off the server side still allows a device to look for updates and if a man-in-the-middle answers it will allow the update, because the whole problem is that it's not verifying the update's source.
I refuse to sign
I thought Hacknet was full it, but here I see I was wrong. That event just seemed a little.. too far.. on the far side of the reality bright-line. Whoops.
https://store.steampowered.com...
In the microcontroller market (not embedded PC), an X.509 certificate might be larger than available RAM. Some of those chips don't even have hardware multipliers, let alone crypto instructions. And frankly, I'd consider a PIC16 overkill for a pacemaker.
Cardiac surgeons aren't stupid.