1. 42

  2. 12

    Saw the title and was hoping this was a new, much less annoying front of the “giving vulnerabilities catchy names” trend, wherein we name them based on the developer’s reaction to finding out about them. Hoping to see the BLARGH and OHSHITIREALLYBOTCHEDTHAT vulns disclosed in the near future…

    1. 9

      Kudos, I’m not sure I’d be able to blog about a mistake like this publicly. It’s great he’s sharing this!

      We can learn from our mistakes, but other’s mistakes are less painful ;)

      1. 1

        Must have been quite a rough thought process to go through. Trying to roll out these fixes in a coordinated matter goes against so much of the rest of the OSS process. Glad the effort is made, of course, I can imagine this class of mistake happens a lot though.

        Being able to break down how this happened is super helpful as well. Helps people discover unknown unknowns.

        Now for the dumb thing that came up right when I saw that list of issues: Rust would have caught all of these issues with array bounds checking.

        Even without transitioning to a new language, maybe putting in bounds checks on arrays would be … Good. That or relying on iterator functions so there’s only one place where unchecked bounds are happening. Unfortunate that C is really messy about this, but you always have macros… I guess.

        1. 1

          I don’t agree with the policy of “don’t announce vulns until a fixed release is available”

          You have to assume there is a huge community of bad guys that already know about these bugs. Why not tell people early so they can mitigate the issues in other ways?