3 ms·

It depends on what is meant by "xz drama". If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider

It depends on what is meant by "xz drama". If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider it worthwhile trying to invest in the long supply chain attack for the OS. If you view it as the break-xz-to-attack-sshd, OpenBSD is designed as a single system with a single codebase, and has a general aversion to features such that it is difficult for an undersecured random library to become a vehicle to breaking a major, important component. If you view it as the techniques used to publish an exploit in open source code, well, OpenBSD is filled with the kind of developers whose self-confidence is such that they believe that they are uniquely capable of writing code without those kinds of issues and will denigrate the use of newer technologies that mitigate that risk with the attitude that it coddles programmers and coddled programmers aren't good programmers. Or, in shorter terms, OpenBSD is actually one of the projects I'd expect to have a relatively high chance of a clever contributor being able to smuggle in an exploit in plain sight.

QuantumG 3y ago
Which newer techniques? Honest question.
- nequo 3y ago
  Not parent but jails and capabilities that are user controlled and not hardcoded into the binary would be nice to see.
  - QuantumG 3y ago
    Do you think they understand the benefits? I think you'd have a lot better chance at enacting change than my emotional rambling has, and if not, lesson learned.
  - nanolith 3y ago
    They tried this. The predecessor for pledge / unveil was systrace, which included a user-controlled policy file. One significant reason that pledge was implemented was because it is possible to disable or mis-configure user-controlled policies. Theo mentions this in his presentation that unveiled pledge, and he's basically referring to things like seccomp and systrace: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.... More explicitly mentioning seLinux / seccomp: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00008.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00008.... https://www.openbsd.org/papers/hackfest2015-pledge/mgp00011.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00011.... More explicitly mentioning systrace: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00009.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00009.... Certainly, it's possible to debate the relative merits of this approach, but this is why OpenBSD has moved away from user controlled policies.
sillywalk 3y ago
> If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider it worthwhile trying to invest in the long supply chain attack for the OS. I agree that OpenBSD is a minor sized target, but I recall these bits from back in the day. EDIT: accusations from ~2010 about actions ~2000 "FBI accused of planting backdoor in OpenBSD IPSEC stack" [0] "A Chapter from the FBI's History with OpenBSD and an OpenSSH Vuln (twitter.com/rooneymcnibnug) 127 points by signa11 on July 21, 2019" | 23 comments [1] "Theo de Raadt summarizes the OpenBSD IPSec "backdoor" situation"[2] and HN discussion "36 points by there on Dec 21, 2010 | 47 comments [3] [0] https://arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/ https://arstechnica.com/information-technology/2010/12/fbi-a... [1] https://news.ycombinator.com/item?id=20489904 https://news.ycombinator.com/item?id=20489904 [2] http://marc.info/?l=openbsd-tech&m=129296046123471&w=2 http://marc.info/?l=openbsd-tech&m=129296046123471&w=2 [3] https://news.ycombinator.com/item?id=2029175 https://news.ycombinator.com/item?id=2029175
- tptacek 3y ago
  The OpenBSD IPSEC stack thing was very silly. https://news.ycombinator.com/item?id=2029640 https://news.ycombinator.com/item?id=2029640
asveikau 3y ago
Last paragraph is off base. They have a long history of doing mitigations by default before they are seen elsewhere. A lot of those are from more than 20 years ago though -- things like fewer services by default, daemons that chroot and drop privilege at a time when Linux didn't do that, W^X, address randomization.. more recently they do some stuff to prevent shellcode from making syscalls.. this IFUNC mechanism to monkey patch system binaries is something they would not go for.
- jcranmer 3y ago
  I'm going a bit far off of my wheelbase here, because exploit development and mitigation is not an area I have a lot of experience in, but the sense I've seen from security researchers is that OpenBSD's security posture is far more mixed than their developers' touting implies. So while OpenBSD may have some features that are well-regarded (say, their malloc implementation), they can do a shockingly bad job in other areas (such as ROP mitigations).
  - tptacek 3y ago
    I think you're expressing an opinion that is pretty mainstream among runtime hardening and exploit people. You can find reasonable opinions in both directions, though. Joshua Stein built a page that is a pretty incredible resource on this topic: https://isopenbsdsecu.re/ https://isopenbsdsecu.re/
    - cyberpunk 3y ago
      I’ve not seen any openbsd exploit code in… a decade though? Can you point me to a single working exploit for anything in openbsd lately? (Excluding shellshock/log4shell kind of vulns) I mean an exploit against some service running on openbsd, or even necessarily the os contents.. Edit: I don’t mean an 0day, just an exploit that worked on some combo of openbsd and x. X being anything like e.g Apache or Bind or whatever
      - tptacek 3y ago
wolverine876 3y ago
I'm not commenting on OpenBSD's security, but I think some of that goes too far: > OpenBSD is designed as a single system with a single codebase, and has a general aversion to features such that it is difficult for an undersecured random library to become a vehicle to breaking a major, important component. From what I understand, those security benefits aren't incidental; they are a major reason for doing those things. > a clever contributor Doesn't seem like it would be very hard for someone to join the team and obtain maintainer status? Also, remember the social engineering done by the xz attacker to get their exploit included in updates - that also seems a bit challenging in the OpenBSD project. OpenBSD seems to do more careful code reviews than other projects, but I don't know that I have an objective measure of it.
- j_not_j 3y ago
  OpenBSD source gets independent code reviews, and they run syzcaller continuously. https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b https://marc.info/?l=openbsd-tech&m=164303498026116&w=2 https://marc.info/?l=openbsd-tech&m=164303498026116&w=2

