3 ms·

My reading is that, if I followed the default install instructions (that is included on the CD Liner), that OpenBSD has not been remotely exploitable in the las

My reading is that, if I followed the default install instructions (that is included on the CD Liner), that OpenBSD has not been remotely exploitable in the last 16+ versions. By default OpenBSD has not opened up and ports, daemons, sockets, or other resources that would allow a remote attacker to exploit it. If I wish to start making changes to the default install, that is, modifying /etc/rc.local to start enabling daemons/services, then I need to take responsibility for those changes, and ensure that I stay current with the security issues associated with those daemons/services.

nickpsecurity 11y ago
That's how I read it, too. That's why I'm wondering if it has had a security-related patch or change since the 2nd flaw was found. If it had, then the claim should be modified. If it hasn't, claim might be true. Most making a claim like that... one that's usually wrong.... have data to back it up. Most people's position has been that I should accept it by default, accept reversed burden of proof, and disprove the claim by countless hours of inspection. Whereas, from high-security to mainstream stuff, the status quo has been something is insecure until proven otherwise. I see no reason to change it.
- ghshephard 11y ago
  OpenBSD tracks 100% of exploits/CVEs, as well as patches in their daily change log. See: http://www.openbsd.org/plus.html http://www.openbsd.org/plus.html, http://www.openbsd.org/plus58.html http://www.openbsd.org/plus58.html, http://www.openbsd.org/plus57.html http://www.openbsd.org/plus57.html, etc... There have been no remote exploits in the last 8 years in the default install.
  - nickpsecurity 11y ago
    That conclusion doesn't follow from the links unless they attempted to produce exploits from each potentially, exploitable defect to confirm or reject whether it was a vulnerability. Like what happens with disclosures in many projects. The truth is that they've fixed many problems in the kernel in the last 8 years which may or may not have been exploitable. They're only sure about two of them with a policy to not check the rest as their time is better spent fixing everything and moving on. I agree with that approach but it makes their 2 vulnerability claim impossible it wasn't tested on defect data. My theory is supported by another post: https://news.ycombinator.com/item?id=10337807 https://news.ycombinator.com/item?id=10337807 So, I'm dismissing their claim entirely and will counter it with their claims linked above along with my argument. However, even without that claim, the OpenBSD team can still make a great argument based on their QA processes and track record in fixing things as you linked. It will certainly have fewer 0-days than anything else which is why I told another OpenBSD developer I recommended Xen projects use it for Dom0 wherever possible. Btw, thanks for the links. It answers the question about their defect tracking in general. Lots of detail in there and evidence of their QA working. As I expected. I'm keeping it to share if the topic comes up in another discussion.

nickpsecurity 11y ago

That's how I read it, too. That's why I'm wondering if it has had a security-related patch or change since the 2nd flaw was found. If it had, then the claim should be modified. If it hasn't, claim might be true. Most making a claim like that... one that's usually wrong.... have data to back it up. Most people's position has been that I should accept it by default, accept reversed burden of proof, and disprove the claim by countless hours of inspection. Whereas, from high-security to mainstream stuff, the status quo has been something is insecure until proven otherwise. I see no reason to change it.

ghshephard 11y ago
OpenBSD tracks 100% of exploits/CVEs, as well as patches in their daily change log. See: http://www.openbsd.org/plus.html http://www.openbsd.org/plus.html, http://www.openbsd.org/plus58.html http://www.openbsd.org/plus58.html, http://www.openbsd.org/plus57.html http://www.openbsd.org/plus57.html, etc... There have been no remote exploits in the last 8 years in the default install.
- nickpsecurity 11y ago
  That conclusion doesn't follow from the links unless they attempted to produce exploits from each potentially, exploitable defect to confirm or reject whether it was a vulnerability. Like what happens with disclosures in many projects. The truth is that they've fixed many problems in the kernel in the last 8 years which may or may not have been exploitable. They're only sure about two of them with a policy to not check the rest as their time is better spent fixing everything and moving on. I agree with that approach but it makes their 2 vulnerability claim impossible it wasn't tested on defect data. My theory is supported by another post: https://news.ycombinator.com/item?id=10337807 https://news.ycombinator.com/item?id=10337807 So, I'm dismissing their claim entirely and will counter it with their claims linked above along with my argument. However, even without that claim, the OpenBSD team can still make a great argument based on their QA processes and track record in fixing things as you linked. It will certainly have fewer 0-days than anything else which is why I told another OpenBSD developer I recommended Xen projects use it for Dom0 wherever possible. Btw, thanks for the links. It answers the question about their defect tracking in general. Lots of detail in there and evidence of their QA working. As I expected. I'm keeping it to share if the topic comes up in another discussion.