Package: ssh-agent-filter Version: 0.2-1 Severity: important Tags: upstream fixed-upstream pending jessie stretch buster sid
A two-byte out-of-bounds stack write has been found in base64_encode(). Quoting relevant parts of the conversation with the security team: 21.11.18 20:21 Timo Weingärtner: > while developing a new feature for ssh-agent-filter I noticed an error > interpreting nettle's API documentation I made when I first wrote an > adjacent function (right in the beginning; every version in Debian is > affected). > > The problem is BASE64_ENCODE_LENGTH() returning the size of the encoded > string without the padding added in the finalization step. If the > programmer forgets to take BASE64_ENCODE_FINAL_LENGTH into account this can > result in up to two bytes with value '=' being written past the end of the > buffer. > > I was not able to crash ssh-agent-filter on my amd64 machine, so I guess the > bug is hidden by alignment on the stack. 23.11.18 15:00 Timo Weingärtner: > The strings to be base64-encoded (there is no decoding) is from the user's > ssh-agent and — if confirmation is used — strings from a remote attacker > (the same user or root on a machine the user connected to via (af)ssh) might > get encoded. Encoded strings are compared against, output to terminal in > debug mode or to the user via ssh-askpass in confirmation mode. > > Incoming connections are handled in threads, so the entire filter process > might crash, resulting in DoS. > > The data written past the end of the buffer is always the same ('='); the > attacker can only influence the number of extra bytes written (string length > % 3). I don't really know about the exact stack layout and alignment on > neither amd64 nor other archs, but if the stack grows downward these bytes > would get written into the base64_ctx, unused space because of alignment, > or the canary. 23.11.18 20:15 Moritz Mühlenhoff: > Thanks for the summary. This sounds all quite limited impact-wise and sounds > like a perfect candidate for a targeted fix via stable-proposed-updates. Do > you agree? If so, let's open a a in the BTS which can then be closed with > the upload to unstable (and also serves as a good reference for the stable > update).
signature.asc
Description: This is a digitally signed message part.