7 ms·

no, the claim is the default install. anything you install afterwards is...not the default.

by pyvpx 11y ago

nickpsecurity 11y ago
So, the claim is meaningless for most users unless they restrict themselves to the tiniest subset of software. That answers the first question. Ok, so the second is, "Have there been defects found in any parts of the default install after those parts were distributed? And were they just fixed or analyzed for exploitability with an update on the website if necessary?"
- jethro_tell 11y ago
  It's generally a security by obscurity claim. Which is strange coming from the OpenBSD guys. I don't think you can even log in with their own OpenSSHd from a default install.
  - nickpsecurity 11y ago
    That's what I'm thinking and suggesting. Because, if we get down to it, anyone reading the claim would have to believe something along these lines: 1. There's never been a defect that could affect security in any OpenBSD software, from kernel to protocols, after it was released. 2. For meaningfulness, the default install supports real-world usage (and usefulness) of the system. The good news for No 1 means that they never had to issue a patch in a protocol or software due to defects with potential to leak data, allow hijacking, or experience DOS. Knowing that, once released, every OpenBSD system was unhackable and needs no patches past functionality fixes would greatly reduce administrator overhead. Truly fire-and-forget system. If the website claim is true, that is. :) Further, if No 2 is true, users won't have to use anything but the base install to handle day-to-day tasks on their network. Anything critical is included, usable, and secure-by-default. Users would only need to rely on 3rd party stuff for non-obvious use cases or stuff that truly doesn't belong in a baseline. So, the ports collection wouldn't even be necessary in most deployments (esp infrastructure, console desktop) as the functionality and what counts in security claims were batteries included like the competition. I'll leave it to users and people following their bug trackers to determine if either is the case. Especially No 1 which is my main point. The mere existence of security patches would kill the web site claim. It would instead become, "Of all the defects found, only two were analyzed and shown to be exploitable over X years." Makes for a totally different impression, eh? ;)
    - slasaus 11y ago
      I think most of your posts are very informative. But your lack of knowledge about OpenBSD surprises me. Perhaps it would save you and the reader some time if you spent a bit more reading about OpenBSD instead of reasoning about all theoretical directions OpenBSD could have taken.
      - nickpsecurity 11y ago
        Appreciate it. Far as lack of knowledge, a brain injury in an accident cost me most of my hands-on IT skills and many details in INFOSEC. Among other things... However, the stuff I did repeatedly, like high-level security engineering and assessments, stays with me. Barely relevant here even though it makes plenty of sense that you'd think that. The short-cut around it is the concept of burden of proof in INFOSEC: one is expected to back up their big, security claims with evidence rather than everyone else expected to disprove them. I certainly could dig back into OpenBSD (and C) to fully understand its current situation, its code, its mitigations, every source change from vulnerability 2, and so on. Those details could benefit OpenBSD in form of contributions I attempt or the reader following along to get a better picture of insides. However, it's not necessary for evaluating my concern about the 2 vulnerability claim. We can cleverly cheat around all that knowledge by going straight to fundamentals and claim itself. Then, only acquiring (me) and/or applying (others) that knowledge if the specialist skill turns out to be required. Others and I did this with success when drowning in product and project security claims with finite time to review them. Let's apply that. "instead of reasoning about all theoretical directions OpenBSD could have taken." My main question is a simple, concrete one that I shouldn't have to investigate at all: what evidence is there that there have only been 2 exploitable flaws in all OpenBSD releases? To claim this, there would have to be a tracker of every defect fixed in OpenBSD since its inception, an analysis of each one's exploitability, and a result saying only two were exploitable. There's trackers like that for many projects. Where's that record for OpenBSD or, to save you time, do they even analyze every bug for exploitability? If that doesn't exist or that analysis wasn't done, then the only 2 vulnerability claim can be rejected immediately because it wasn't proven. Instead, the claim becomes "Of all X defects found, people only showed two were exploitable remotely. (Optionally) That's a defect ratio of X per Kloc with vulnerability ratio of Y per Kloc. (Not optional) The rest either weren't assessed for severity or were shown harmless." Alternatively, the claim is totally false if even one security fix for a remote attack was done after the 2nd vulnerability was fixed. It would have to be changed to a maybe pending further, specialist analysis. This isn't theoretical: it's a direct implication of the claim they're making, an extraordinary implication, and one which deserves concrete evidence to back it. So, I encourage people to reject it until they have that evidence and in a way they can share easily. If I have time or resources, I might attempt a thorough assessment of OpenBSD in terms of design or code. A past study I did comparing it to prior secure UNIX attempts showed some things it's missing where there's surely issues. It has some other attributes, esp code quality & protections, that help it more than others (including old ones). Nonetheless, the issue I have is an extraordinary claim that pops up repeatedly in discussions over OpenBSD vs whatever with no evidence to back it and high chance of failure. See the problem? Also, do you see how I don't need to be an OpenBSD developer to spot it?
  - tedunangst 11y ago
    You can. There's an option to turn off, but it starts on.
- tedunangst 11y ago
  The claim is quite old, and comes from an era where a fresh install of an operating system would have web servers and DNS servers and file servers globally exposed. Many projects have adjusted since then, but there was definitely an era of Apache worms that could spread juat by pwning the default "it's working!" Web site that many operators didn't even know they were running.
  - nickpsecurity 11y ago
    Best explanation I've heard. Still supports my concern more than the claim's truth. Nonetheless, I can totally understand that given I was around back then and remember what that was like. It would certainly have been a differentiator back then before sane defaults were a thing.

