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 0000000 O p e n S S L O p e n S S L \n \0 0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 000002b However, it can also cause output to be truncated: $ echo T3BlblNTTE9wZW5TU0wK`python -c 'print "="*44'` | openssl enc -d -base64 | hexdump -c 0000000 O p e n 0000004 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 0000000 a \0 \0 a \0 \0 a 0000007 $ echo A=== | openssl enc -d -base64 | hexdump -c 0000000 \0 0000001 -- Tomas Hoger _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
