Bug 50449 (CVE-2004-0367) - VUL-0: CVE-2004-0367: ethereal: 10 buffer overflows
Summary: VUL-0: CVE-2004-0367: ethereal: 10 buffer overflows
Status: RESOLVED FIXED
: 52627 (view as bug list)
Alias: CVE-2004-0367
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: All Linux
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Thomas Biege
QA Contact: Security Team bot
URL:
Whiteboard: CVE-2004-0367: CVSS v2 Base Score: 5....
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-08 19:29 UTC by Thomas Biege
Modified: 2021-09-30 15:21 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
full vendor-sec discussion (12.68 KB, text/plain)
2004-03-08 19:33 UTC, Thomas Biege
Details
patchinfo-box.ethereal (549 bytes, text/plain)
2004-03-08 19:58 UTC, Thomas Biege
Details
patchinfo.ethereal (492 bytes, text/plain)
2004-03-08 19:59 UTC, Thomas Biege
Details
ongoing vendor-sec discussion (14.01 KB, text/plain)
2004-03-23 16:10 UTC, Thomas Biege
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Biege 2004-03-08 19:29:00 UTC
Hi, 
Stefan Esser pre-notified us about 10 buffer overfows in ethereal. 
" 
Date: Sat, 6 Mar 2004 09:45:16 +0100 
From: Stefan Esser <s.esser@e-matters.de> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] 10 x Ethereal Overflows 
 
Hi, 
 
I just wanted to pre-notify you. Yesterday I submitted the 
following 10 bugs (only shortname) to the ethereal devs 
and meanwhile 7/10 bugs are fixed in their CVS. The other 
3 need further investigation in the protocol specs for 
the correct way of fixing. 
 
[01] Netflow Protocol Dissector Overflow 
[02] IGAP Protocol Dissector Account Overflow 
[03] IGAP Protocol Dissector Message Overflow 
[04] EIGRP Protocol TLV_IP_INT Long IP Address Overflow 
[05] EIGRP Protocol TLV_IP_EXT Long IP Address Overflow 
[06] PGM Protocol NakList Overflow 
[07] IRDA Protocol Plugin IRCOM_PORT_NAME Overflow 
[08] BGP Protocol MPLS Label Overflow 
[09] ISUP Protocol INTERWORKING FUNCTION ADDRESS Overflow 
[10] TCAP Protocol TID Overflow 
 
All of these bugs are stackoverflows that are nearly all caused 
by missing boundary checks and in one case by an integer 
underflow. With exception of [06][07][08] they allow code execution. 
In [06] and [08] the overflow is quite small and therefore it seems 
not exploitable (in the sense of code execution) on atleast the x86) 
[07] was not further tested and is an off-by-two on the stack. 
")\0" are written. 
 
Due to the fact that not all bugs are fixed yet I cannot tell 
you when we are about to release. If you want details you can 
either contact me directly or look into the Ethereal CVS. 
 
Greetings, 
Stefan Esser 
"
Comment 1 Thomas Biege 2004-03-08 19:29:00 UTC
<!-- SBZ_reproduce  -->
-
Comment 2 Thomas Biege 2004-03-08 19:33:38 UTC
Created attachment 16420 [details]
full vendor-sec discussion
Comment 3 Thomas Biege 2004-03-08 19:58:41 UTC
Created attachment 16421 [details]
patchinfo-box.ethereal
Comment 4 Thomas Biege 2004-03-08 19:59:17 UTC
Created attachment 16422 [details]
patchinfo.ethereal
Comment 5 Petr Ostadal 2004-03-08 22:42:57 UTC
I need patches for all vulnerable distros. Becouse the last rule of my leader of
packagers team vinil@suse.cz is that my position (packager) can't make security
patches ;(... Making security patches is work of security team as he said.
Comment 6 Thomas Biege 2004-03-09 20:50:46 UTC
Some additional information: 
Date: Tue, 9 Mar 2004 12:57:35 +0100 
From: Stefan Esser <s.esser@e-matters.de> 
To: Matt Zimmerman <mdz@debian.org> 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] 10 x Ethereal Overflows 
 
Hi Matt, 
 
