3 ms·

> Less safe than what? World A contains an archive of concentrated vulnerability information. World B doesn't. World A is strictly less safe than World B, beca

by pdkl95 10y ago

> Less safe than what? World A contains an archive of concentrated vulnerability information. World B doesn't. World A is strictly less safe than World B, because concentrating information creates a more attractive target. Without that concentrated archive, the vulnerabilities would have to be discovered on their own. Do you really want to argue that allowing the archive of stolen tools recently released by the "Shadow Brokers" didn't make people less safe? Even though it contained attacks on various routers that were previously unknown? Is it really your assertion that those same tools were never used before the "action" announcement? > the idea that we should ignore that Nobody is saying that. Where did you get the idea that we should ignore vulnerabilities? > could be developed by anyone who works long enough Obviously, which is why I also discussed the hoarding of vulnerability knowledge. Maybe all of those vulnerabilities would have been discovered independently, but stealing the archive from the NSA would have been a lot easier and faster. These are not traits you can simply brush off as irrelevant, as most security is not about perfection, but instead about how long the security features will delay an attacker. > scapegoats This isn't about finding a scapegoat. The NSA making us less safe is the "bad decision" that needs to be recognized.

ryao 10y ago
My point is that research or even exploitation is not causation of security flaws. The flaws themselves are what make people insecure and ignoring that by complaining about people researching them for whatever reason suggests that we should ignore security flaws and just blame anyone who looks. The release of the concentrated archive will help security in the long term the same way that a fire that burns down a city improves fire safety in the long term by encouraging changes to building codes. Ideally, such things should have been done already, but people tend to only fix things after something catastrophic happens. Hopefully, people will realize that they need to adopt solutions that are more resilient. That means equipment running fully open source solutions such as PFSense, OpenBSD, LEDE, etcetera.
- wepple 10y ago
  The NSA would have a cache of remote code exec exploits in PFSense if they actually cared about exploiting. But they don't.
  - ryao 10y ago
    PFSense is much easier to audit than the closed source stuff that the disclosed zero days targeted. Anything that they find in it is far more likely to be found by others and patched. It is a fundamental improvement that you only can get with OSS. That being said, organizations doing what the NSA does will always exist. Making decisions based on that premise that will lead to a much better result than blaming them for flaws in the things people use ever will.
    - wepple 10y ago
      I definitely agree with your premise, that OSS can more easily be reviewed. In reality, do you think/know that happens? (I'm genuinely intrigued). I know almost all major software shops generally have some kind of formalized process for internal and external security review; and often have automated tooling to also support that process. I'm not saying it's perfect, but it's there, and catches a lot of bugs. Running with PFSense as our example, do they have regular codebase-wide and change-specific code reviews and security assessments? I'd be delighted to know they do, but haven't seen much about it.
      - ryao 10y ago
        There are tools being such as coverity run on it: https://www.google.com/#q=coverity+pfsense https://www.google.com/#q=coverity+pfsense https://www.google.com/#q=coverity+freebsd https://www.google.com/#q=coverity+freebsd That is a rather good tool provided to open source projects for free that finds bugs, including exploitable bugs. FreeBSD and pfSense by extension has the benefit of Clang's various tools for catching issues (e.g. its static analysis, address sanitizer, etcetera). I also know that there was a TrustedBSD hardening effort. You probably would want to ask the pfSense and FreeBSD guys for details. There are better people than me to ask, but given that it is open source the people doing things are under no obligation to talk about it, it is hard for anyone to know everything being done. Anyway, my point is that these sorts of things only happen with OSS. If a search researcher has an idea for a new way of catching bugs, he is likely going to use it on OSS code rather than closed source software by virtue of it being easier to do experiments on it. The same goes for non-profits devoting money to auditing code (which the Linux Foundation announced last year). You definitely will not see that happen with proprietary software. This gives OSS an intrinsic advantage.

by pdkl95 10y ago

ryao 10y ago

My point is that research or even exploitation is not causation of security flaws. The flaws themselves are what make people insecure and ignoring that by complaining about people researching them for whatever reason suggests that we should ignore security flaws and just blame anyone who looks. The release of the concentrated archive will help security in the long term the same way that a fire that burns down a city improves fire safety in the long term by encouraging changes to building codes. Ideally, such things should have been done already, but people tend to only fix things after something catastrophic happens. Hopefully, people will realize that they need to adopt solutions that are more resilient. That means equipment running fully open source solutions such as PFSense, OpenBSD, LEDE, etcetera.

wepple 10y ago
The NSA would have a cache of remote code exec exploits in PFSense if they actually cared about exploiting. But they don't.
- ryao 10y ago
  PFSense is much easier to audit than the closed source stuff that the disclosed zero days targeted. Anything that they find in it is far more likely to be found by others and patched. It is a fundamental improvement that you only can get with OSS. That being said, organizations doing what the NSA does will always exist. Making decisions based on that premise that will lead to a much better result than blaming them for flaws in the things people use ever will.
  - wepple 10y ago
    I definitely agree with your premise, that OSS can more easily be reviewed. In reality, do you think/know that happens? (I'm genuinely intrigued). I know almost all major software shops generally have some kind of formalized process for internal and external security review; and often have automated tooling to also support that process. I'm not saying it's perfect, but it's there, and catches a lot of bugs. Running with PFSense as our example, do they have regular codebase-wide and change-specific code reviews and security assessments? I'd be delighted to know they do, but haven't seen much about it.
    - ryao 10y ago
      There are tools being such as coverity run on it: https://www.google.com/#q=coverity+pfsense https://www.google.com/#q=coverity+pfsense https://www.google.com/#q=coverity+freebsd https://www.google.com/#q=coverity+freebsd That is a rather good tool provided to open source projects for free that finds bugs, including exploitable bugs. FreeBSD and pfSense by extension has the benefit of Clang's various tools for catching issues (e.g. its static analysis, address sanitizer, etcetera). I also know that there was a TrustedBSD hardening effort. You probably would want to ask the pfSense and FreeBSD guys for details. There are better people than me to ask, but given that it is open source the people doing things are under no obligation to talk about it, it is hard for anyone to know everything being done. Anyway, my point is that these sorts of things only happen with OSS. If a search researcher has an idea for a new way of catching bugs, he is likely going to use it on OSS code rather than closed source software by virtue of it being easier to do experiments on it. The same goes for non-profits devoting money to auditing code (which the Linux Foundation announced last year). You definitely will not see that happen with proprietary software. This gives OSS an intrinsic advantage.