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
Thanks for the report, Pacho. @net-im, we should at least re-add the p.mask entry if upstream does not intend to fix.
This CVE is from 2006 and it's still a candidate, so I guess it's nothing serious.
(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.
(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 ?)
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).
Thank you, Youness. @net-im, may we proceed with stabilization of =net-im/amsn-0.98.9 ?
With net-im hat on, you may proceed with stabilisation
Great, thank you. Arches, please test and mark stable: =net-im/amsn-0.98.9 Target keywords : "amd64 hppa ppc x86"
x86 stable
amd64: pass
Stable for HPPA.
amd64 stable
ppc stable
@security: please vote
Thanks, folks. GLSA Vote: no.
Vote: NO, closing noglsa.
