Bug 168916 – net-analyzer/tcpdump off-by-one heap overflow in 802.11 printer (CVE-2007-1218)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Executioner 2007-03-01 18:07:38 UTC]

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

[Comment 1 Marcelo Goes (RETIRED) 2007-03-02 02:33:50 UTC]

Thanks, patch in 3.9.5-r2!

[Comment 2 Steve Dibb (RETIRED) 2007-03-02 03:03:17 UTC]

amd64 stabl

[Comment 3 Jeroen Roovers (RETIRED) 2007-03-02 04:36:08 UTC]

e

Stable for HPPA.

[Comment 4 Jonathan Smith (RETIRED) 2007-03-02 05:08:17 UTC]

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?

[Comment 5 Christian Faulhammer (RETIRED) 2007-03-02 07:24:59 UTC]

CVE is a good idea, x86 stable.

[Comment 6 solar (RETIRED) 2007-03-02 15:15:07 UTC]

(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.

[Comment 7 Jason Wever (RETIRED) 2007-03-02 17:28:33 UTC]

SPARC stable

[Comment 8 solar (RETIRED) 2007-03-02 20:23:32 UTC]

======================================================
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.

[Comment 9 Jonathan Smith (RETIRED) 2007-03-02 20:31:11 UTC]

this issue has been assigned CVE-2007-1218

[Comment 10 Tobias Scherbaum (RETIRED) 2007-03-03 13:00:17 UTC]

ppc stable

[Comment 11 Jose Luis Rivero (yoswink) (RETIRED) 2007-03-05 09:26:49 UTC]

[e-mail]

[Comment 12 Jose Luis Rivero (yoswink) (RETIRED) 2007-03-05 09:49:27 UTC]

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.

[Comment 13 Markus Rothe (RETIRED) 2007-03-06 08:44:09 UTC]

net-analyzer/tcpdump-3.9.5-r2 stable on ppc64

[Comment 14 Alexander Færøy 2007-03-07 14:12:36 UTC]

Stable on MIPS.

[Comment 15 Stefan Cornelius (RETIRED) 2007-03-07 14:25:18 UTC]

it seems to be commonly accepted that this is DoS only (i.e. see comment #6), so this should be B3.

Voting no

[Comment 16 Matthias Geerdsen (RETIRED) 2007-03-07 14:29:23 UTC]

just a DoS?
-> voting no

[Comment 17 Raúl Porcel (RETIRED) 2007-03-31 18:25:24 UTC]

arm/ia64/s390/sh done