QuantumG 3y ago

Which newer techniques? Honest question.

nequo 3y ago
Not parent but jails and capabilities that are user controlled and not hardcoded into the binary would be nice to see.
- QuantumG 3y ago
  Do you think they understand the benefits? I think you'd have a lot better chance at enacting change than my emotional rambling has, and if not, lesson learned.
- nanolith 3y ago
  They tried this. The predecessor for pledge / unveil was systrace, which included a user-controlled policy file. One significant reason that pledge was implemented was because it is possible to disable or mis-configure user-controlled policies. Theo mentions this in his presentation that unveiled pledge, and he's basically referring to things like seccomp and systrace: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00005.... More explicitly mentioning seLinux / seccomp: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00008.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00008.... https://www.openbsd.org/papers/hackfest2015-pledge/mgp00011.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00011.... More explicitly mentioning systrace: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00009.html https://www.openbsd.org/papers/hackfest2015-pledge/mgp00009.... Certainly, it's possible to debate the relative merits of this approach, but this is why OpenBSD has moved away from user controlled policies.

sillywalk 3y ago

> If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider it worthwhile trying to invest in the long supply chain attack for the OS. I agree that OpenBSD is a minor sized target, but I recall these bits from back in the day. EDIT: accusations from ~2010 about actions ~2000 "FBI accused of planting backdoor in OpenBSD IPSEC stack" [0] "A Chapter from the FBI's History with OpenBSD and an OpenSSH Vuln (twitter.com/rooneymcnibnug) 127 points by signa11 on July 21, 2019" | 23 comments [1] "Theo de Raadt summarizes the OpenBSD IPSec "backdoor" situation"[2] and HN discussion "36 points by there on Dec 21, 2010 | 47 comments [3] [0] https://arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/ https://arstechnica.com/information-technology/2010/12/fbi-a... [1] https://news.ycombinator.com/item?id=20489904 https://news.ycombinator.com/item?id=20489904 [2] http://marc.info/?l=openbsd-tech&m=129296046123471&w=2 http://marc.info/?l=openbsd-tech&m=129296046123471&w=2 [3] https://news.ycombinator.com/item?id=2029175 https://news.ycombinator.com/item?id=2029175

tptacek 3y ago
The OpenBSD IPSEC stack thing was very silly. https://news.ycombinator.com/item?id=2029640 https://news.ycombinator.com/item?id=2029640

asveikau 3y ago

Last paragraph is off base. They have a long history of doing mitigations by default before they are seen elsewhere. A lot of those are from more than 20 years ago though -- things like fewer services by default, daemons that chroot and drop privilege at a time when Linux didn't do that, W^X, address randomization.. more recently they do some stuff to prevent shellcode from making syscalls.. this IFUNC mechanism to monkey patch system binaries is something they would not go for.

jcranmer 3y ago
I'm going a bit far off of my wheelbase here, because exploit development and mitigation is not an area I have a lot of experience in, but the sense I've seen from security researchers is that OpenBSD's security posture is far more mixed than their developers' touting implies. So while OpenBSD may have some features that are well-regarded (say, their malloc implementation), they can do a shockingly bad job in other areas (such as ROP mitigations).
- tptacek 3y ago
  I think you're expressing an opinion that is pretty mainstream among runtime hardening and exploit people. You can find reasonable opinions in both directions, though. Joshua Stein built a page that is a pretty incredible resource on this topic: https://isopenbsdsecu.re/ https://isopenbsdsecu.re/
  - cyberpunk 3y ago
    I’ve not seen any openbsd exploit code in… a decade though? Can you point me to a single working exploit for anything in openbsd lately? (Excluding shellshock/log4shell kind of vulns) I mean an exploit against some service running on openbsd, or even necessarily the os contents.. Edit: I don’t mean an 0day, just an exploit that worked on some combo of openbsd and x. X being anything like e.g Apache or Bind or whatever
    - tptacek 3y ago

wolverine876 3y ago

I'm not commenting on OpenBSD's security, but I think some of that goes too far: > OpenBSD is designed as a single system with a single codebase, and has a general aversion to features such that it is difficult for an undersecured random library to become a vehicle to breaking a major, important component. From what I understand, those security benefits aren't incidental; they are a major reason for doing those things. > a clever contributor Doesn't seem like it would be very hard for someone to join the team and obtain maintainer status? Also, remember the social engineering done by the xz attacker to get their exploit included in updates - that also seems a bit challenging in the OpenBSD project. OpenBSD seems to do more careful code reviews than other projects, but I don't know that I have an objective measure of it.

j_not_j 3y ago
OpenBSD source gets independent code reviews, and they run syzcaller continuously. https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b https://marc.info/?l=openbsd-tech&m=164303498026116&w=2 https://marc.info/?l=openbsd-tech&m=164303498026116&w=2