CVE-less vulnerabilities

Posted Jun 28, 2019 21:11 UTC (Fri) by rweikusat2 (subscriber, #117920)
In reply to: CVE-less vulnerabilities by Cyberax
Parent article: CVE-less vulnerabilities

You "clearly" haven't yet managed to move past the shtick of supplanting assertions of insanity for arguments. Parsing your second sentence yields "I [ie, you] don't know if there were more critical errors in [somehow defined] parsers than in order kinds of software". Even assuming the "but it may well be the case" (aka "probably") as given, one can only wonder what this is now supposed to express. You could even be trying to make my point for me: "As parsers are a lot simpler than sandboxes, a lot of bugs in them are eventually found and fixed, as evidenced by the very long list of CVEs relating to such bugs".

But that's really entirely besides the point. The base situation is still "it is unknown if $parser has security issues, hence it probably has" vs "it's unkown if $sandbox has security issues, hence, it's probably safe to use". These are still two appeals to ignorance used to justify both a statement "A" and the inverse statement "not A".

NB: I do not claim that the parser must be safe or that the sandbox must be unsafe, only that absolutely nothing can be validly concluded from ignorance.

CVE-less vulnerabilities

Posted Jun 28, 2019 22:39 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

The situation right now is this. If you have a C-based parser then it contains remote holes, end of story. Old C-based parsers just have the most obvious holes discovered (usualy).

Just look at libpng, libgzip, libjpeg, Apache, libcurl, ... for examples. Every one of them had multiple severe vulnerabilities in parsing.

So if you are using a C-based parser for untrusted data (which in this world means "all data") then you have at least one security hole.

Sandboxes are a way to mitigate this. They still can have bugs but there is just a handful of sandboxes, and some of them are written in languages that preclude most of regular C bugs.

Of course, if you want to be in the perfect world then you should turn off all computers tomorrow and start a Manhatattan-project style mass rewrite of C software in saner languages.

CVE-less vulnerabilities

Posted Jun 30, 2019 10:24 UTC (Sun) by nix (subscriber, #2304) [Link]

> You could even be trying to make my point for me: "As parsers are a lot simpler than sandboxes, a lot of bugs in them are eventually found and fixed, as evidenced by the very long list of CVEs relating to such bugs".

You're suggesting that finding more bugs in some piece of software is evidence that it has fewer bugs than other software in which fewer bugs were found in the first place, and you don't think this might perhaps be motivated reasoning so contorted that you could probably find singularities in it?

Thousands of image and other media parser bugs have been found (and continue to be found), even discounting the endless flood from Wireshark's network protocol dissectors. How many bugs have been found in Chrome's sandbox, which has annual events in which people basically get paid for finding holes in it? Is it as many as a dozen?