There's an off-by-one heap-overflow in the ieee802.11 printer, which can be triggered by a maliciously crafted 802.11 frame. The link type must have been explicitly specified for this to work. The function parse_elements() in print-802_11.c checks the length pbody->tim.length from the frame for too small values in line 265, but then uses the wrong variable in the following range check in line 267. Since pbody->tim.length is defined as a u_int8_t it can hold a maximum value of 255, which in turn would copy 252 bytes into pbody->tim.bitmap, which is only 251 bytes of size. 253 case E_TIM: 254 /* Present, possibly truncated */ 255 pbody->tim_status = TRUNCATED; 256 if (!TTEST2(*(p + offset), 2)) 257 return; 258 memcpy(&pbody->tim, p + offset, 2); 259 offset += 2; 260 if (!TTEST2(*(p + offset), 3)) 261 return; 262 memcpy(&pbody->tim.count, p + offset, 3); 263 offset += 3; 264 265 if (pbody->tim.length <= 3) 266 break; 267 if (pbody->rates.length > sizeof pbody->tim.bitmap) 268 return; 269 if (!TTEST2(*(p + offset), pbody->tim.length - 3)) 270 return; 271 memcpy(pbody->tim.bitmap, p + (pbody->tim.length - 3), 272 (pbody->tim.length - 3)) The current tcpdump release 3.9.5 is still vulnerable. This got fixed [1] in CVS Head and in the tcpdump_3_9 branch. [1] http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-802_11.c?r1=1.42&r2=1.43 Reproducible: Didn't try
Thanks, patch in 3.9.5-r2!
amd64 stabl
e Stable for HPPA.
Is there a CVE for this issue? What is the potential effect (DoS, crash, system subversion?)? If there isn't already a CVE, could we try to get one so other distros could fix it as well?
CVE is a good idea, x86 stable.
(In reply to comment #4) > Is there a CVE for this issue? What is the potential effect (DoS, crash, system > subversion?)? > > If there isn't already a CVE, could we try to get one so other distros could > fix it as well? "minor tcpdump 4-byte stack overflow" Michael K. Johnson [johnsonm->rpath.com] has requested a CVE for this. He also reviewed the code and claims at best this is only a DoS.
SPARC stable
====================================================== Name: CVE-2007-1218 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1218 Reference: FULDISC:20070301 tcpdump: off-by-one heap overflow in 802.11 printer Reference: URL:http://seclists.org/fulldisclosure/2007/Mar/0003.html Reference: CONFIRM:https://issues.rpath.com/browse/RPL-1100 Reference: MISC:https://bugs.gentoo.org/show_bug.cgi?id=168916 Off-by-one buffer overflow in the parse_elements function in the 802.11 printer code (print-802_11.c) for tcpdump 3.9.5 and earlier allows remote attackers to cause a denial of service (crash) via a crafted 802.11 frame. NOTE: this was originally referred to as heap-based, but it might be stack-based.
this issue has been assigned CVE-2007-1218
ppc stable
alpha@gentoo.org
Last comment should have been: "stable on alpha" (Mental note) Don't use bugzilla too early in the morning. Don't use bugzilla too early in the morning. ... Sorry.
net-analyzer/tcpdump-3.9.5-r2 stable on ppc64
Stable on MIPS.
it seems to be commonly accepted that this is DoS only (i.e. see comment #6), so this should be B3. Voting no
just a DoS? -> voting no
arm/ia64/s390/sh done
