1. 17

  2. 8

    No? I mean, I came up with a better bug that was even more plausibly deniable without even trying.


    To clarify, a broken memcpy of a sha1 hash that only copied four bytes would have been much harder to detect by code inspection, and practically impossible to detect by random fuzzing. But it would have allowed anyone with a few hundred CPU hours to throw at the problem the ability to create a cert with a partial hash collision that ios would verify.

    1. [Comment removed by author]

      1. [Comment removed by author]

        1. [Comment removed by author]

          1. 3

            I think well informed infosec folks have seen it all before, know exactly how previous bugs happened, and are therefore less quick to rule out the possibility of unintentional mistakes.

            What do I think is strange? John Gilmore watching the IPSEC sausage get made, saying nothing, then ten years later somebody tells him the NSA interfered in the process and suddenly he says “oh, yeah, I saw the whole thing.” what???

            It’s all shadows on the cave wall.

    2. 1

      I’m impressed this wasn’t caught in code review. It was very obvious to me that there was a bug as I scrolled through. It was also very out of place among many automated refactorings.

      1. 9

        Well, here’s your chance to become a famous security researcher. Just scroll through the rest of the Apple’s open source code and spot the other very obvious bugs.

        Sorry for the snark, but this is no different from dozens of other bugs that exist for months or years, and then when it’s pointed out, everybody says “oh, it’s so obvious.” X had a bug like this once:

        if (geteuid != 0)

        Stupid bug, missing parens means the function isn’t called; instead its address is compared to 0. There were likewise hundreds (though not thousands, X being less popular than ios) of comments complaining about how X developers can’t read code, or C sucks, or if only they had enabled this compiler warning it never would have happened.

        1. 1

          Yeah but look at the diff! Assuming SOMEONE other than the original author looked at it, it would’ve been caught during a casual scroll-through.

          1. 2

            I don’t know how “casual” it was, but I did exactly that when a link to that diff was posted on HN. The title didn’t say what the issue was, I hadn’t heard of the bug before, and I had no idea what I was looking for, other than that there’s a bug or hole or something bad going on in there.

            And I did spot the double goto the instant it scrolled in view.

            Actually I think glancing through diffs is a very nice way to catch things like that. By contrast, having someone tell you to read through goodness knows how many thousand lines of reasonably mature code is, well.. meh. Been there, done that. The thing with good diffs is that they break things up for you for review. And it’s new code that hasn’t been seen by too many pairs of eyeballs, so easy-to-catch oopsies are more likely to be present. But if you just start with a huge code dump, it’s your responsibility to chunk it into parts for which you have the attention span to review carefully enough. It does take a lot of effort and it can be quite demotivating.

            I wish I could tell source-changes@openbsd to mail me diffs along with the commit logs. Right now I only stop on some of the more interesting sounding ones and go on cvsweb for the diffs.