diff options
| author | Emilia Kasper <emilia@openssl.org> | 2016-02-24 12:59:59 +0100 |
|---|---|---|
| committer | Emilia Kasper <emilia@openssl.org> | 2016-02-25 15:42:48 +0100 |
| commit | 380f18ed5f140e0ae1b68f3ab8f4f7c395658d9e (patch) | |
| tree | 83e686e480f176176595a3b2f388be366b774b08 /CHANGES | |
| parent | 37529928faa8456e85a9c5ad9255517da8dd0c61 (diff) | |
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>
Diffstat (limited to 'CHANGES')
| -rw-r--r-- | CHANGES | 15 |
1 files changed, 15 insertions, 0 deletions
@@ -4,6 +4,21 @@ Changes between 1.0.2f and 1.1.0 [xx XXX xxxx] + *) Deprecate SRP_VBASE_get_by_user. + SRP_VBASE_get_by_user had inconsistent memory management behaviour. + In order to fix an unavoidable memory leak (CVE-2016-0798), + SRP_VBASE_get_by_user was changed to ignore the "fake user" SRP + seed, even if the seed is configured. + + Users should use SRP_VBASE_get1_by_user instead. Note that in + SRP_VBASE_get1_by_user, caller must free the returned value. Note + also that even though configuring the SRP seed attempts to hide + invalid usernames by continuing the handshake with fake + credentials, this behaviour is not constant time and no strong + guarantees are made that the handshake is indistinguishable from + that of a valid user. + [Emilia Käsper] + *) Configuration change; it's now possible to build dynamic engines without having to build shared libraries and vice versa. This only applies to the engines in engines/, those in crypto/engine/ |