The unreasonable joy of it

Let me describe a recent Tuesday evening. I am sitting at a Mac Mini in Whitby, North Yorkshire. Outside, it is doing what the North Yorkshire coast does most evenings: raining, sideways, with conviction. I have a cup of tea. I am reading the OpenBSD kernel source. I have been reading the OpenBSD kernel source for three weeks. I have found a bug in the unveil() implementation that has been there, quietly minding its own business, since 2018.

Nobody asked me to do this.

Nobody is paying me to do this.

Nobody will be particularly surprised if I stop doing this.

And yet I cannot quite describe how satisfying it is.

The bug that waited eight years to be noticed

The unveil system call is one of OpenBSD's most elegant security contributions. It lets a process declare, before it does anything sensitive, exactly which parts of the filesystem it is allowed to touch. Once you call unveil(NULL, NULL) to lock the sandbox, the declared permissions are fixed. The man page is clear: attempting to widen your permissions after the fact returns EPERM. No, you may not have more. Off you go.

The code had a different opinion. Specifically, the escalation guard — the bit of code that enforces the "no wider permissions" rule — had been sitting inside a #if 0 block since the initial commit. A #if 0 block is, for the non-C programmers in the audience, the programming equivalent of writing something down and then immediately crossing it out. The code was there. It was correct. It just wasn't running.

It had not been running for eight years. Across every OpenBSD release since 2018. On every system that shipped with unveil(2).

I sent a short, polite email to security@openbsd.org. I included a reproducer. I explained the issue. I offered to be told I was wrong. Then I went to bed, because it was 2am.

The two-word reply that made my week

OpenBSD kernel developers are not known for effusive correspondence. The project has a long tradition of concise, direct communication, which is probably partly why the codebase is as good as it is. The reply to my bug report was, in its entirety:

"ok beck" means Bob Beck, a member of the OpenBSD core team, reviewed the fix and approved it for commit. It is the project's standard sign-off. It is, in two words, a kernel developer whose opinion I respect telling me that the fix was right, the analysis was correct, and the change would ship.

I read it on my phone at 7am while still half asleep. I may have done a small, undignified celebration in the kitchen. The cat was unimpressed. The cup of tea I subsequently made tasted noticeably better than usual.

A second finding — a type truncation in exec_elf.c involving the pinsyscall security mechanism — came back as "ok guenther", Otto Moerbeek's approval arriving shortly after. Two credits. Two fixes. Now shipping on every OpenBSD system worldwide.

Shipped on every OpenBSD system worldwide. From a Mac Mini. In Whitby. On a Tuesday.

Why bother, though, really

My earliest computing memory is not my own machine. It is my dad's Commodore PET: green screen, full-travel keyboard (not the horrible chiclet one on the later models), a pair of enormous external 5¼-inch floppy drives that sounded like small aircraft preparing for takeoff, and a dot matrix printer that produced everything in purple ink. My dad would type in games from magazines — Commodore BASIC, line by line, out of Compute! or whatever came through the post that month. I would watch. Then I would try. It was, I discovered, very easy to make a mistake. It was also, I occasionally discovered, the magazine that had made the mistake first.

By the time I got to school there were BBC Micros, and eventually PCs, and the instinct that had formed in front of that green screen — but what happens if I do this? — turned out to transfer perfectly to every new machine I encountered. It has never really gone away. It got me a first job at University College Scarborough in 1994. It got me through decades of NHS cryptographic standards work, contactless payment systems, internet infrastructure, and more firewall configurations than I could count. It eventually turned into a book on macOS security research methodology, a SANS paper in 2001, and a blog I have apparently decided to write in the evenings when I should probably be watching television.

The honest answer to "why bother" is that I find it interesting. Not interesting in the dutiful, professionally obligatory sense. Interesting in the way that makes you look up from your screen and realise it is 1am and you have been reading about ELF binary loading for three hours and you are genuinely fine with this.

There is also something more than personal satisfaction in it. Independent researchers — people doing this work outside of corporate security teams, without a budget or a mandate or a manager asking for weekly updates — find things. Not because they are smarter than the people inside those teams, but because they bring different eyes to the same code. Fresh eyes that do not already "know" how something works. Eyes that ask naïve questions that turn out not to be naïve at all.

The #if 0 in OpenBSD's unveil implementation had been there since 2018. Presumably many people had read that code over those eight years. But reading code with the specific question "does this do what the man page says it does?" is a different activity from reading code because you are familiar with it. Familiarity is the enemy of the fresh read. Independent research is, in part, the institutionalisation of the fresh read.

An invitation, entirely without pressure

If you are reading this and you have ever thought about doing this kind of work — reading source code, poking at systems you own, asking careful questions about whether the documentation and the implementation actually agree — then I would gently suggest that the barrier is lower than it appears.

You do not need a team. You do not need a budget. You need curiosity, time, a willingness to be wrong and learn from it, and something to read. The cross-reference technique from an earlier post on this blog is a reasonable starting point. The methodology book is free. The OpenBSD source is public. The FreeBSD security advisories go back to the 1990s.

You might find nothing. That is fine; reading carefully is still worthwhile. You might find something small. That is genuinely useful. You might, one Tuesday evening in the rain, find something that has been quietly sitting in a #if 0 block for eight years, send a polite email, and get back two words that make your entire week.

It is, I have to say, a very good feeling.