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.

more...

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

more...

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.

more...

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.

more...

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.

more...

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.

more...

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

more...

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.

more...

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.

more...

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);
open("banana")
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.