CVE-2008-4829 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4829): Multiple buffer overflows in lib/http.c in Streamripper 1.63.5 allow remote attackers to execute arbitrary code via (1) a long "Zwitterion v" HTTP header, related to the http_parse_sc_header function; (2) a crafted pls playlist with a long entry, related to the http_get_pls function; or (3) a crafted m3u playlist with a long File entry, related to the http_get_m3u function.
*** Bug 245959 has been marked as a duplicate of this bug. ***
B1 because it is a client, and you need to entice a user to visit the malicious URL.
We can either bump: New for 1.64.0 ------------------------------------ Wed Nov 19 09:00:06 EST 2008 * Security patch for CVE-2008-4829, multiple buffer overflows in http.c that could result in remote exploit. ... or patch: http://streamripper.cvs.sourceforge.net/viewvc/streamripper/sripper_1x/lib/http.c?view=patch&r1=1.50&r2=1.51&pathrev=sripper-1_64_0
1.64.0 is now in Portage. Test and stable.
Arches, please test and mark stable: =media-sound/streamripper-1.64.0 Target keywords : "alpha amd64 hppa ppc ppc64 sparc x86"
For hppa this means stabilizing cdk without ~arch testing, DEPEND.bad, RDEPEND.bad, media-sound/streamripper/streamripper-1.64.0.ebuild: ~hppa(default/linux/hppa/2008.0) ['dev-libs/cdk'] or mass unkeywording of media applications.
We can add a grace period for cdk ~hppa testing and stable it in a week.
Stable for HPPA.
May I ask why streamripper-1.64.0 ebuild depends on cdk ? I removed the cdk dep ( cdk not installed on my system ) and it built just fine. Output was Using included CDK library? no Which means neither did it use the internal one nor is there a system one. ./configure --help says --with-included-cdk use the cdk library included with streamripper No option is there for using system cdk. I conclude that a) cdk is optional and unternal only - maybe needs a cdk useflag b) it seems that streamripper will not build against a system cdk at all ( unsure about this - please check with ldd ) Sorry if it was wrong to post here instead of doing a new bug right away.
Next arch touching this. - Remove dev-libs/cdk from RDEPEND. - Remove unused "inherit eutils" Thank you.
(In reply to comment #10) > Next arch touching this. > > - Remove dev-libs/cdk from RDEPEND. > - Remove unused "inherit eutils" > > Thank you. > done, as amd64/x86.
For The Record, cdk was used for cstreamripper which is supposed to be some sort of ncurses frontend to streamripper itself. I remember looking at this issue like an year ago, and seeing some upstream message it was temp. disabled for a reason. Anyway, I will investigate this issue more closely later (again). Luckily, streamripper has other frontends available in Portage.
ppc stable
alpha/sparc stable
ppc64: *PING*
ppc64 done
GLSA request filed.
GLSA 200901-05
