This post never made it into words when planned, so the references are a bit dated, but I think it’s still mostly relevant. (For those who are familiar with the references.) Some time ago, I saw a claim that the software developers who worked on Zelda: Breath of the Wild are much better than the developers for Elder Scrolls: Skyrim which has a great many bugs. I agree that Skyrim (and every Bethesda game) has an infamous reputation for lots of bugs, much more so than the Wild, but I don’t think we can conclude much about the skills of the people jamming code into vim or notepad++ or whatever.

more...

I really dislike writing tests. There’s some amount of discomfort I’d be willing to sustain if I felt it they were beneficial, but I also find they’re rarely worth the bother. Some reasons why. Most of this probably applicable specifically to unit testing, but some other bits to integration testing.

more...

Sometimes there’s a bad implementation of a good idea, which typically results in discussions turning into shouting matches between people who see only the bad implementation and people who see only the good idea. And sometimes seems more like always when it comes to smart devices, or the internet of things, aka ioshit.

more...

Postel’s law, also known as the robustness principle, states that we should all be friends and try to get along. It’s also occasionally harmful. Here’s an example.

more...

I’m aware of two occasions on which Knuth advised editing existing code, as opposed to simply using it. One mention is in this interview, advocating for “re-editable” code instead of the fashionable reusable code, although it doesn’t amount to much more than that statement. In Coders at Work he describes a system of working that’s basically patch and diff. He writes a program, the master version that works for him, and ships it out. People receive and it and then modify it with change files so it works for them.

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

Real World Crypto 2020 was last week. It’s a conference I like because the talks are usually pretty interesting. The crypto talks have real world applications and the real world application talks have crypto. Afterwards, there’s usually not just something to be learned, but something to be done. I didn’t actually attend every talk, but here’s some notes.

more...

Every software project has a backlog of enhancement requests, unimplemented features. It may be explicitly tracked in a database, or perhaps just a sort of informal consensus among developers. Whether officially acknowledged or not, it exists.

more...

One way to slip malicious code into a project is to hack into their build server and just drop it in. Messy. Another way is to hack a trusted developer’s machine and alter the code there so that they commit it, but it might get spotted during code review. A third way is to become a developer, then yourself commit a seemingly innocuous patch containing an obfuscated backdoor. This is sneaky. Even better is to have somebody else intentionally commit the backdoor for you.

code

Consider this code to allocate some buffers.

void *
allocatebufs(int num)
{
    size_t limit = 256;

    if (num > limit)
        return NULL;
    return malloc(num * 64);
}

This isn’t top quality code, but it’s totally safe and secure. It does however trigger a warning about signed vs unsigned comparisons. Many developers don’t like to see those. Some will even try to fix it.

void *
allocatebufs(int num)
{
    size_t limit = 256;

    if (num > (int)limit)
        return NULL;
    return malloc(num * 64);
}

Now the warning is gone. And they’ve introduced a serious security hole.

If you’re a sneaky bastard, you might write the first code and submit it, knowing that a trusted developer somewhere down the line will alter it. And you’ve got perfectly plausible deniability. Your code was secure. They introduced the bug.

thoughts

This is just a thought experiment, and you can dissect it with the razor of your choosing, but what I think is interesting is the paradox of plausibility. What happened? The most likely explanation is the mundane one, that it’s just an accident. People introduce bugs like this with alarming regularity. No reason to suspect foul play. But it’s the dependable regularity of such errors that make the attack possible. If people didn’t introduce bugs fixing harmless warnings, the attack would never succeed.

(There was a concrete incident, somewhat similar, although this is not meant to be a comment on any particular patch or fix.)

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