Hi, Tavis Ormandy found some bugs in OpenSSL's ASN.1 and buffer code that can be exploited to cause a heap overflow: http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification function (openssh_RSA_verify): http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c?rev=HEAD;content-type=text%2Fplain That's now eight exploitable bugs that this change has saved us from. It's a good lesson in how excising even a relatively small amount of complex attack surface can make a substantial difference to the security of an application. This gloating only applies to sshd though - private key loading still uses the affected OpenSSL code, so if you are somehow allowing untrusted users to supply private keys to ssh, ssh-keygen or ssh-add in a privileged context then you should apply the OpenSSL fixes forthwith. -d
Le 19/04/12 14:19, Damien Miller a ?crit :> Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use > of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification > function (openssh_RSA_verify):Hi Damien, In order to check the impact that this bug has on other software using libcrypto, your email caught my eye. I have a hard day figuring out if RSA_verify from libcrypto is vulnerable. From what I could read, this bug is only exploitable when the ASN.1 parsing is done on BIO objects, and RSA_verify parses from memory, thus avoiding the bug. (I could see it calls d2i_X509_SIG() which is not bio nor fp). OpenSSL also claims [1] that this bug is not exploitable on SSL/TLS clients/servers, so my opinion is that OpenSSH (and other software using RSA_verify) are not vulnerable. But of course this doesn't alter anything in the good security practices in use for OpenSSH, that will protect from the next ASN.1 bug :) Aris [1] http://www.openssl.org/news/secadv_20120419.txt
Damien Miller wrote:> Hi, > > Tavis Ormandy found some bugs in OpenSSL's ASN.1 and buffer code that > can be exploited to cause a heap overflow: > > http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html > > Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use > of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification > function (openssh_RSA_verify): > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c?rev=HEAD;content-type=text%2Fplain > > That's now eight exploitable bugs that this change has saved us from. > It's a good lesson in how excising even a relatively small amount of > complex attack surface can make a substantial difference to the security > of an application. > > This gloating only applies to sshd though - private key loading still > uses the affected OpenSSL code, so if you are somehow allowing untrusted > users to supply private keys to ssh, ssh-keygen or ssh-add in a > privileged context then you should apply the OpenSSL fixes forthwith.I cannot understand this sentence. Issue is with operation on file stream. I cannot remember exact version when key reading from streams was replaces by "atomic" operation - read file into memory and then use memory to parse. Please could you clarify are user programs vulnerable or not ?> -d >Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/