I have a list of the bugs with their date of introduction: 
(Bug 15011 which was found after my last mail is not yet verified 
by myself ;) With verified I mean I havent created a packet 
yet that overflows the buffer. I will do this right after sending 
this email. And Bug 15011 allows overwrites only with a limited set 
of chars, so if possible remote code execution exploits would be 
very hard) 
 
here comes the list of overflows... 
 
 
(version 0.7.0) 
 
[11] Radius (BIN)STRING Overflow 
HEAP - Revision: 1.1, Thu Jul 8 04:23:04 1999 UTC (4 years, 8 months ago) 
STACK- Revision: 1.84, Wed Dec 17 01:57:23 2003 UTC (2 months, 3 weeks ago) 
(version 0.10.1) 
 
 
 
(Version 0.8.14) 
 
 
[04] EIGRP Protocol TLV_IP_INT Long IP Address Overflow 
     - Revision: 1.7, Thu Nov 9 05:16:19 2000 UTC (3 years, 3 months ago) 
 
[05] EIGRP Protocol TLV_IP_EXT Long IP Address Overflow 
     - Revision: 1.7, Thu Nov 9 05:16:19 2000 UTC (3 years, 3 months ago) 
 
 
 
(version 0.8.19) 
[06] PGM Protocol NakList Overflow 
     - Revision: 1.1, Thu Jul 12 20:16:28 2001 UTC (2 years, 7 months ago) 
 
 
 
(version 0.9.10) 
 
[01] Netflow Protocol Dissector Overflow 
     - since Revision 1.9 Tue Mar 4 03:37:12 2003 UTC (12 months ago) 
 
 
 
(versin 0.9.16) 
 
[09] ISUP Protocol INTERWORKING FUNCTION ADDRESS Overflow 
     - Revision: 1.29, Fri Oct 3 20:58:13 2003 UTC (5 months ago) 
 
[10] TCAP Protocol TID Overflow 
     - Revision: 1.1, Thu Oct 2 06:13:28 2003 UTC (5 months, 1 week ago) 
 
 
 
(version 0.10.0) 
 
[02] IGAP Protocol Dissector Account Overflow 
     - since Revision 1.1 Wed Dec 10 19:21:55 2003 UTC (2 months, 4 weeks ago) 
 
[03] IGAP Protocol Dissector Message Overflow 
     - since Revision 1.1 Wed Dec 10 19:21:55 2003 UTC (2 months, 4 weeks ago) 
 
 
(version 0.10.1) 
 
[08] BGP Protocol MPLS Label Overflow 
     - Revision: 1.84, Tue Jan 6 02:29:36 2004 UTC (2 months ago) 
 
[07] IRDA Protocol Plugin IRCOM_PORT_NAME Overflow 
     - Revision: 1.1, Thu Dec 18 19:07:12 2003 UTC (2 months, 2 weeks ago) 
 
 
 
 
 
-- 
 
-------------------------------------------------------------------------- 
 Stefan Esser                                        s.esser@e-matters.de 
 e-matters Security                         http://security.e-matters.de/ 
 
 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
 Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69 
-------------------------------------------------------------------------- 
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/ 
-------------------------------------------------------------------------- 
 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
Comment 7 Thomas Biege 2004-03-09 21:06:12 UTC
Date: Tue, 9 Mar 2004 13:19:34 +0100 
From: Stefan Esser <s.esser@e-matters.de> 
To: Matt Zimmerman <mdz@debian.org> 
Cc: vendor-sec@lst.de 
Subject: Re: [vendor-sec] 10 x Ethereal Overflows 
 
Oops... Better forget about bug 15011. I oversaw that the lengths 
are only of byte size. The static buffer cannot be overflown... 
After so many bugs one starts to see ghosts. 
 
Stefan 
 
-- 
 
-------------------------------------------------------------------------- 
 Stefan Esser                                        s.esser@e-matters.de 
 e-matters Security                         http://security.e-matters.de/ 
 
 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
 Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69 
-------------------------------------------------------------------------- 
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/ 
-------------------------------------------------------------------------- 
 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
Comment 8 Roman Drahtmueller 2004-03-10 16:37:32 UTC
Stefan Probst and Vinil are discussing the future method used. This will take
some time, but the work on the bugs for ethereal and openssh/scp should not wait
while this discussion takes place. Therefore, we will provide you with the 
patches for this specific problem. We are very grateful if you could handle the
package building and preliminary testing before the package can get checked in
and be handed over to the QA team for testing.

