Ncat segfault with -l --ssl < /dev/zero

[David Fifield <david () bamsoftware com>]

On Mon, Feb 22, 2010 at 10:00:14PM -0600, Mak Kolybabi wrote:
> As an aside, I often segfault ncat with:
>
> % ./src/nmap/nmap --script scripts/ssl-enum -PN -p5061 -d2 127.0.0.1
>
> and
>
> % ./src/nmap/ncat/ncat -l --ssl -k -v 5061 > /dev/null < /dev/zero
> Ncat: Version 5.21 ( http://nmap.org/ncat )
> Ncat: Generating a temporary 1024-bit RSA key. Use --ssl-key and --ssl-cert to use a permanent one.
> Ncat: SHA-1 fingerprint: 4C57 23D2 66A3 050D FC84 8613 6E85 BC33 3EEA 7419
> Ncat: Listening on 0.0.0.0:5061
> Ncat: Connection from 127.0.0.1.
> ...
> Ncat: Connection from 127.0.0.1.
> zsh: segmentation fault  ./src/nmap/ncat/ncat -l --ssl -k -v 5061 > /dev/null < /dev/zero

I reproduced this and fixed it in r16845. New connections get their file
descriptor added to two lists in Ncat: the read list and the broadcast
list. When the connection is closed, the descriptor is supposed to be
removed from both lists. There was a bug in the removal code, where a
pointer to the struct removed from the first list was dereferenced to
get the descriptor (should have been the same descriptor) to remove from
the second list. What ended up happening is that the wrong descriptor
was removed from the second (broadcast) list.

I'm surprised this hasn't been seen to cause a problem before, but I
guess it's because the bogus leftover descriptors remained selectable
and were subsequently closed, or caused a broken pipe when written to or
something. It broke in the SSL case because SSL connections have a
separately dynamically allocated little struct that is freed when the
connection is closed. The program was accessing the freed memory.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/