A malicious (authenticated) server could send a long AT_NEXT_PSEUDONYM
or AT_NEXT_REAUTH_ID attribute (max. 1016 bytes) that the client then
attempts to return in an AT_IDENTITY attribute that could overflow the
fixed-sized stack buffer `out_buf` by a few bytes (writing into the
`encr_buf` buffer).
This refactoring first calculates the length required to encode the
attributes (with and without encryption) and accounts for the overhead
necessary for AT_ENCR_DATA, AT_PADDING, and AT_MAC (some limits are
enforced and error handling is added where appropriate). Then correctly
sized buffers are allocated and the attributes are encoded pretty much
as before. Except that the encoding of AT_RES is corrected (it actually
worked fine for up to 31 bytes, so in practice it wasn't a problem),
AT_PADDING is not added if data is already block-aligned, and it corrects
handling of AT_NOTIFICATION (they are never sent encrypted according to
the RFCs, but protected with a MAC).
Fixes: f8330d0395 ("Added a libsimaka library with shared message handling code for EAP-SIM/AKA")
Tobias Brunner
cd24806543