Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 415861 (CVE-2006-0138) - <net-im/amsn-0.98.9: aMSN (aka Alvaro's Messenger) allows remote attackers to cause a denial of service (CVE-2006-0138)
Summary: <net-im/amsn-0.98.9: aMSN (aka Alvaro's Messenger) allows remote attackers to...
Status: RESOLVED FIXED
Alias: CVE-2006-0138
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [noglsa]
Keywords:
Depends on: 418023
Blocks:
  Show dependency tree
 
Reported: 2012-05-14 08:43 UTC by Pacho Ramos
Modified: 2012-08-14 16:09 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2012-05-14 08:43:55 UTC
This was the reason why debian removed the package time ago:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654540

But, since an upstream developer has prevented that removal after getting angry with us, the package is now unmasked again:
https://bugs.gentoo.org/show_bug.cgi?id=411205#c2

As you can read in that reply, he doesn't think this bug is so major, the problem is that debian categorized it as "medium" and, since they look to have different opinions on this issue, I would like to let you decide if this bug needs to be fixed or not:
http://security-tracker.debian.org/tracker/CVE-2006-0138

Also, the bug was submitted to upstream as I have seen simply searching by that CVE number:
http://sourceforge.net/tracker/?func=detail&aid=2921641&group_id=54091&atid=472655

Thanks for your help

Reproducible: Always
Comment 1 Sean Amoss gentoo-dev Security 2012-05-14 12:00:23 UTC
Thanks for the report, Pacho.

@net-im, we should at least re-add the p.mask entry if upstream does not intend to fix.
Comment 2 Olivier Crete (RETIRED) gentoo-dev 2012-05-14 18:59:47 UTC
This CVE is from 2006 and it's still a candidate, so I guess it's nothing serious.
Comment 3 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2012-05-15 06:47:43 UTC
(In reply to comment #2)
> This CVE is from 2006 and it's still a candidate, so I guess it's nothing
> serious.

That means nothing. Pretty much all CVEs are in the 'candidate' status.
Comment 4 Youness Alaoui 2012-05-15 23:13:13 UTC
(In reply to comment #0)
> This was the reason why debian removed the package time ago:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654540
> 
> But, since an upstream developer has prevented that removal after getting
> angry with us, the package is now unmasked again:
> https://bugs.gentoo.org/show_bug.cgi?id=411205#c2
> 
I prevented the removal by getting angry? I thought it was because I gave logical arguments.

> As you can read in that reply, he doesn't think this bug is so major, the
> problem is that debian categorized it as "medium" and, since they look to
> have different opinions on this issue, I would like to let you decide if
> this bug needs to be fixed or not:
> http://security-tracker.debian.org/tracker/CVE-2006-0138
I'm not saying that it's "not so major", I'm saying that it's impossible for us to reproduce it. It either has been fixed a long time ago, or it never was there in the first place (most likely) *and* if it was valid, then yes, it's not major *and* it's unrealistic to have that kind of thing "fixed". When the CIA/FBI/<insert any company you can think of> can be attacked with a DoS on servers that are online 24/7, I don't see how an IM client can be "fied" to sustain a DoS on a port that gets opened for a few milliseconds when a special action is triggered (a file transfer is started)... and that is assuming the attacker knows your IP address and when you're starting a file transfer and when your NAT ports have been opened, etc...


> 
> Also, the bug was submitted to upstream as I have seen simply searching by
> that CVE number:
> http://sourceforge.net/tracker/
> ?func=detail&aid=2921641&group_id=54091&atid=472655
> 
> Thanks for your help
> 
> Reproducible: Always

I see, well thanks for the link. We never actually used the sourceforge tracker. I have now disabled it from there to avoid any further similar confusion. 

(In reply to comment #1)
> Thanks for the report, Pacho.
> 
> @net-im, we should at least re-add the p.mask entry if upstream does not
> intend to fix.

upstream intends to fix if the bug is proven to be reproducible.
Last time we checked (when debian removed amsn), we were not able to reproduce it and after code review of the relevant modules, it was judged that the bug cannot happen since the port is never open unless a file transfer is started and it gets closed right after the user connects and authenticates properly.
The listening port is closed, but the p2p port is kept for the data transfer, so we stop listening on that port as soon as possible. As soon as the user authenticates, we close the listening socket, and if a peer doesn't send the right authentication command with the right auth key, we close his socket right away to save resources. As far as I know, this has always been our implementation of the file transfer protocol, and I don't see how it can be improved (unless we keep a list of every IP address that connected to us and allow a maximum auth retries from each IP, and match the remote peer's IP address with the database before accepting any new socket, etc... but isn't that over-over-overkill ?)
Comment 5 Youness Alaoui 2012-05-25 22:22:48 UTC
After another round of testing, the bug (listening port was kept open) appeared in the latest 0.98.4 stable release, but had not been in the svn version for years. Apparently, it was never backported to the 0.98 branch.
We have released a 0.98.9 version today which fixes this CVE by closing the listen port as previously explained.
So you can consider this bug as officially fixed in an upstream version (0.98.9).
Comment 6 Sean Amoss gentoo-dev Security 2012-05-26 19:06:17 UTC
Thank you, Youness. 

@net-im, may we proceed with stabilization of =net-im/amsn-0.98.9 ?
Comment 7 Olivier Crete (RETIRED) gentoo-dev 2012-05-28 16:36:38 UTC
With net-im hat on, you may proceed with stabilisation
Comment 8 Tim Sammut (RETIRED) gentoo-dev 2012-05-28 16:46:00 UTC
Great, thank you.

Arches, please test and mark stable:
=net-im/amsn-0.98.9
Target keywords : "amd64 hppa ppc x86"
Comment 9 Johannes Huber gentoo-dev 2012-05-28 18:45:35 UTC
x86 stable
Comment 10 Elijah "Armageddon" El Lazkani (amd64 AT) 2012-05-28 19:13:49 UTC
amd64: pass
Comment 11 Jeroen Roovers gentoo-dev 2012-05-28 23:13:47 UTC
Stable for HPPA.
Comment 12 Agostino Sarubbo gentoo-dev 2012-05-29 12:12:22 UTC
amd64 stable
Comment 13 Michael Weber (RETIRED) gentoo-dev 2012-07-08 22:04:38 UTC
ppc stable
Comment 14 Agostino Sarubbo gentoo-dev 2012-07-08 22:10:17 UTC
@security: please vote
Comment 15 Tim Sammut (RETIRED) gentoo-dev 2012-08-14 05:43:24 UTC
Thanks, folks. GLSA Vote: no.
Comment 16 Stefan Behte (RETIRED) gentoo-dev Security 2012-08-14 16:09:34 UTC
Vote: NO, closing noglsa.