This patch simply reworks the code to make it more understandable and
reduce if() branches.
It also avoids reallocs, and instead uses a support buffer to hold
intermediate results of the hmac function so that no buffer overrides
happen when the requested size is not an exact mutiple of the digest_len.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The zeroing MUST use the correct cipher length as keys can be both
longer or shorter than the digest. In one case only some part of the key
may end up being zeroed, in the other memory corruption may happen as
we zero memory we do not own.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This adds the OpenSSH HMACs that do encrypt then mac. This is a more
secure mode than the original HMAC. Newer AEAD ciphers like chacha20 and
AES-GCM are already encrypt-then-mac, but this also adds it for older
legacy clients that don't support those ciphers yet.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This adds a flag to the type structures to track if we use a
Encrypt-then-MAC cipher instead of Encrypt-and-MAC. EtM is a more secure
hashing mechanism.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This will make it easier to do Encrypt-then-MAC checks as those will be
on the direct encrypted data received before decrypting which means they
are not allocated in an ssh buffer at that point yet.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
This is not supported by OpenSSH and not recommended to be implemented
either.
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
src/pki_gcrypt.c:485:10: error: assuming signed overflow does not occur
when simplifying conditional to constant [-Werror=strict-overflow]
Fixes T132
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Buffer (un)packing was broken on compilers that are not
gcc-compatible since the checks for an argument count of
-1 have been removed from ssh_buffer_(un)pack(). This
fix no longer uses GCC extensions for the __VA_NARG__
macro, but only plain C99.
Note: The macro can no longer count empty argument lists
(results in compile error) which was not needed anyway.
Signed-off-by: Tilo Eckert <tilo.eckert@flam.de>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Ensure to honor the client preference ordering when enabling one of
the RFC8332 RSA signature extensions (`rsa-sha2-{256,512}`).
Before this change, libssh unconditionally selects the `rsa-sha2-512`
algorithm for clients which may have offered "rsa-sha2-256,rsa-sha2-512".
The change can be observed before-and-after with the pkd tests:
./pkd_hello -t torture_pkd_openssh_rsa_rsa_sha2_256_512
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Add four passes to the pkd tests to exercise codepaths where an
OpenSSH client requests these HostKeyAlgorithms combinations:
* rsa-sha2-256
* rsa-sha2-512
* rsa-sha2-256,rsa-sha2-512
* rsa-sha2-512,rsa-sha2-256
The tests demonstrate that the third combination currently fails:
libssh ends up choosing `rsa-sha2-512` instead of `rsa-sha2-256`,
and the initial exchange fails on the client side citing a signature
failure.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
OpenSSH has a block size of 8 so we need to always add padding.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
In 3341f49a49, some direct assignments
to OpenSSL structures was replaced with usage of getter and setter
macros. Ensure to `bignum_safe_free` a couple of intermediate values
in error paths for `pki_signature_from_blob` DSS and ECDSA cases.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Check for a potential NULL result from `pki_signature_from_rsa_blob`
in `pki_signature_from_blob`. Otherwise the following `sig->type_c`
will result in a segfault.
Introduced in 7f83a1efae.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Harden the error path in 'ssh_dh_init_common' such that
all potential allocations are free'd upon exit.
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to `SSH_STRING_FREE` the pubkey_blob local in
`ssh_server_dh_process_init`. The leak can be seen with
valgrind and the pkd tests with:
valgrind \
--leak-check=full \
--show-leak-kinds=definite \
./pkd_hello -i1 -t torture_pkd_openssh_rsa_rsa_diffie_hellman_group14_sha1
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Fix a memory leak whereby the x, y, and k bignum fields within
a session's next_crypto structure were being unintentionally
initialized twice.
The leak can be seen before the fix with valgrind and the pkd
tests with:
valgrind \
--leak-check=full \
--show-leak-kinds=definite \
./pkd_hello -i1 -t torture_pkd_openssh_rsa_rsa_diffie_hellman_group_exchange_sha256
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure to close the moduli file stream in `ssh_retrieve_dhgroup`.
The leak is observable with the pkd tests and valgrind with:
valgrind \
--track-fds=yes \
./pkd_hello -i1 \
-t torture_pkd_openssh_rsa_rsa_diffie_hellman_group_exchange_sha256
Signed-off-by: Jon Simons <jon@jonsimons.org>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
