ELI5 why the “xz drama” couldn’t happen on openBSD? do they not use open source packages? are they assuming they would have caught it before adding the infected version to their repos?
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.
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.
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).
citation needed for the failings of their ROP mitigations. I don't use openbsd for the security, so I don't pay much attention to that side of things. But the one that stood out was where they removed all rop gadgets. which sounds pretty good to me.
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:
Do you have a source for that? I run it on a few machines and monitor that stuff, I think I would remember. I remember patching that one before the portable tree release with the fix was in a distro. I remember it very well because I was rushed, heading out to a meal but realizing a machine was vulnerable.
I think later they had another crashing bug that wasn't exploitable. This one from 2020 was poor validation of input leading to a shell command. A very 90s bug indeed.
Oh! You're totally right. I had two different links, and, of course, the actual Qualys advisory has the date you're giving it. Thanks for taking the time to correct me on this.
> 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]
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.
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:
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.
OpenSSH and the OpenBSD init system are part of the base system, maintained by OpenBSD developers. There's no opportunity for an outsider to use dependencies to insert backdoors in critical components.
The critical piece was systemd, was it not? ssh is no dependent on xz, it only gets there through the "systemd notification" hook provided by vendor specific patches.
Not really, systemd was 1 way that openssh could load liblzma, but another would have been thought the selinux PAM stack. It didn't exactly rely on anything systemd specific, just that it was a (transitive) dependency to openssh.
And the entire notification stuff can also be done without linking to libsystemd, but the maintainers that added the patch I guess didn't want to reimplement it manually (now the docs have a fully functional example ready to copy-paste, but before the protocol was just explained).
What I am trying to say is: it doesn't have to be any specific dependency, it can be any dependency that somehow loads liblzma. It can be a tiny mostly insignificant direct dependency if you want, it doesn't matter, it just needs to somehow be loaded into the address space.
But if such things are avoided across the board as policy, exactly to attain the result of reducing that attack surface, then there are few such possible examples, and so you can't just say "it could be anything" you have to show that there is actually much pool of "anything".
What's an equivalent example that could actually happen in openbsd?
My understanding is that nothing in base has a dependency on anything outside. There may be some third party software in contrib (if OpenBSD has contrib, like FreeBSD), but I don't think the 3rd party software's build system would be used.
Some BSDs use an external compiler on some platforms, and in that case, you have a build dependency on that, and trusting trust may apply.
If you run the 'ldd' tool against OpenBSD's ssh, you get 4 libraries. If you do the same on different Linux distros you get many more; this means the surface area is much larger.
was it mostly about the targets the xz actor was interested in than some security property inherent to openbsd that would prevent that sort of dynamic linking vulnerability?
Debian and RedHat link liblzma into SSH for systemd which OpenBSD doesn't use. So in the sense of there being a larger attack surface with those distros I guess you can consider it more secure, but it's not just OpenBSD though; there are plenty of Linux distros that don't do this either.
"ELI5 why the "xz drama" couldn't happen on [O]penBSD."
It could happen but it did not happen.
Linux distributions that use glibc and systemd are popular. Linux has millions of dollars behind it, and many corporations contributing their time and money, some building businesses around Linux. AFAIK, OpenBSD does not have similar resources. It's volunteer-supported.
Berkeley Software Distributions use their own libc, such as OpenBSD, and their own init system (not systemd) and are relatively unpopular.
The liblzma exploit that was discovered targeted Linux distributions that use glibc and systemd. Specifically, it relied on a feature of glibc called ifunc.
If an exploit targeted OpenBSD, then there would probably be less "drama".
Unpopularity probably plays a role in avoiding "drama".
Also consider the use of features such as ifunc and systemd. In some cases Linux may use features that BSD projects do not have. The liblzma exploit author chose to target Linux-specific features.
Also, glibc and systemd are different projects, the later is associated with a commercial entity. The libc and init system used on a BSD project are normally both parts of the BSD project, and the project is not associated with any commercial entity. Whether that has any effect on anything is left as question for the reader.
The "all bugs are shallow" schtick is not about bugs being less likely, only that bugs are more likely to be brought to light. Which is still true: the xz backdoor never would have been found in a closed-source codebase.
