[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2422A407-94F6-4AB2-9928-310C5089EA5D@gmail.com>
Date: Tue, 25 Jun 2019 07:14:52 -0700
From: Matthew Fernandez <matthew.fernandez@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Thousands of vulnerabilities, almost no CVEs:
OSS-Fuzz
> On Jun 25, 2019, at 06:41, Bob Friesenhahn <bfriesen@...ple.dallas.tx.us> wrote:
>
> * Consumption of uninitialized data (e.g. image data) which is not
> used to make important decisions. This is usually due to unhandled
> cases or error handling which does not quit immediately.
C/C++ compilers will infer backwards from uninitialized variable reads (undefined behavior in these languages) that preceding code is unreachable. For example, when moving from GCC 6 series to GCC 7 series we found one of our code bases would produce a binary that would only segfault when compiled at >= -O2. We root caused this to exactly the situation you describe: an error handling path that read uninitialized variables. The compiler appeared to infer backwards that the error check itself was a no-op as the true branch led to unconditional UB (this is my interpretation of its actions; I did not delve into the compiler’s internals).
I’m probably telling you things you already know and it sounds like you don’t consider such issues worth addressing, but I just wanted to point out that these are not theoretical. These cause real problems for users and, for open source software, you may not have full control over what toolchain/flags users build your code with.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
