Skip to content
Commit 03d3dd61 authored by Jakub Jelen's avatar Jakub Jelen
Browse files

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: default avatarJakub Jelen <jjelen@redhat.com>
parent 0196abb1
Loading
Loading
Loading
Pipeline #3451 failed with stages
in 1 hour, 50 minutes, and 39 seconds
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment