The wrong conditional check for newly allocated memory would make the
function to fail when the allocation was successful and access invalid
memory when the allocation failed.
Signed-off-by: Anderson Toshiyuki Sasaki <ansasaki@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Commit c306a693f3 ("buffer: Use size_t for argc argument in
ssh_buffer_(un)pack()") mentioned unpack in the commit log, but it only
touches the pack variants. Extend the conversion to unpack.
Pre-initialize the p pointer to avoid possible use before
initialization in case of early argc check failure.
This fixes build failure:
.../libssh-0.8.6/src/buffer.c: In function 'ssh_buffer_unpack_va':
.../libssh-0.8.6/src/buffer.c:1229:16: error: assuming signed overflow does not occur when simplifying conditional to constant [-Werror=strict-overflow]
if (argc == -1){
^
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
Ensure most of the abstraction around the 3 libs are consistent.
Signed-off-by: Aris Adamantiadis <aris@0xbadc0de.be>
Reviewed-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
By default, the list of already stored known host types is preferred,
but this selection so far ignored the SHA2 extension and excluded these
keys in the KEXINIT list leading to not using this extension if not
explicitly enabled from configuration.
This commit extends the default list with the SHA2 signatures algoritms
and compares only base types so they can be listed in the KEXINIT list.
This adjust the tests to expect the full list of algorithms to pass.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
If the server had an RSA host key, it provided unconditionally SHA2
signatures without consulting the client proposed list of supported host
keys.
This commit implements more fine-grained detection of the extension
to provide the client with valid signatures according to RFC 8332
Section 3.1.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
The default rekeying recommendations are specified in
RFC4344 Section 3 (First and Second Rekeying Recommendations).
Additionally, the rekeying can be specified in configuration
file/options allowing us to turn the rekeying off, base it
on time or make it more strict.
The code is highly inspired by the OpenSSH rekeying code.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
And remove most of the direct access to the structure throughout the code
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
If the rekey is initialized by client, it sends the first KEXINIT
message, changes to the INIT_SENT state and waits for the KEXINIT
message from the server. This was not covered in the current filter.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Daiki Ueno <dueno@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
This is more reliable fix than 83f2ac4a, which was failing for the
server initialized rekeying, because the session_state is altered
by receiving the KEXINIT from server.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Reviewed-by: Andreas Schneider <asn@cryptomilk.org>
