7 ms·

3> has nothing to do with the code being OS, wherether or not a device is locked down is independent of that.

smallnamespace 10y ago
Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.
- r3bl 10y ago
  No. 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.
  - smallnamespace 10y ago
    If the same vulnerability is present across a large range of devices, a public exploit has a much larger impact. 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.
    - pdkl95 10y ago
      > This doesn't work for embedded devices. 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 attack Relying 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.
      - smallnamespace 10y ago
        Even if embedded devices are updatable in principle, in practice how often do they receive security patches? Pointing to a feature list isn't a realistic evaluation of what actually happens. 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.
        pdkl95 10y ago
        > in practice how often do they receive security patches? 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?
  - TeMPOraL 10y ago
    In the interest of honesty - first of all, "it gets patched within hours and it may take a day or two for it to be distributed to everyone" is not true. No matter how fast a vulnerability is patched, the distribution process usually takes days to weeks (c.f. Heartbleed bug, Canonical was apparently the first to find and fix it, and yet I've waited weeks to get the fix on my Ubuntu machine) for those who care and monitor those issues constantly, and months to years for everyone else. 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.
- wadetandy 10y ago
  Anyone you're likely to classify as a "script kiddy" is not going to be able to read the kind of code going into embedded devices like a pacemaker to a deep enough level to find any problems. And if they can the software is really problematic, most likely. 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.
  - smallnamespace 10y ago
    I agree with you in general, but since we're talking about embedded devices that can't be updated, here's a concrete scenario: 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.

Maybe in a complete vacuum, but in reality, having access to source certainly makes it easier to look for vulnerabilities, and if the same software is in many devices, the cost of finding vulnerabilities is amortized. Security by obscurity obviously doesn't stop a determined attacker, but it does raise the barrier to entry for script kiddies.

r3bl 10y ago
No. 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.
- smallnamespace 10y ago
  If the same vulnerability is present across a large range of devices, a public exploit has a much larger impact. 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.
  - pdkl95 10y ago
    > This doesn't work for embedded devices. 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 attack Relying 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.
    - smallnamespace 10y ago
      Even if embedded devices are updatable in principle, in practice how often do they receive security patches? Pointing to a feature list isn't a realistic evaluation of what actually happens. 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.
      - pdkl95 10y ago
        > in practice how often do they receive security patches? 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?
- TeMPOraL 10y ago
  In the interest of honesty - first of all, "it gets patched within hours and it may take a day or two for it to be distributed to everyone" is not true. No matter how fast a vulnerability is patched, the distribution process usually takes days to weeks (c.f. Heartbleed bug, Canonical was apparently the first to find and fix it, and yet I've waited weeks to get the fix on my Ubuntu machine) for those who care and monitor those issues constantly, and months to years for everyone else. 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.
wadetandy 10y ago
Anyone you're likely to classify as a "script kiddy" is not going to be able to read the kind of code going into embedded devices like a pacemaker to a deep enough level to find any problems. And if they can the software is really problematic, most likely. 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.
- smallnamespace 10y ago
  I agree with you in general, but since we're talking about embedded devices that can't be updated, here's a concrete scenario: 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.