To be honest: We doubt that the packagers in Prague are not well enough educated
to handle security patches. The experience has shown that you are. We'll always 
be glad to answer questions of all kinds if this helps, since that's what we are
here for.

Is that OK for you/does that match vinil's ruling?

I am increasing this bug to "major".

Thanks,
Roman.
Comment 9 Thomas Biege 2004-03-12 17:31:07 UTC
I have no time to handle this issue. I am bound to managing all the current 
incidents ( > 30 ) and to EAL4. 
Comment 10 Thomas Biege 2004-03-18 22:34:11 UTC
Date: Thu, 18 Mar 2004 15:26:56 +0100 
From: Stefan Esser <s.esser@e-matters.de> 
To: Mark J Cox <mjc@redhat.com> 
Cc: vendor-sec@lst.de 
Subject: Re: CAN-2004-0176 Re: [vendor-sec] 10 x Ethereal Overflows 
 
Hi Mark, 
 
> Hello Stefan; do you have an update on when the new release and your 
> advisory is planned? 
 
I have just a little update. From the bugs I told you sofar 1 last one 
is awaiting a patch. The ethereal guys want to find the tcap specification 
first to see if the transaction id is always 4 byte ... They want a clean 
fix. And obviously they are very slow in searching for specs.... 
 
However yesterday evening I sent them 3 more bugs in the ucp dissector. 
I have no reply to this mail yet. 
 
The bugs in question are 3 bufferoverflows in packet-ucp.c 
 
ucp_handle_string/ucp_handle_int/ucp_handle_time 
 
All 3 functions may overflow their internal buffer on systems where the 
MTU is bigger than BUFSIZ. I do not believe that there are systems with 
MTUs > 8192 (correct me if I am wrong) and so glibc systems are kinda 
safe. However Windows has a BUFSIZ of 512 and BSD iirc of 1024. On those 
systems an overflow is possible. Due to the lack of a BSD system atm i have 
only tested my evil packets against ethereal on windows. 
 
When I get a reply concerning the UCP dissector I will ask the guys again 
when they are ready... If I find the time I will search the TCAP specification 
for them ;) 
 
Stefan 
 
Comment 11 Thomas Biege 2004-03-23 16:10:46 UTC
Created attachment 17022 [details]
ongoing vendor-sec discussion
Comment 12 Thomas Biege 2004-03-23 16:15:15 UTC
Petr, 
regarding the high amount of bugs and the missing ressources to create a patch 
can we do a version upgrade (to 0.10.3)? Can you discuss this with the 
projectmanagers please. 
 
Will version 0.10.3 go into 9.1? 
Comment 13 Petr Ostadal 2004-03-23 17:03:16 UTC
I agree with Thomas, the version upgrade will be better in this case because
fixing these bugs would take a lot of time. The new version comming in few days.
Can I make these versin upgrade in SL9.1 too?

Ralf and Andreas, could you make a decision please.  
Comment 14 Roman Drahtmueller 2004-03-23 17:06:29 UTC
Side note: The package is leaf as leaf can be.
Comment 15 Andreas Jaeger 2004-03-23 17:20:06 UTC
Version update for 9.1 is approved.
Comment 16 Thorsten Kukuk 2004-03-23 17:23:43 UTC
Roman, sorry, but this package is in no way a leaf package. 
 
When can we expect the new version? 
Comment 17 Roman Drahtmueller 2004-03-23 17:59:37 UTC
More insight appreciated, for educational reasons: ethereal doesn't show up 
in a single spec file in STABLE, and it doesn't contain any libraries. 
No package requires ethereal.

Danke!
Roman.
Comment 18 Thorsten Kukuk 2004-03-23 18:28:26 UTC
If no other package depend on it for building this does not 
mean that this is a core package for a product. 
Comment 19 Thorsten Kukuk 2004-03-23 18:43:27 UTC
Should be ".. not a core package for a product.", of course. 
 
