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:
1.64.0 is now in Portage. Test and stable.
Arches, please test and mark stable:
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"
(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.
GLSA request filed.