Files
openssl/apps
Emilia Kasper 380f18ed5f CVE-2016-0798: avoid memory leak in SRP
The SRP user database lookup method SRP_VBASE_get_by_user had confusing
memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no
way of distinguishing these two cases.

Specifically, SRP servers that configure a secret seed to hide valid
login information are vulnerable to a memory leak: an attacker
connecting with an invalid username can cause a memory leak of around
300 bytes per connection.

Servers that do not configure SRP, or configure SRP but do not configure
a seed are not vulnerable.

In Apache, the seed directive is known as SSLSRPUnknownUserSeed.

To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user
is now disabled even if the user has configured a seed.

Applications are advised to migrate to SRP_VBASE_get1_by_user. However,
note that OpenSSL makes no strong guarantees about the
indistinguishability of valid and invalid logins. In particular,
computations are currently not carried out in constant time.

Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-25 15:42:48 +01:00
..
2011-03-16 11:50:33 +00:00
2016-02-20 14:53:53 +01:00
2016-02-19 11:06:54 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-18 12:24:44 -05:00
2016-02-11 08:53:11 +00:00
2016-02-20 14:53:53 +01:00
2016-02-19 11:06:54 +01:00
2016-02-20 14:53:53 +01:00
2016-02-17 09:46:10 -05:00
2015-11-20 13:40:53 +00:00
2015-12-16 16:14:49 -05:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2015-11-21 14:37:24 +01:00
2009-09-06 15:49:46 +00:00
2016-02-12 04:42:22 +01:00
2016-01-12 01:00:31 -05:00
2015-12-16 16:14:49 -05:00
2016-02-20 14:53:53 +01:00
2016-02-24 14:23:21 -05:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-02-20 14:53:53 +01:00
2016-01-26 16:40:43 -05:00
2016-01-26 16:40:43 -05:00
2016-02-20 14:53:53 +01:00
2009-09-07 17:57:18 +00:00
2016-02-10 19:04:08 +00:00