Hello,
I have sent the following to [EMAIL PROTECTED], received no response. Could
someone authoritative at least confirm the existence of the outlined
problems.
Save yourself,
Nergal
Forwarded message:
> Date: Sun, 15 Apr 2001 14:43:49 +0200 (CEST)
> From: Rafal Wojtczuk <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Bugs in tcpdump-3.6.2
> Hello,
> I have found a few security bugs/coding errors in tcpdump-3.6.2 (all
> of them are also present in tcpdump-current). Their severity is not high, yet
> they definitely should be fixed. As the patches are straightforward, I allow
> myself to burden the tcpdump team with their implementation. If the next
> tcpdump version is not planned to be released soon, I would be grateful for
> notifying me when the temporary official patch is ready.
>
> 1) Memory leak.
> Even when the address resolution is turned off with -n flag, each call to
> getname() (or ipaddr_string()) with a previously unseen IP as an argument
> results in a call to newhnamemem(), which allocates memory. This memory is
> never freed. So, if I flood tcpdump with IP packets with forged source
> addresses (there are 2^32 different addresses possible :) ), tcpdump will
> allocate memory with the rate proportional to the bandwidth. Bad. Also,
> single-linked lists are not too efficient (one could create a list with
> 2^32/HASHNAMESIZE= 1e6 nodes). It is advisable to use a hashing algorithm
> which depends on a pseudo-random parameter (determined at tcpdump startup).
> This parameter should be impossible for an attacker to determine.
>
> 2) Stack buffer oveflow in smi_decode_oid()
> smi_decode_oid() parses data from the network and placed the results in the
> location pointed to by its second argument (named oid). No bounds are
> checked. The offending line 905 (placed in a loop) in print-snmp.c reads:
> oid[(*oidlen)++] = o;
>
> smi_decode_oid() is called e.g. by smi_print_variable():
> static SmiNode *smi_print_variable(struct be *elem)
> {
> unsigned int oid[128], oidlen;
> SmiNode *smiNode = NULL;
> int i;
>
> smi_decode_oid(elem, oid, &oidlen);
> As we see, "oid" array can be overflowed. Remote code execution is
> imaginable.
> One must notice that in order to exploit this flaw:
> a) tcpdump must be compiled with #define LIBSMI
> b) tcpdump must be run with -m flag
> c) probably snaplen must be larger than default, around 200
>
> 3) Stack buffer overflow in dhcp6ext_print()
> The offending line 209 in print-dhcp6.c reads
> strncpy(buf, &cp[4], len);
> "len" parameter is taken from the network, has nothing to do with the
> (static) size of "buf". However, sizeof(buf)=8192, so snaplen would have to
> be more than 8k for an overflow to occur.
>
> 4) Untidy coding in ataddr_string()
> The offending code reads:
> if (sscanf(line, "%d.%d.%d %256s", &i1, &i2, &i3,
> nambuf) == 4)
> The hardcoded "256" limit is unrelated to sizeof(nambuf), which on linux
> actually equals 64. However, "line" is not read from the network (from
> /etc/atalk.names in fact), so no malicious action can be taken.
>
> Save yourself,
> Nergal
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