So, when can we expect the new ethereal version? 
Comment 20 Thomas Biege 2004-03-24 16:49:22 UTC
---------- Forwarded message ---------- 
Date: Mon, 22 Mar 2004 16:25:07 -0500 (EST) 
From: Steven M. Christey <coley@mitre.org> 
To: mjc@redhat.com, mdz@debian.org 
Cc: coley@mitre.org 
Subject: Ethereal 0.10.2 bugs (CAN-2004-0176, CAN-2004-0365, CAN-2004-0367) 
 
 
Based on feedback from Matt Zimmerman and the new Ethereal advisory, 
here are 3 CANs for Ethereal bugs: 
 
CAN-2004-0176 - 13 overflows in various dissectors 
CAN-2004-0365 - RADIUS null dereference in dissect_attribute_value_pairs() 
CAN-2004-0367 - zero-length Presentation protocol selector 
 
There's a mention of a 4th issue where "A corrupt color filter file 
could cause a segmentation fault," but that sounds like a self-exploit 
only, so maybe it shouldn't get a CAN. 
 
- Steve 
 
 
====================================================== 
Candidate: CAN-2004-0176 
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0176 
inal-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20040225 
Category: SF 
Reference: CONFIRM:http://www.ethereal.com/appnotes/enpa-sa-00013.html 
 
Multiple buffer overflows in Ethereal 0.8.13 to 0.10.2 allow remote 
attackers to cause a denial of service and possibly execute arbitrary 
code via the (1) NetFlow, (2) IGAP, (3) EIGRP, (4) PGM, (5) IrDA, (6) 
BGP, (7) ISUP, or (8) TCAP dissectors. 
 
 
 
====================================================== 
Candidate: CAN-2004-0365 
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0365 
Final-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20040322 
Category: SF 
Reference: MLIST:20040318 [ethereal-dev] ethereal radius dissector 
vulnerability 
Reference: URL:http://
marc.theaimsgroup.com/?l=ethereal-dev&m=107962966700423&w=2 
Reference: CONFIRM:http://www.ethereal.com/appnotes/enpa-sa-00013.html 
 
The dissect_attribute_value_pairs function in packet-radius.c for 
Ethereal 0.8.13 to 0.10.2 allows remote attackers to cause a denial of 
service (crash) via a malformed packet that triggers a null 
dereference. 
 
 
 
====================================================== 
Candidate: CAN-2004-0367 
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0367 
inal-Decision: 
Interim-Decision: 
Modified: 
Proposed: 
Assigned: 20040322 
Category: SF 
Reference: CONFIRM:http://www.ethereal.com/appnotes/enpa-sa-00013.html 
 
Ethereal 0.8.13 to 0.10.2 allow remote attackers to cause a denial of 
service (crash) via a zero-length Presentation protocol selector. 
 
 
_______________________________________________ 
 
Comment 21 Petr Ostadal 2004-03-26 19:40:19 UTC
Ok I will upgrade it in SL9.1.

And what decision will be for older SL box and SLES?
Comment 23 Petr Ostadal 2004-03-31 19:21:31 UTC
*** Bug 52627 has been marked as a duplicate of this bug. ***
Comment 24 Ralf Flaxa 2004-03-31 19:37:04 UTC
If all the patches and functionality we had previously are also available 
in the latest upstream version then I approve the version update 
for SLES 8 and SLES 9. 
 
Comment 25 Andreas Jaeger 2004-04-04 02:38:09 UTC
Fixed for 9.1, so changing version.

Approved for older versions.
Comment 26 Thomas Biege 2004-04-05 23:25:12 UTC
Petr, 
when you are done submitting the new packages, reassign to me instead of 
closing this bug. Thanks a lot. 
Comment 27 Petr Ostadal 2004-04-07 02:00:19 UTC
All distros were fixed and submited. Thomas, submit patchinfo files by yourself,
please (I am going on sick leave, and I will return on Tuesday).
Comment 28 Thomas Biege 2004-04-07 16:01:31 UTC
thomas@bragg:/work/src/done> for i in $(find . \( -name ethereal -a -type d \) 
2>/dev/null);do echo $i; (cd $i;distmail);done 
./8.0/ethereal 
./8.1/ethereal 
./8.2/ethereal 
./9.0/ethereal 
./SLES7/ethereal 
./SLES7-PPC/ethereal 
 
done! 
Comment 29 Thomas Biege 2004-04-23 17:36:05 UTC
packages approved 
Comment 30 Thomas Biege 2009-10-13 20:17:05 UTC
CVE-2004-0367: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)