| Age | Commit message (Collapse) | Author |
|---|
|
The functions SRP_Calc_client_key() and SRP_Calc_server_key() were
incorrectly returning a valid pointer in the event of error.
Issue reported by Yuan Jochen Kang
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 308ff28673ae1a4a1b346761224b4a8851d41f58)
|
|
Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matt Caswell <matt@openssl.org>
GH: #1017
(cherry picked from commit c9141a43e246d527ec8b5a97b98e93fc31b0f0b8)
|
|
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>
|
|
There were some memory leaks in the creation of an SRP verifier (both on
successful completion and also on some error paths).
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit bf95cde28712cfcad90cb3975cdcb8e5c0f20fde)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 2d540402aac7a05af9c99b58864d53c0201a0b42)
|
|
We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 0f539dc1a2f45580435c39dada44dd276e79cb88)
Conflicts:
Makefile.org
apps/Makefile
test/Makefile
|
|
Reviewed-by: Matt Caswell <gitlab@openssl.org>
|
|
Ensure all calls to RAND_bytes and RAND_pseudo_bytes have their return
value checked correctly
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Invalid parameters passed to the SRP code can be overrun an internal
buffer. Add sanity check that g, A, B < N to SRP code.
Thanks to Sean Devlin and Watson Ladd of Cryptography Services, NCC
Group for reporting this issue.
|
|
|
|
PR: 3165
Submitted by: Daniel Richard G.
(cherry picked from commit 2df9ec01d563f9cc2deab07e8c3391059d476592)
|
|
|
|
|
|
Submitted by: Bruce Stephens <bruce.stephens@isode.com>
Use same construct for EXHEADER in srp/Makefile as other makefiles to cope
with possibly empty EXHEADER.
|
|
|
|
This meant a slight renumbering in util/libeay.num due to symbols
appearing in 1.0.0-stable. However, since there's been no release on
this branch yet, it should be harmless.
|
|
|
