Comments by "Anony Mousse" (@anon_y_mousse) on "These New Xorg Vulnerabilities Are Older Than Me" video.

  1. They were fixed in September, but truthfully, they should never have existed in the first place because everyone should check such bounds by default anyway.
    2
  2. Fair point, though when I write code that multiplies values to perform allocations I always check it regardless of malicious intent.
    2
  3. I find it interesting that the bugs they fixed were all relatively easy to fix, especially if you look at the code, but also they're the kind of bugs that should not have existed in the first place regardless of fuzz testing, but more extensively that you'd have to actually be malicious to make use of them, and for that matter that anyone is still fixing any bugs in X. It's kind of amazing too, how easy it was to follow along with this video because of how cleanly the code is laid out. I didn't already have a copy of the source for libXpm, and annoyingly it had some configuration that only happened when you `make`'d it, but once that was done it was super easy to trace through it by hand. The majority of problems occur in inner functions that the user can't access and are a direct result of not fully checking input before calling them. Also, ParseComment() still has a bug where it doesn't compare the characters read so far against the buffer's maximum size, which if you look in the generated header, XpmI.h, is set to BUFSIZ. There may be more, but that one was within the first 20 lines of the function. Also also, `git blame` is such a cool tool.
    1
  4. True, but there are more and if you `git blame` you can see they were only fixed in September of this year. Of course, that's not to say that I would advocate for scrapping the whole project, but I'm more of a realist when it comes to these things.
    1