Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nvd.nist.gov

Post reply on HN
Print view View original

151–160 of 170 posts

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

#151

Post by rootnod3 »

ptx wrote: post #148
rootnod3 wrote: post #131

Earlier quoted context omitted.

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

Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge. [1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...

Difference is that capsicum is after the fact and mostly about file descriptors. You need to open them in advance and _then_ call capsicum. But it does nothing about syscalls.

Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.

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

#152

Post by rootnod3 »

ptx wrote: post #148
rootnod3 wrote: post #131

Earlier quoted context omitted.

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

Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge. [1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...

And yes, I went into that a while ago on my blog (https://blog.wollwage.com/2026/20260212-daily-source-reading...)

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

#153

Post by collinfunk »

rootnod3 wrote: post #131
dcrazy wrote: post #36

Earlier quoted context omitted.

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

The others and I, working on GNU coreutils, frequently use 'yes' to generate a bunch of garbage input for testing programs. It is nice that it can do so quickly.

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

#154

Post by bell-cot »

yjftsjthsd-h wrote: post #87
JCattheATM wrote: post #77

Earlier quoted context omitted.

Well, that's where OpenBSD falls short, it lacks facilities to really enforce defense in depth - even NetBSD has some better features in this regard.

I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.

Just popped up, about pledge+unveil - https://news.ycombinator.com/item?id=48851765

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

#155

Post by fsckboy »

tiffanyh wrote: post #83
trashb wrote: post #53

One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.

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).

>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)

you mean the most simple way. "simplistic" would mean they went too far.

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

#156

Post by fsckboy »

tiffanyh wrote: post #83
trashb wrote: post #53

One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.

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).

>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)

you mean the most simple way. "simplistic" would mean they went too far.

https://en.wiktionary.org/wiki/simplistic

simplistic

1. Overly simple.

2. In a manner that simplifies a concept or issue so that its nuances and complexities are lost or important details are overlooked.

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

#157

Post by khrbtxyz »

nubinetwork wrote: post #92
TacticalCoder wrote: post #63

Earlier quoted context omitted.

Sidenote but... I read this on that link: dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517 dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that…

I would love to, but apparently its needed for libvirt.

It is required mainly for VMs that use virbr0 and NAT. Networking options like macvtap don't need it.

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

#158

Post by tiltowait »

doublepg23 wrote: post #109
tiffanyh wrote: post #83

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.

Out of curiosity, why put "router" in quotes?

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

#159

Post by somat »

Someone wrote: post #144
somat wrote: post #120

Earlier quoted context omitted.

Unbound can do authoritative dns. It is a bit clunky so usually what you do is have NSD for the authoritative parts and unbound for the recursive parts. but unbound has local-zone: stub-zone: forward-zone: auth-zone: directives. I am not the most sophisticated dns admin but I am fairly sure that just unbound by itself can do almost any dns party trick you care to throw at it.

> Unbound can do authoritative dns I don’t know whether they’re right, but https://www.openbsdhandbook.com/bind/ and https://www.openbsdhandbook.com/unbound/ disagree with that, saying you need the sublingual nsd for that.

I use NSD myself, but the man page sez an auth-zone directive could act like a self contained authoritive zone served from a file. the other way it can be used to to speed up the cache for the actual authoritive data.

https://man.openbsd.org/unbound.conf#AUTHORITY_ZONE_OPTIONS

"Authority zones are configured with auth-zone:, and each one must have a name. There can be multiple ones, by listing multiple auth-zone section clauses, each with a different name, pertaining to that part of the namespace. The authority zone with the name closest to the name looked up is used. Authority zones can be processed on two distinct, non-exclusive, configurable stages.

With for-downstream: yes (default), authority zones are processed after local-zones and before cache. When used in this manner, Unbound responds like an authority server with no further processing other than returning an answer from the zone contents. A notable example, in this case, is CNAME records which are returned verbatim to downstream clients without further resolution.

With for-upstream: yes (default), authority zones are processed after the cache lookup, just before going to the network to fetch information for recursion. When used in this manner they provide a local copy of an authority server that speeds up lookups for that data during resolving.

If both options are enabled (default), client queries for an authority zone are answered authoritatively from Unbound, while internal queries that require data from the authority zone consult the local zone data instead of going to the network.

An interesting configuration is for-downstream: no, for-upstream: yes that allows for hyperlocal behavior where both client and internal queries consult the local zone data while resolving. In this case, the aforementioned CNAME example will result in a thoroughly resolved answer.

Authority zones can be read from a zonefile. And can be kept updated via AXFR and IXFR. After update the zonefile is rewritten. The update mechanism uses the SOA timer values and performs SOA UDP queries to detect zone changes."

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

#160

Post by anoneng »

efficax wrote: post #149
anoneng wrote: post #138

Earlier quoted context omitted.

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.

Not really sure what you mean? You have to use `unsafe` in Rust to access arbitrary mutable pointers. How would you do DMA, or write a device driver, without `* mut T`

I’m referring to use of process (sometimes with a partial assist from qualified tools, of which Rust is NOT one) for safety assurance, not the language. As is done in safety and security critical embedded contexts. eg DO-178, Common Criteria, etc.
Post reply on HN