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.
