From the Debian security announcements: Package : mpg123 Vulnerability : heap overflow Problem-Type : remote CVE Ids : CAN-2003-0865 A vulnerability was discovered in mpg123, a command-line mp3 player, whereby a response from a remote HTTP server could overflow a buffer allocated on the heap, potentially permitting execution of arbitrary code with the privileges of the user invoking mpg123. In order for this vulnerability to be exploited, mpg321 would need to request an mp3 stream from a malicious remote server via HTTP. At least 59r is affected, I don't know whether 59s (in portage) is.
It seems that the last version (pre-0.59s) is affected too. This is a quick fix, that i found on internet, for this version: --- httpget.c 2000-10-30 18:45:12.000000000 +0100 +++ httpget.c.patch 2004-02-09 10:05:56.000000000 +0100 @@ -55,7 +55,7 @@ void readstring (char *string, int maxle #endif int pos = 0; - while(1) { + while(maxlen>pos) { if( read(fileno(f),string+pos,1) == 1) { pos++; if(string[pos-1] == '\n') {
I swear I've package masked this before !~@#$%^ Ok looks like somebody went a fscked things up good. 59r is still marked as stable with an already applied fix for 59s. This patch would be the second security patch needed for mpg123. So I'm outright opting to package.mask it all together until such a time as a mpg123 maintainer chooses to notice this bug. I'll add everybody thats ever commited on mpg123 to this bug. mpg123-0.59r-r2.ebuild:KEYWORDS="x86 ppc sparc alpha hppa amd64" mpg123-0.59r-r3.ebuild:KEYWORDS="x86 ppc sparc alpha hppa amd64" mpg123-0.59s-r1.ebuild:KEYWORDS="~x86 ia64 ~amd64 ~ppc ~sparc alpha ~hppa ~mips ~arm" mpg123-0.59s.ebuild:KEYWORDS="~x86 ~sparc" 59s should add this patch and then be bumped to stable for all arches with the old versions being removed. I'd also like to request that one of you please become the full time maintainer and add a metadata.xml
masked in portage now. # <solar@gentoo.org> (15 Feb 2004) # heap overflow bug #40631 <=media-sound/mpg123-0.59s-r1 /home/cvsroot/gentoo-x86/profiles/package.mask,v <-- package.mask new revision: 1.2700; previous revision: 1.269
Stable on sparc.
Well, jolly good that it's masked. However... !!! all ebuilds that could satisfy "media-sound/mpg123" have been masked. !!! possible candidates are: - media-sound/mpg123-0.59s (masked by: package.mask) - media-sound/mpg123-0.59r-r2 (masked by: package.mask) - media-sound/mpg123-0.59r-r3 (masked by: package.mask) - media-sound/mpg123-0.59s-r1 (masked by: package.mask) !!! (dependency required by "kde-base/kdemultimedia-3.2.0" [ebuild]) mpg123 is in the DEPEND list of kdemultimedia-3.2.0. Masking does not strike me as a good idea. phil
Solar, masking this was a bad idea. Please get off your high horse. Security is important, but right now you've broken kde at least, and probably a number of other things that rely on mpg123. I've put sound@gentoo.org in the cc list since this ebuild clearly belongs to that group. I've removed the others from the list since they aren't really appropriate. I've marked 0.59s-r1 stable on x86 and removed a couple of the older ebuilds to make things clearer. At this point the following arches need to mark this ebuild stable to get the security fix finished up: amd64 ppc hppa mips. I've removed arm from the list of arches since they don't have bugzilla account.
Sorry but your just going to have to cope with it for now. It's a problem and it needs to be resolved. The package needs a maintainer! Package masking was chosen because it's makes other developers aware that a problem exists and it usually does not take long to have things addressed when you get those types of breakage. So I firmly stand by my choice to package.mask
solar: breaking the tree and ruining QA is not acceptable. Please don't do it again. As far as I can tell, mpg123 is maintained by the sound team - so what's the problem? Anyway, I've marked it stable on AMD64. I've also unmasked it; massive dependency breakage across the tree is worse than a relatively minor security hole.
fixing bug 14940 could handle it (if mpg321 really provides the same as mpg123, I'm not sure about this)
I marked it stable on ppc
Solar, since your comment #7 was addressed to me, I'm going to respond. You do not have the right to break dependencies to "make developers aware". It's absolutely the wrong thing to do. You can send email to people, you can complain on IRC, you can fix the package yourself... but you cannot break dependencies and make everybody's attempts to install Gentoo fail. In this case, is it YOU who are going to have to cope with slow/non-existent maintainers. You can't break things to make a point, that's a quick way to the exit ramp.
Removing amd64 an ppc from the cc list to show which arches are still affected: hppa and mips.
It seems you all have completely missed the point. The sound team (eradicator@g.o) has agreed to adopt mpg123 via the sound team. A metadata.xml has been added and he requested I do the bump for this package and I have done so (now mpg123-59s-r2) I've only confirmed it builds ok. It should be noted that this package has ACCEPT_KEYWORDS="~x86" at this time. It's up to the rest of you to test it and call it stable for your arches. Jon your not on the security team and you should never undo a change we have made. Quite simply it's not your place to undo. We have our policies in place and they behave this way for a reason. If you would like to change policy then you know what to do, join the herd and become active in proposing new policy. Why your all bumping the exploitable version to stable is beyond my comprehension. None the less a fixed version is now in portage. Have fun.
I am engaged in distribution-wide policy decisions. Security team policy is irrelevant -- anything breaking huge chunks of the tree is unacceptable. That kind of unacceptable behavior is a devrel issue. Part of what I do is clean up other people's messes, especially when they ruin Gentoo's QA (and reputation). This is moving to -core. Consider this note simply for posterity's sake.
Then Gentoo's QA (and reputation) needs to be addressed. Because if you think that allowing a known vulnerability to slip by is ok then QA is clearly doing a poor job.
A note from the user camp, simply because I do not currently participate in -core: Masking a package that is already installed on countless systems already (a consequence of being an important dependency) does not solve the problem. These system still have the package installed. You will notice that this masking created alot of noise because the people who were performing an update of this package, people who ALREADY HAD THE FLAW ON THEIR SYSTEM, were unable to update. I would agree with solar's decision were this not the case, but it was. This decision served to break the portage tree with the intent of "protecting" the select few users who did not have this package installed on their system already, at the expense of breaking it for all of the Gentoo KDE users who tried to update their system today. This behavior needs to be looked at. If you really want to protect the users who would have been installing KDE on their system for the first time today, you need to make it known that a capacity is needed for disabling new package installs only, as opposed to breaking it for the majority of people *with no percievable benefit to them*. This, I feel, is why many people felt that this decision was unacceptable. There are merits to both side of the argument. Please seek a compromise.
we are working on seeking a compromise and we do recognize that this situation was not handled as well as it could have been.
Ok, I'm a bit concerned because I haven't seen a GLSA for this yet... Who is supposed to send out the GLSA? I was under the impression it was security, but if it's sound, could someone please point me in the right direction as I have not done a GLSA before.
Patch in portage for more than a month : unfortunately we missed issuing a GLSA back then, now publishing one would be of little value. We are taking steps in order to avoid such problems in the future. Closing without GLSA.
I hope all vulnerable versions are removed from portage? I discovered this multiple times now, GLSAs are often lacking completely. Please try to keep up with them. Like you state "Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us" below every GLSA, you should really stick to this.
we are in the process of a) documenting and streamlining our workflow and b) seeking additional volunteers to help ensure these things don't slip through the cracks in the future. However, as I've stated multiple times on the gentoo-security mailing list, unlesss we get enough qualified, dedicated folks willing to help with bug wrangling and GLSA writing, these things *will* continue to slip through the cracks as we don't have the staff to handle it all. You can help us most by dedicating some time to filing bugs, wrangling bugs or drafting GLSAs. You're welcome to join us in #gentoo-security on irc.freenode.net to help be part of the solution.
