Christos Zoulas committed: > Module Name: src > Committed By: christos > Date: Sun Oct 4 19:32:48 UTC 2020 > > Modified Files: > src/crypto/external/bsd/openssl/dist/crypto/bn: bn_print.c > src/crypto/external/bsd/openssl/dist/include/openssl: bn.h > src/crypto/external/bsd/openssl/lib/libcrypto: crypto.map > > Log Message: > Add BN_oct2bn(3) for factor(6) > > > To generate a diff of this commit: > cvs rdiff -u -r1.1.1.10 -r1.2 \ > src/crypto/external/bsd/openssl/dist/crypto/bn/bn_print.c > cvs rdiff -u -r1.1.1.3 -r1.2 \ > src/crypto/external/bsd/openssl/dist/include/openssl/bn.h > cvs rdiff -u -r1.8 -r1.9 \ > src/crypto/external/bsd/openssl/lib/libcrypto/crypto.map
I was going to ask for this to be reverted, but I see that it has already been done - thank you. I will nonetheless state my reasons for wanting it reverted, to keep everyone vigilant in case someone tries something like this again. Although it's not stated in the commit message, this commit also changes the behavior of BN_asc2bn() to interpret numbers with a leading zero as octal rather than decimal. This raises a huge red flag. OpenSSL is security critical code, and BN_asc2bn() is likely used for parsing numbers in text representations of security critical data. This change makes is possible to deliberately construct a text representation that will be interpreted differently on NetBSD vs. other systems, or when parsed using OpenSSL vs. another parser. For example, if an RSA key modulus is stored in a file in text form and parsed using BN_asc2bn(), it is likely possible to construct a key file that results in a secure key on another system, but a trivially factorable one on NetBSD. A large number of vulnerabilities have been caused by similar minor differences between implementations of parsers for Unicode, HTTP, SMTP, and JSON. We should not introduce another one in OpenSSL. Also, the behavior of BN_asc2bn() after the change is different from that specified in the man page. -- Andreas Gustafsson, g...@gson.org