0.10.13 will be out October 17th with the following fixorz : The ISAKMP dissector could exhaust system memory. The FC-FCS dissector could exhaust system memory. The RSVP dissector could exhaust system memory. The ISIS LSP dissector could exhaust system memory. The IrDA dissector could crash. The SLIMP3 dissector could overflow a buffer. The BER dissector was susceptible to an infinite loop. The SCSI dissector could dereference a null pointer and crash. If the "Dissect unknown RPC program numbers" option was enabled, the ONC RPC dissector might be able to exhaust system memory. The sFlow dissector could dereference a null pointer and crash. The RTnet dissector could dereference a null pointer and crash. The SigComp UDVM could go into an infinite loop or crash. If SMB transaction payload reassembly is enabled the SMB dissector could crash. The X11 dissector could attempt to divide by zero. The AgentX dissector could overflow a buffer. The WSP dissector could free an invalid pointer. iDEFENSE found a buffer overflow in the SRVLOC dissector. Get ready.
GLSA drafted.
CAN assignment : CAN-2005-3184 SRVLOC "buffer overflow (iDEFENSE)" from 0.10.0 to 0.10.12 CAN-2005-3241 ISAKMP "exhaust system memory" from 0.10.11 to 0.10.12 FC-FCS "exhaust system memory" from 0.9.0 to 0.10.12 RSVP "exhaust system memory" from 0.9.4 to 0.10.12 ISIS LSP "exhaust system memory" from 0.8.18 to 0.10.12 CAN-2005-3242 IrDA crash from 0.10.0 to 0.10.12 SMB crash from 0.9.7 to 0.10.12 CAN-2005-3243 SLIMP3 "buffer overflow" from 0.9.1 to 0.10.12 AgentX "buffer overflow" from 0.10.10 to 0.10.12 CAN-2005-3244 BER "infinite loop" from 0.10.3 to 0.10.12 CAN-2005-3245 ONC RPC "exhaust system memory" from 0.7.7 to 0.10.12 CAN-2005-3246 SCSI "null dereference" from 0.10.3 to 0.10.12 sFlow "null dereference" from 0.9.14 to 0.10.12 RTnet "null dereference" from 0.10.8 to 0.10.12 CAN-2005-3247 SigComp UDVM "infinite loop or crash" 0.10.12 CAN-2005-3248 X11 "divide by zero" from 0.10.1 to 0.10.12 CAN-2005-3249 WSP "free an invalid pointer" from 0.10.1 to 0.10.12
Still nothing upstream. ETA unknown.
Still no announcements but tarball available. Setting to SEMI-PUBLIC for now. Daniel please provide an updated ebuild.
added masked - had trouble reading from pcap file - 100% cpu and no action. If someone could test that would be great. feel free to unmask.
Now public.
ethereal-0.10.13 commited and ready for stabilisation. Test plan: 1. capture some network traffic (tcpdump -i eth0 -w dump.pkt) and run ethereal -r dump.pkt as non-root user. 2. run as ethereal as root and see if it can capture packets. last arch out please remove 0.10.12. Apoligies for cc you on a bug you can't see but I'm sure the ethereal web page will tell all.
Worky worky on x86.
Forgot to unCC...
Folks, I went to stablize on ppc64 and also tried with the adns USE flag. The adns package failed one of its tests with a memory leak. So it might take us a while to get this one under the wraps.
On my ~amd64 box, emerging ethereal generates the following syslog entry; lt-tethereal[31339]: segfault at 00002aaaac0c1f68 rip 00002aaaac0c1f68 rsp 00007ffffff938a8 error 15 Is that to be expected?
I tend not to expect that (memleak or syslog). Netmon friends can you do a bit more testing. I'm pretty busy at the moment.
netmon please advise.
Its working ok in x86 as far as i can test :)
Please mark stable if it doesn't work worse than the previous version. We need to GLSA this one soon because of the potential impact of the vulnerability. ppc64: maybe mask the adns USE flag to get out of the deadlock.
Marking ppc64 stable. Also discussed the test failure of adns with dostrow and we agreed to stablize anyways.
alpha seems to have the same problems that ppc64 with memory leaks. It could be a 64bits related problem since in x86 is working fine and amd64 also presents some issues (maybe sparc folks can check this). To check it out just make: emerge adns with FEATURES="test". I *really* against mark ethereal stable with this bug so, is the way to go to mask the global use flag "adns"? If so, i will do it in a few hours.
adns works on ppc(32), marked stable.
yoswink: of course if there is a regression in 0.10.13 you shouldn't mark it stable. But if it's just a bug that is already there in 0.10.12 (in adns support or anywhere else), then you should mark it stable. The idea here is not to mark stable beacuse it's perfect, but to mark stable because it's the same as the current stable + security fixes. So please check 0.10.12 status on the problem you detected to determine if it's a regression in 0.10.13 or not.
If adns causes problems then ethereal-0.10.13 should be marked stable and adns use.mask'ed. That way you keep everyone happy :) Cheers, Ferdy
sparc stable, adns seems safe for us.
After more serious tests on ethereal (with adns support), more tests on adns and check how many time adns has been stable on alpha (29 Mar 2004) without any bug (on any arch) i decided ... Marked 0.10.13 as Stable on alpha and *not* mask the USE "adns". If sometime in future, errors appear on it, please punish me until I die ;)
Running this ethereal on amd64 on a small dump file (72k) dump file generated by tcpdump causes it to go into a hard loop consuming all available CPU. I cannot mark it stable under these circumstances, as it does not work at all with a dump file. Note that it works fine capturing it's own dump.
Daniel: can you confirm the same test works correctly on 0.10.12 ? Any chance you can attach your dump file so that we can test and narrow it down to amd64 ? We need to push this upstream asap if we want to have a security fix soon.
It works fine on 0.10.12. There's a dump that fails at http://dev.gentoo.org/~dang/dump.pkt
I can reproduce the problem on x86 with this capture file, so it's not amd64-specific. I pushed the issue upstream, hopefully we'll get a fix. Calling stable arches back as they might want to test with the file and downgrade to ~ or mask 0.10.13 if they are affected.
Gerald Combs answered, it's an IRC loop that was introduced in the 0.10.13 release. This patch should solve it : http://anonsvn.ethereal.com/viewcvs/viewcvs.py/trunk/epan/dissectors/packet-irc.c?r1=15985&r2=16290&rev=16290&makepatch=1&diff_format=u netmon, please revbump with patch.
Use CVE-2005-3313 for the DoS issue reported on this bug.
Archs, 0.10.13-r1 is in cvs with the patch in comment 27 applied. Please test/re-keyword.
marked ppc64 stable
sparc does it again!
Alpha is ready. Thanks to Daniel for reporting it.
amd64 stable
x86 done
Waiting on ppc to mark 0.10.13-r1 stable to release GLSA. ia64 should stable too.
Stable on ppc. Sorry for the delay.
Security please review the updated draft (approvals was downgraded).
GLSA 200510-25
