Live data from Hacker News

OpenBSD has a use-after-free allowing local privilege escalation to root

nvd.nist.gov

131–140 of 170 posts

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#131
post #36

Earlier quoted context omitted.

The Linux kernel is generally much larger than OpenBSD which is quite minimal. But I do agree with you - not directly related to activity.

As another commenter said, number of bugs increases with lines of code changed.

And some code is absolutely unnecessary. Look at the yes command. GNU version is optimized to death for no reason at all[1].

OpenBSD's version is as simple as it gets[2].

[1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#133

Earlier quoted context omitted.

I thought that parsing implied validation. Is this not the case?

Validation asserts what’s in the data type, while parsing just creates it. Especially in the context of C structures where you can just create it from a blob of bytes.

Ah, I suppose in my mind parsing precludes the idea of invalid data.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#134

Earlier quoted context omitted.

OpenBSD has a reputation for being... selective about what they admit is a security-relevant bug.

They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all). Dismissing their claims is not being selective, it's just the right thing to do.

Exactly! As an open source developer who has a notable-enough-for-Wikipedia 25-year-old project out there (MaraDNS), let me tell you, a lot of “security bugs” found by AI-assisted researchers are anything but security bugs. Just some examples of stuff which ended up in my inbox recently:

- A security “bug” where someone who sends hundreds of millions of spoofed DNS queries could possibly have one come through. This is a problem with the DNS protocol, and it’s a problem with broken servers which drop DNS packets under some circumstances. It’s a long known issue where, in reality, the exploit isn’t incredibly practical (to say the least).

- A security “bug” where someone saw `strcat` in my code and assumed it was automatically a big huge buffer overflow exploit. No, it wasn’t: I did bounds checking in all cases, except one case where the program in question hasn’t been able to even compile since 2022 (and is a side utility which isn’t needed in any way, shape, or form to run MaraDNS).

- A bunch of security “bugs” which were cases where my recursive resolver took a few seconds to fully drop resources used to solve a DNS query if it got various kinds of weird packets. This researcher claimed one bug was a remote packet of death, so I spent an entire afternoon writing a test case creating the packet in question. Nope, no packet of death.

- Finally, one researcher did find a security bug in the TCP code for the recurisve resolver, where an authorized client could disable the TCP server (without affecting the UDP server). Keep in mind that the code doesn’t enable TCP by default, a user would have to go out of their way to enable DNS-over-TCP, and it’s not a “packet of death” because the IP sending the bad TCP packets has to be one already authorized to perform recursive queries.

With the DNS-over-TCP bug, I patched the code and made a new MaraDNS release. With the overflow in the code which hasn’t compiled since 2022, I fixed the bug, patched the code to compile again, then next removed the code completely from MaraDNS (putting it in “MaraDNS-attic”).

As an aside, djbdns users may have observed that, because of the C23 changes, djbdns doesn’t even compile anymore, and I am not aware of anyone besides myself caring enough to post patches. In my own distribution of djbdns, I have instructed people to set CC to "c99 -D_DEFAULT_SOURCE" so that the code can compile again.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#135

Earlier quoted context omitted.

But Bluetooth is basically a giant blast of security vulnerabilities. On the consumer side, yes, it's a big subsystem to drop, but on the server side, it's a little bit different! I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.

The Bluetooth spec is horrendous, and from what I read, the hardware is equally horrifying. Bluettoth is a wireless bus, not one class a device and an implementation would need to provide hooks to the other subsystems like wscons (keyboard and mouse), audio and network. OpenBSD does not have kernel modules, so it’s either in or not.

> The Bluetooth spec is horrendous

The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account.

Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a disaster it is, but I'm still able to use my mouse and headphones over LE only.

> OpenBSD does not have kernel modules, so it’s either in or not.

But I'm assuming that not all kernel code is active at all times? Because it would seem odd to me if the amdgpu code was always active on something like a Raspberry Pi.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#136

Earlier quoted context omitted.

While I agree, OpenBSD also doesn't fully implement features/functionality. If your operating system only does 20% of what another operating system can do, it's easier for you to have 80% less bugs. That's not a knock, it's a design philosophy of OpenBSD (which is to do the minimal needed, and no more, in the most simplistic way).

My hobby horse is the lack of a “modern” filesystem on obsd. Without journaling I really don’t agree with the oft repeated claims it makes a good “router”. Any networking gear I’ve used is treated as an appliance and I don’t want an unfortunate power outage causing data loss.

I ran it diskless for years with read-only NFS mounts. Set up syslog and a pflog daemon to send logs elsewhere, and you don't need write access most of the time.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#137

Earlier quoted context omitted.

Yes, you know that because of their marketing.

Do you have an example of this?

The first line of text on their homepage?

But I don't see anything wrong with OpenBSD saying they focus on security when it's well documented that they do, in fact, focus heavily on security.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#138
post #41
post #15

[flagged]

It's difficult to say if a kernel written in rust would not have similar vulnerabilites, because it would be impossible to build a kernel without significant amounts of `unsafe`.

Oh it’s possible and people do it in embedded all the time at great expense, but that safety isn’t assured by using a “safe” language, it comes from the requirements, documentation and verification process. OpenBSD’s kernel was developed with security in mind but not that level of safety.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#139
post #24

Earlier quoted context omitted.

Tell us you know nothing about kernel programming and trust stacks while you are at it.

I know a lot about kernel programming. and the last thing as I would ever suggest as being core to kernel programming is that is a specialized discipline that uses different rules and shouldn't be accessible to neophytes. its just code. sometimes the restrictions are unfamiliar, but there is nothing magic going on here.

If you knew a lot you would stop digging.

Re: OpenBSD has a use-after-free allowing local privilege escalation to root

#140

Earlier quoted context omitted.

> OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. I am very interested, is there anything we can read to achieve that?

You can look at the mount command and the "sync" option: https://man.openbsd.org/mount If you're really curious about it, Michael Lucas wrote a full book about the OpenBSD file system.

Man, thanks for this precious tip
Post reply on HN