Hi!
Looking at the CVE-2015-0292 fix:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9febee0272
the added (eof v) check seems somewhat suspicious. While it prevents
integer underflow that causes out of bounds memcpy(), it still allows
some messing with output via proper number of trailing '=' signs. The
code was apparently written under assumption that eof is in the rage of
0 - 2, which are the only valid counts of '=' in proper base64 encoded
data.
One possible issue is that extraneous '=' will lead to decoded data to
contain extraneous trailing '\0's:
$ echo T3BlblNTTE9wZW5TU0wK`python -c 'print =*40'` | openssl enc -d -base64
| hexdump -c
000 O p e n S S L O p e n S S L \n \0
010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
02b
However, it can also cause output to be truncated:
$ echo T3BlblNTTE9wZW5TU0wK`python -c 'print =*44'` | openssl enc -d -base64
| hexdump -c
000 O p e n
004
Decoding should probably reject such malformed inputs. If the
expectation is to tolerate malformed inputs with extraneous trailing
'='s, it can do something like:
if (eof % 4 == 3) { /* error */ }
ret+=(v - ((eof/4)*3) - (eof%4))
This should ensure proper number of trailing '\0's are ignored.
However, there are other code paths that would need amending, as eof
gets reset to the expected 0-2 range in some cases. However, code will
also need to check that no '=' appears in the middle of the input.
Examples of other malformed inputs that should be rejected:
$ echo YQ==YQ==YQ== | openssl enc -d -base64 | hexdump -c
000 a \0 \0 a \0 \0 a
007
$ echo A=== | openssl enc -d -base64 | hexdump -c
000 \0
001
--
Tomas Hoger
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
