flak rss random

reversing an openbsd kernel syspatch

OpenBSD has provided binary patches for a select few architectures for a while now, to save users from the daunting task of running make on their own. Alas, this means you might now apply a patch without first reviewing it. In the olden times, you had a source patch, so obviously you meticulously studied every line before application, just like you advised new users on IRC to do. But now, who will believe you do this when the binary syspatch is right there, so easy, so tempting.


Posted 25 May 2022 08:38 by tedu Updated: 25 May 2022 17:22
Tagged: openbsd

compiling an openbsd kernel 50% faster

This is approximately as wise as taking off from Mars in a ragtop rocket, but don’t worry, the math all checks out.


Posted 02 May 2022 14:38 by tedu Updated: 02 May 2022 14:38
Tagged: openbsd

probing my ssd's latency

My SSD is probably pretty fast, but maybe a faster one would let me compile a kernel even quicker by reducing the time spent waiting for I/O to complete. First though, I need to determine its latency, and the benchmark tool available to me, dd, measures throughput not latency. We need to go deeper.


Posted 25 Apr 2022 05:39 by tedu Updated: 25 Apr 2022 05:39
Tagged: openbsd programming

two and a half bad bits

It started with a simple feature addition. It always does. And then the murders began. I don’t think I’ve ever introduced so many bugs by changing so few bits.


Posted 11 Apr 2022 08:08 by tedu Updated: 11 Apr 2022 08:08
Tagged: openbsd programming

sometimes the knote comes early

Some bugs, some ambiguities, some assumptions, some bad results. Nothing went too seriously wrong, but it seems like an interesting case study in code evolution. I had nothing to do with finding or resolving the issues, I’m just commenting.


Posted 04 Apr 2022 15:39 by tedu Updated: 04 Apr 2022 15:39
Tagged: openbsd programming

rethinking openbsd security

OpenBSD aims to be a secure operating system. In the past few months there were quite a few security errata, however. That’s not too unusual, but some of the recent ones were a bit special. One might even say bad. The OpenBSD approach to security has a few aspects, two of which might be avoiding errors and minimizing the risk of mistakes. Other people have other ideas about how to build secure systems. I think it’s worth examining whether the OpenBSD approach works, or if this is evidence that it’s doomed to failure.


Posted 31 Mar 2020 04:20 by tedu Updated: 04 Apr 2020 09:15
Tagged: openbsd programming security thoughts

changing defaults and removing options

Times change and programs must change with them. Altering or removing functionality however risks breaking backwards compatibility. A few examples.


Posted 08 Aug 2019 18:14 by tedu Updated: 08 Aug 2019 18:53
Tagged: openbsd programming

random ip id comments

There’s a new paper, From IP ID to Device ID and KASLR Bypass, which I liked. It’s at the intersection of networking, old but not obsolete standards, random, security, and implementation defined behavior. By all means, read the paper, but the really short version is they accomplished two things. They reverse engineered a per host random seed from network traffic on Windows and Linux, allowing fingerprinting, and more surprising, turned this into a KASLR break on Linux. Pretty wild.


Posted 01 Jul 2019 01:23 by tedu Updated: 01 Jul 2019 01:23
Tagged: networking openbsd security

ssh in https

The wifi network at BSDcan, really the UOttawa network, blocks a bunch of ports. This makes it difficult to connect to outside machines using “exotic” protocols, basically anything except http or https. There are many ways to resolve this, here’s what I did.


Posted 17 May 2019 17:32 by tedu Updated: 15 Jul 2019 21:15
Tagged: openbsd software web

syzkaller found a bug

Common problem for operating system fuzzers is breaking the system they’re running on. Some forms of damage are expected, some are not, and sometimes it’s difficult to tell which is which.

A few days ago, a stack leak bug was fixed in FreeBSD. A similar fix for OpenBSD was committed. And then syzkaller came kalling just a few days later.

panic: bad dir

There’s a few possible causes for this, but inspection revealed that the most likely case might be a directory entry missing the nul terminator. The timing certainly seemed suspicious. Could there be an off by one?

memset(newdirp->d_name + (cnp->cn_namelen & ~(DIR_ROUNDUP-1)), 0, DIR_ROUNDUP);

Actually no. syzkaller had found a way to create filesystem corruption through one of the “expected” damage paths, but the test case was a little obfuscated. More study revealed it was calling mknod to create a new device that happened to be equal to /dev/sd0c and opening it, and then calling pwrite to write some garbage to a random spot.

mknod("banana", 0777, 0x0402);
pwrite(3, "oops", 4, 0x9000);

Not recommended.

Further complicating the matter was that syzkaller didn’t know that pwrite is one of the magic syscalls that takes a padding argument before off_t. This didn’t affect the test, per se, but makes it harder to interpret because syzkaller calls things directly. (The actual syscall in use was the iovec variant, pwritev.)

syscall(SYS_pwritev, r[0], 0x200002c0, 1, 0);

If you read the man page for pwritev that looks correct. But inspecting src/sys/kern/syscalls.master reveals that the fourth argument is actually a pad argument, and the offset is the fifth argument. So the call above was writing to an offset that was not zero.

Not the first fuzzer to encounter this oddity. More details here.

In the end, it was just coincidence that syzkaller found a new way to corrupt its filesystem a few days after a filesystem commit.

Posted 10 May 2019 16:02 by tedu Updated: 10 May 2019 16:02
Tagged: openbsd