no, the claim is the default install. anything you install afterwards is...not the default.

by pyvpx 11y ago

no, the claim is the default install. anything you install afterwards is...not the default.

So, the claim is meaningless for most users unless they restrict themselves to the tiniest subset of software. That answers the first question. Ok, so the second is, "Have there been defects found in any parts of the default install after those parts were distributed? And were they just fixed or analyzed for exploitability with an update on the website if necessary?"

jethro_tell 11y ago
It's generally a security by obscurity claim. Which is strange coming from the OpenBSD guys. I don't think you can even log in with their own OpenSSHd from a default install.
- nickpsecurity 11y ago
  That's what I'm thinking and suggesting. Because, if we get down to it, anyone reading the claim would have to believe something along these lines: 1. There's never been a defect that could affect security in any OpenBSD software, from kernel to protocols, after it was released. 2. For meaningfulness, the default install supports real-world usage (and usefulness) of the system. The good news for No 1 means that they never had to issue a patch in a protocol or software due to defects with potential to leak data, allow hijacking, or experience DOS. Knowing that, once released, every OpenBSD system was unhackable and needs no patches past functionality fixes would greatly reduce administrator overhead. Truly fire-and-forget system. If the website claim is true, that is. :) Further, if No 2 is true, users won't have to use anything but the base install to handle day-to-day tasks on their network. Anything critical is included, usable, and secure-by-default. Users would only need to rely on 3rd party stuff for non-obvious use cases or stuff that truly doesn't belong in a baseline. So, the ports collection wouldn't even be necessary in most deployments (esp infrastructure, console desktop) as the functionality and what counts in security claims were batteries included like the competition. I'll leave it to users and people following their bug trackers to determine if either is the case. Especially No 1 which is my main point. The mere existence of security patches would kill the web site claim. It would instead become, "Of all the defects found, only two were analyzed and shown to be exploitable over X years." Makes for a totally different impression, eh? ;)
  - slasaus 11y ago
    I think most of your posts are very informative. But your lack of knowledge about OpenBSD surprises me. Perhaps it would save you and the reader some time if you spent a bit more reading about OpenBSD instead of reasoning about all theoretical directions OpenBSD could have taken.
    - nickpsecurity 11y ago
      Appreciate it. Far as lack of knowledge, a brain injury in an accident cost me most of my hands-on IT skills and many details in INFOSEC. Among other things... However, the stuff I did repeatedly, like high-level security engineering and assessments, stays with me. Barely relevant here even though it makes plenty of sense that you'd think that. The short-cut around it is the concept of burden of proof in INFOSEC: one is expected to back up their big, security claims with evidence rather than everyone else expected to disprove them. I certainly could dig back into OpenBSD (and C) to fully understand its current situation, its code, its mitigations, every source change from vulnerability 2, and so on. Those details could benefit OpenBSD in form of contributions I attempt or the reader following along to get a better picture of insides. However, it's not necessary for evaluating my concern about the 2 vulnerability claim. We can cleverly cheat around all that knowledge by going straight to fundamentals and claim itself. Then, only acquiring (me) and/or applying (others) that knowledge if the specialist skill turns out to be required. Others and I did this with success when drowning in product and project security claims with finite time to review them. Let's apply that. "instead of reasoning about all theoretical directions OpenBSD could have taken." My main question is a simple, concrete one that I shouldn't have to investigate at all: what evidence is there that there have only been 2 exploitable flaws in all OpenBSD releases? To claim this, there would have to be a tracker of every defect fixed in OpenBSD since its inception, an analysis of each one's exploitability, and a result saying only two were exploitable. There's trackers like that for many projects. Where's that record for OpenBSD or, to save you time, do they even analyze every bug for exploitability? If that doesn't exist or that analysis wasn't done, then the only 2 vulnerability claim can be rejected immediately because it wasn't proven. Instead, the claim becomes "Of all X defects found, people only showed two were exploitable remotely. (Optionally) That's a defect ratio of X per Kloc with vulnerability ratio of Y per Kloc. (Not optional) The rest either weren't assessed for severity or were shown harmless." Alternatively, the claim is totally false if even one security fix for a remote attack was done after the 2nd vulnerability was fixed. It would have to be changed to a maybe pending further, specialist analysis. This isn't theoretical: it's a direct implication of the claim they're making, an extraordinary implication, and one which deserves concrete evidence to back it. So, I encourage people to reject it until they have that evidence and in a way they can share easily. If I have time or resources, I might attempt a thorough assessment of OpenBSD in terms of design or code. A past study I did comparing it to prior secure UNIX attempts showed some things it's missing where there's surely issues. It has some other attributes, esp code quality & protections, that help it more than others (including old ones). Nonetheless, the issue I have is an extraordinary claim that pops up repeatedly in discussions over OpenBSD vs whatever with no evidence to back it and high chance of failure. See the problem? Also, do you see how I don't need to be an OpenBSD developer to spot it?
- tedunangst 11y ago
  You can. There's an option to turn off, but it starts on.
tedunangst 11y ago
The claim is quite old, and comes from an era where a fresh install of an operating system would have web servers and DNS servers and file servers globally exposed. Many projects have adjusted since then, but there was definitely an era of Apache worms that could spread juat by pwning the default "it's working!" Web site that many operators didn't even know they were running.
- nickpsecurity 11y ago
  Best explanation I've heard. Still supports my concern more than the claim's truth. Nonetheless, I can totally understand that given I was around back then and remember what that was like. It would certainly have been a differentiator back then before sane defaults were a thing.