Package: dsniff Version: 2.4b1+debian-18 Severity: important Tags: patch There is an opportunity for a DoS in dsniff's Tabular Data Stream protocol handler that can be found in decode_tds.c:decode_tds(): If both the third and fourth byte of a new connection (or anything that gets interpreted as a TDS packet header) are zero, dsniff will hang.
The two bytes are interpreted as the length of a packet header which, according to <http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-TDS%5D.pdf>, must be 8 bytes long. If the advertized length is 0, the loop will never advance, reading the same broken header again and again. I can reliably reproduce the bug by having dsniff analyze a stream of null bytes being sent to 1433/tcp: ,---- | $ nc -l 1433 > /dev/null & | [1] 20888 | $ sudo dsniff -n -i lo & | [2] 20889 | $ dsniff: listening on lo | $ dd if=/dev/zero bs=1024 count=1 | nc localhost 1433 | 1+0 records in | 1+0 records out | 1024 bytes (1.0 kB) copied, 1.3934e-05 s, 73.5 MB/s | [1]- Done nc -l 1433 > /dev/null `---- Adding a simple check at the beginning of the loop (line 147) should solve this problem. if (th->size != 8) { /* wrong header length */ return (strlen(obuf)); } Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
