Hello, we have found some uses of uninitialized memory in OpenSSL that, unlike other infamous ones, have not been previously discussed (to the best of our knowledge).
These uses of uninitialized memory have characteristics that might make them worth fixing even if other uses of uninitialized memory remain in OpenSSL: - the uninitialized access occurs in a single branch of an if-then-else. An obvious optimization for a compiler is to compile out the condition and the branch containing undefined behavior (UB), leaving only the non-undefined branch. The blog post below shows the widely used GCC C compiler optimizing a program according to this very idea: http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined - Sometimes the obligation the compiler has to produce code that must work for inputs that do not cause UB will in practice make the UB relatively harmless. Here, the uninitialized access occurs within a macro, BN_with_flags, meaning that a particular use of the macro for inputs that cause UB is NOT protected by separate compilation compiler constraints. - If a compiler has applied the optimization from the aforementioned blog post, or if a future compiler decides to, the resulting flaw will not be visible in functional tests (it will not be a functional bug) but it could still lead to side-channel vulnerabilities in OpenSSL (as far as I understand the surrounding code). - The uninitialized memory access does add any value. It does not make the PRNG work better or anything, it is purely incidental (it occurs in a pattern that could also have been implemented using bit-fields, the difference being that it is legal to assign x.bitfield1 when x.bitfield2 is uninitialized, whereas doing so by hand as in the macro BN_with_flags invokes undefined behavior). With help of an anonymous good soul on the Internet, we have investigated the code produced by the GCC version that was used for the aforementioned blog post 4.4.3. We have found that: * GCC authors must not have found that this agressive optimization was very desirable, since this GCC behavior had disappeared in 4.4.7. * Nevertheless, GCC 4.4.3 was the packaged compiler for a Ubuntu LTS distribution. The behavior in GCC 4.4.3 was not acknowledged as a bug, and it was not fixed in the Ubuntu distribution, and it could be re-introduced in a future GCC version. The behavior may also already exist or be introduced in another C compiler. * GCC 4.4.3 does not appear to optimize the specific source code pattern in OpenSSL the way it optimizes the one in the blog post. Best regards, Pascal Cuoq TrustInSoft Chief Scientist
uninitialized.patch
Description: uninitialized.patch
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
