The OpenBSD project to build a secure operating system has also, in passing, built an extremely robust operating system, because from their perspective any bug that potentially crashes the system is considered a critical security hole. An ordinary paranoid sees an input that crashes the system and thinks, “A crash isn’t as bad as somebody stealing my data. Until you demonstrate to me that this bug can be used by the adversary to steal data, it’s not extremely critical.” Somebody with security mindset thinks, “Nothing inside this subsystem is supposed to behave in a way that crashes the OS. Some section of code is behaving in a way that does not work like my model of that code. Who knows what it might do? The system isn’t supposed to crash, so by making it crash, you have demonstrated that my beliefs about how this system works are false.”
Hey there,
I was showing this post to a friend who’s into OpenBSD. He felt that this is not a good description, and wanted me to post his comment. I’m curious about what you guys think about this specific case and what it does to the point of the post as a whole. Here’s his comment:
This isn’t an accurate description of what OpenBSD does and how it differs from other systems.
> any bug that potentially crashes the system is considered a critical security hole
For the kernel, this is not true: OpenBSD, just like many other systems, has a concept of crashing in a controlled manner when it’s the right thing to do, see e.g. [here](https://man.openbsd.org/crash). As far as I understand [KARL](https://why-openbsd.rocks/fact/karl), avoiding crashes at any cost would make the system less secure: attacker guesses incorrectly ⇒ the system crashes ⇒ the system boots a new randomized kernel ⇒ attacker is back at square one vs. attacker guesses incorrectly ⇒ the system continues working as usual ⇒ attacker guesses again with new knowledge
For the other parts of the system, the opposite is true: OpenBSD consistently introduces new interesting restrictions, if a program violates them, it will crash immediately.
“The %n conversion specifier has serious security implications, so it was changed to no longer store the number of bytes written so far into the variable indicated by the pointer argument. Instead a syslog(3) message will be generated, after which the program is aborted with SIGABRT.”
“Code such as printf(foo); often indicates a bug, since foo may contain a % character. If foo comes from untrusted user input, it may contain %n, causing the printf() call to write to memory and creating a security hole.”
“%n can be used to write arbitrary data to potentially carefully-selected addresses. Programmers are therefore strongly advised to never pass untrusted strings as the format argument, as an attacker can put format specifiers in the string to mangle your stack, leading to a possible security hole.”
As we see, on Linux and macOS, the potential security issue is well-known and documented, but a program that uses it is supposed to work. On OpenBSD, it’s supposed to crash.
This system call allows a program to sandbox itself, basically saying “I only need this particular system functionality to operate properly; if I ever attempt to use anything else, may I crash immediately”.
Like many other systems, OpenBSD doesn’t allow you to have memory that is both writable and executable. However, it’s an error the program can recover from. By setting a kernel parameter, you can make the error unrecoverable. The program that attempts to use memory like that will crash.
Hey there,
I was showing this post to a friend who’s into OpenBSD. He felt that this is not a good description, and wanted me to post his comment. I’m curious about what you guys think about this specific case and what it does to the point of the post as a whole. Here’s his comment: