ssh-keyscan bug (not really exploitable)

[Damien Miller]

On Sat, 6 Mar 2010, Joachim Schipper wrote:

> ssh-keyscan may, under very specific circumstances, be vulnerable to
> something akin to a buffer overflow.  It's probably impossible to
> exploit, though, if only because ssh-keyscan is not usually run on very
> large untrusted input files.

Not to mention adversarial ones.

> ssh-keyscan uses an fgets() wrapper that uses an unsigned int to keep
> track of the length of a buffer holding the current line. On machines
> with sufficient address space to hold UINT_MAX / 2 bytes, e.g. amd64,
> one can fill those bytes. The next call will be realloc(buf, 0), which
> free()s the buffer and returns a non-NULL zero-size chunk of memory. The
> program will then try to write to some point in memory about UINT_MAX /
> 2 past this newly-returned chunk.
> 
> Test case:
> 
> $ while true; do echo -n 'AAAAAAAAAAAAAAAA'; done | ssh-keyscan -f -
> 
> I stumbled upon this a while ago; I was trying to solve
> https://bugzilla.mindrot.org/show_bug.cgi?id=1565 ("ssh-keyscan doesn't
> like comment-lines"). The patch below rips out the fgets() wrapper and
> correctly handles both comments and ridiculously long lines.

please attach the patch to the bug if any haven't already done so.

-d