Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
Security by obscurity is never a good idea, but especially not when it might prevent a white hat from finding a bug that would allow a malicious actor to remotely STOP MY HEART.
1) White hat finds a vulnerability in the source code which applies to a large number of devices. 2) Source is patched but vulnerable devices exist in wild
Now all an attacker needs to do is find a vulnerable device; because the source code is public like OP suggests, figuring out which devices are vulnerable is trivial.
Unless I'm missing something drastic, this is actually a problem in the embedded space where obscurity seems to help.
Tell me, how many vulnerabilities are running wild on Linux, the software that powers... well, pretty much anything (including the servers through which you read this content)? Even if you find a vulnerability, it gets patched within hours and it may take a day or two for it to be distributed to everyone.
> Security by obscurity [...] does raise the barrier to entry for script kiddies.
Which script can help you find a vulnerability inside of the source code? You'll need a script that can understand the code it's looking at. I'm not aware of any such script.
I'm not advocating for security by obscurity in the slightest because on balance I think it's bad, but we should acknowledge that publishing your source does change the potential cost of mounting an attack in various scenarios, and some of them might actually favor obscurity.
Nobody except the most determined attacker will attack a device with some custom, unpublished code. On the other hand, popular software have a variety of exploits in the wild because their popularity makes them more attractive targets, one consequence of which is enabling script kiddies (since the hard work can be outsourced).
> it gets patched within hours and it may take a day or two for it to be distributed to everyone
This doesn't work for embedded devices. Hence why it might not be a great idea to publish their vulnerabilities, or tell the whole world that you're running on old vulnerable source.
This is patently incorrect. Even the underpowered Z80-clone micros with 18kB RAM I was writing firmware for 15 years ago had trivially updated firmware; modern devices are even easier.
The article even mentions that wireless firmware updates is a feature:
Then she bought a pacemaker programmer online,
and she and other hackers figured out that it
could be used to update the code on her implant.
> Nobody except the most determined attacker will attackRelying on the laziness and ignorance of the attacker is a terrible idea.
> Hence why it might not be a great idea to publish their vulnerabilities
This is why any it's important to practice responsible disclosure. The manufacturer should have a reasonable time to make their patch before telling the internet.
We live in a world where even phones don't get patched as frequently as they should; you expect end users to patch their pacemakers?
Putting them online and allowing auto-patching would probably be worse since it also increases their attack surface drastically.
> This is why any it's important to practice responsible disclosure.
Right, and fact is that 'responsible disclosure' ends up looking a lot like obscurity in a world where you can't guarantee that devices will be patched before an attacker would be interested in exploitation.
I have no idea what the current patch rate is for pacemakers, but they do happen. The use of radio was a feature specifically to allow updating and management of the pacemakers while avoiding the serious risks of surgery. The pacemakers would be patched when the patient shows up for their next checkup appointment, which is probably every 1-2 months. They already connect to the devices for regular diagnostic purposes at those times.
If the problem was severe enough, calls would be made to the patients to come in right away. Medical services already handle problems on a priority basis ("triage"). This already happens for other types of problems.
> 'responsible disclosure' ends up looking a lot like obscurity
That's a circular argument. You're implying that the manufacturer wouldn't want to fix their product, which is highly unlikely. The only reason they are resistant to the idea at present is because the source is closed. The entire point is that by opening up the source the community can work with the manufacturers to fix these problems.
You're arguing that because the current system currently doesn't patch bugs that often, we shouldn't allow more debugging. Pretending that either bugs don't exist or that malicious actors won't find them without the source code is dangerous. "Pride goes before the fall"; do you really want to bet - potentially with your life - that all malicious actors are too stupid to find security problems? Hint: many medical devices have already been hacked (without the source). Or do you want to let the community at least attempt to find the bugs first?
In other words, it's a ready-made vector for potential attacks, as long as an attacker can get close to a pacemaker with a radio. You could probably even put a powerful device near a hospital and pick up random people coming and going.
> Or do you want to let the community at least _attempt_ to find the bugs first?
The promise of open-source security has always been that you let many eyes look for problems, then you patch ahead of potential attackers.
Logistically, that's extremely problematic for embedded devices. Every time a vulnerability is found, you ask the patient to go back to the doctor to get it updated? That doesn't scale at all.
The idea that device manufacturers will change their entire engineering and security philosophy is somewhere between idealistic and naive. I sincerely hope it's the former and not the latter.
Now there is an argument that there is a trivial way to find vulnerabilities in Open Source code - just diff the commits to look for fixed bugs, and attack those who didn't manage to update their software yet. That's part of the reason why e.g. Wordpress blogs and PHPBB forums get spammed so heavily.
Whether or not the benefits of Open Source are greater than those problems is another topic, but let's not pretend opensourcing doesn't lower the entry bar for attackers.