Live data from Hacker News

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

nvd.nist.gov

121–130 of 170 posts

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

#121

Earlier quoted context omitted.

I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine. I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” whic…

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.

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

#122

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.

OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. If you lose power it will lose the specific data currently being written to disk. It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data that has yet to land on disk if the power is cut.

I've had my share of sudden power cuts hit OpenBSD during the 20+ years I've been using it, and I have yet to ever see its file system actually go corrupt.

A sincere question: what important data does your router frequently and busily need to persist? If you don't have a UPS for it, perhaps it isn't too important after all. Maybe we have different perspectives of what a router is and should be. I manage a router (with OpenBSD) and it can drop off the power grid at any moment without losing anything of importance. If your router is in fact a multi-functional server I can understand the notion. Consider making all of the file systems fully synchronous. It has worked great for me for two decades.

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

#123

Earlier quoted context omitted.

I’m not an OS programmer and have been dabbling with OpenBSD’s code for fun. But the fact is that Rust kinda lacks flexibility. Most of the OS is dedicated to building a beautiful lie for programs to run happily, and that’s where C shine. I shudder to think about the amount of work that it would take to convince the rust compiler that everything is all right. Most hardware interactions is “parse, don’t validate” whic…

In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain. Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are di…

Most data in the kernel are rather long lived or traversing too many layers. There are too many entry points (system calls, interrupts) into the kernel for guarantees to hold.

And OpenBSD development is rather slow. The tech mailing list average 300-400 mails a month.

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

#124

Earlier quoted context omitted.

They are throwing tokens at codebases and finding mostly vulnerabilities in cases that have not been worth the limited time and effort of the chronically underfunded and understaffed professional groups. There’d be a lot more value in the companies giving the money they spend on their synthetic text extruders to the organizations doing quality security research work.

> they are ... finding ... vulnerabilities ... that have not been worth the time and effort ... that's kinda the entire point

The point of the comment you are replying to is that it's also not worth the time and effort to use LLMs to find vulnerabilities, if "time and effort" can be measured with "money". If you factor in all the money spent on training, GPU data centers etc, it's not actually a financially efficient way to find bugs unless you profit from creating demand for LLMs. LLMs aren't cheaper than humans per unit work, yet. They're just massively deficit funded because capital thinks "AI" is going to reshape the world order, and wants in.

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

#125

Earlier quoted context omitted.

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.

OpenBSD's FFS can be told to be fully synchronous, making it about as robust as can be for not being journaled. If you lose power it will lose the specific data currently being written to disk . It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data…

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

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

#126
post #89
post #86

Earlier quoted context omitted.

That does not match my experience with obsd. It is not so much minimalism as they are not afraid to reinvent the wheel. A obsd install is full of services, more than most linux installs I have seen. For example you can imagine my disappointment when I discovered what a pain in the ass it is to get a pflow producer working on linux after doing the first one on openbsd.

I'd say it's true. They chose to not implement SMP until consumer CPUs surprised them by going multi thread. And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.

They mostly dropped it because nobody was around who could maintain it. Wasn't just about security.

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

#127

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 believe that while the file system does not have journaling, that can be offset by applications. I.e. I think the SQLite Write Ahead Log would still protect you against data loss even if there's no journal in the file system, assuming you set various settings correctly. So I think it kinda depends on how the applications store data.

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

#128

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. If you lose power it will lose the specific data currently being written to disk . It won't lose other data, because it doesn't keep a bunch of it sitting around in a RAM cache while lying to the writing process about the I/O op already being completed. A journaled file system, too, will lose in-flight data…

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

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

#129

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.

What's the use for a writable filesystem in network gear, that is detrimental if lost at power outage? Some sort of very important logging?

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

#130
post #89

Earlier quoted context omitted.

I'd say it's true. They chose to not implement SMP until consumer CPUs surprised them by going multi thread. And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.

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.
Post reply on HN