A few thoughts on the BCBCBC vulnerability. Original report. There’s a few things not explicitly stated in the report, which I thought may be interesting.

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

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

On the last day of AsiaBSDCon, George Neville-Neil gave the keynote talk, Security Fantasies and Realities. Some of it was good and some of it was bad. One of the central points is that the ioshitsunami is coming and in order to save humanity we need to do more of the good security and less of the bad security. One of the, or perhaps just the, good security things to do is hardware root of trust, which I will call TPM, although it has a few brand names.

more...

My phone decided it didn’t like my face and wouldn’t let me log in. Unusually, instead of giving me some retries, it immediately locked me out, requiring a passcode. At first I thought this might be a security measure, but I’m pretty sure it was just a glitch. However, it’s an interesting possibility for an authorization system. Fast lockout after a near match.

more...

In reference to arbitrary code execution in various source control programs. Refer svn advisory. Remember A Fire Upon the Deep?

There’s some code archaeologists who dig up an artifact. They don’t know what it does, but it includes some instructions for how to unpack it. And so they follow the instructions. And they think they’re taking precautions to prevent it from doing bad stuff, but they screw up, and the evil AI is turned loose. And then bad stuff happens.

It’s funny how similar this is to today’s vulnerability. In theory, checking out a code repo should be a safe operation. All you’re doing is downloading some artifact from a server. Building the code, running the code, all that can be unsafe. But surely there’s no trouble to simply checking out some code?

Alas, a repo is not just a repo. Checking out a repo might require checking out other sub repos and external resources. And so a dumb read only artifact is actually a smart read/execute artifact. The artifact can’t be checked out without also interpreting some of its contents. And if interpreting happens to execute some unwanted shell commands... Bad stuff happens.

It’s a bug, and it’s fixed, but another lesson that nothing is ever simple when adding features. What looks like just a hostname over here could be interpreted as a shell command over there.

A few thoughts after reading Are all BSDs created equally? by Ilja van Sprundel. Theo says OpenBSD is the best, Ilja fact checks.

more...

The time has finally come to switch everything to https. Actually, I’ve been using https for a while, but now it’s time to inflict, er invite, everyone else along for the ride.

more...

A few thoughts I had after reading Exploiting the Linux kernel via packet sockets. Not really about the exploit itself, but what it reveals about the state of systems security.

more...

Some thoughts based on a series of tweets.

more...