tests: Avoid buffer overflow when creating invalid PKCS#1.5 paddded data
* The sign array is the whole APDU. * For payload of less than 256 bytes (for RSA keys of less than 2k), we fit Lc part in one byte (instead of 3 as in template for larger keys), which means the "header" is only 5 bytes long. The Le value is adjusted on line 298. * On the sixth byte (line 299), there already start PKCS#1.5-padded data [1]. This byte needs to be zero from [1] * The line 300 marks where the intentional error is -- we are trying to create bad PKCS#1.5 padding -- we overwrite it with 0xff padding later. * The memmove() line is moving the tail of padded data (where the actual data is stored) by shrinking the padding in the middle. * The padding (for simplicity, 0xff bytes are used) starts on the 7th byte and spans before the next 0x00 byte. * The memmove(), in theory, should copy data up to the end of the original, 256 bytes payload, but it can move also the last byte which specifies the Le (handled separately)v. This means, we were 3 bytes off. * target (&sign[6]) -- this is the place where the padding starts in the new buffer * length (key_bits/8 - 1) -- the length of payload is 128 bytes, but we already wrote the first byte (line 299). * the source was wrong (&sign[sign_len-key_bits/8]) -- we need to find a place where to start copying data from to match the ends of payloads in the buffer (128 B and 256 B). * The lines 302 and 303 adjust the buffer lengths and appends 0x01 (Le) of APDU. [1] https://tools.ietf.org/html/rfc2313#section-8.1 Signed-off-by: Jakub Jelen <jjelen@redhat.com>
parent
0196abb1
Loading
Loading
Pipeline
#3451
failed
with stages
in
1 hour, 50 minutes, and 39 seconds
Loading
Please register or sign in to comment