[openssl-dev] [PATCH] Fix (new!) uninitialized-use undefined behaviors

[Pascal Cuoq]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: uninitialized.patch
Type: application/octet-stream
Size: 3718 bytes
Desc: uninitialized.patch
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150325/f84e72cd/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150325/f84e72cd/attachment.txt>