Copied from Full Disclosure: Thanks to Luigi Auriemma. ====== 2) Bug ====== --------------------------------------------- A] buffer-overflow in reconnect's redirection --------------------------------------------- The function which handles the HTTP connections is vulnerable to a buffer-overflow that happens when it uses sscanf for copying the URL in the Location's field received from the server into the redirect buffer of only 1024 bytes declared in http_open. >From reader/http/http.c: static int reconnect (http_desc_t *desc, char *redirect) { char request [2048]; char response [10240]; ... } else if (rc == 302) { s = strstr(response, "302"); if (s) { //alsaplayer_error("%s", s); s = strstr(response, "Location: "); if (s && redirect) { /* Parse redirect */ if (sscanf(s, "Location: %[^\r]", redirect)) { /* alsaplayer_error("Redirection: %s", redirect); */ } } return 1; } ... ---------------------------------- B] buffer-overflow in GTK playlist ---------------------------------- A buffer-overflow exists in the functions which add items to the playlist when the GTK interface is used (so the other interfaces are not affected by this problem): new_list_item and CbUpdated in interface/gtk/PlaylistWindow.cpp. The best way for exploiting this bug is through the following URLs (perfect, for example, if AlsaPlayer is the default player of the web browser): http://aaaaa(more_than_1024_chars)aaaaa or http://127.0.0.1/aaaaa(more_than_1024_chars)aaaaa.mp3 --------------------------------- C] buffer-overflow in cddb_lookup --------------------------------- AlsaPlayer automatically queries the CDDB server specified in its configuration (by default freedb.freedb.org) when the user choices the CDDA function for playing audio CDs. The function which queries the server uses a buffer of 20 bytes and one of 9 for storing the category and ID strings received from the server while the buffer which contains this server's response is 32768 bytes long. Naturally for exploiting this bug the attacker must have control of the freedb server specified in the AlsaPlayer's configuration. >From input/ccda/cdda_engine.c: char * cddb_lookup (char *address, char *char_port, int discID, struct cd_trk_list *tl) { int port = atoi (char_port); int server_fd, i, j, n; int total_secs = 0, counter = 0; char *answer = NULL, *username, *filename, categ[20], newID[9]; char msg[BUFFER_SIZE], offsets[BUFFER_SIZE], tmpbuf[BUFFER_SIZE]; char hostname[MAXHOSTNAMELEN], server[80]; ... /* copy the match to the category */ j = 0; while (answer[i] != ' ') categ[j++] = answer[i++]; categ[j++] = '\0'; /* copy the new cdID */ j = 0; i++; while (answer[i] != ' ') newID[j++] = answer[i++]; newID[j++] = '\0'; } ... =========== 3) The Code =========== http://aluigi.org/poc/alsapbof.zip usage examples: A] nc -l -p 80 -v -v -n < alsapbof_a.txt B] alsaplayer http://`perl -e 'print "a"x2000'` C] nc -l -p 888 -v -v -n < alsapbof_c.txt
Sound please advise.
i would say B2 ?
I'd concur with that. Setting to B2.
Upstream appears to be dead. No CVS commits for 18 months. Secundia recommends switching products. No activity on alsaplayer-devel. Recommending removal from the tree (preferred) or hardmasking. Thanks to tcort from Sound. =) Removing sound@.
Treecleaners: Please dispose of this dead corpse, er, I mean, ebuild ;)
"Solution: Use another product." lol i suggest masking this package
masked in package.mask and pending removal on September 15th, 2006
thanks. i suppose we should issue a GLSA for this one.
Sad to hear it's in such a state. What would be necessary to prevent it's removal from the tree? I've downloaded and applied the patches that are from the debian package and are available on the alsaplayer developer mailing list at http://lists.tartarus.org/pipermail/alsaplayer-devel/2006-May/001891.html and everything appears to be OK. Are these patches sufficient for the Gentoo team to change their position about the removal of alsaplayer, or does there need to be CVS commits? I ask because I find the alsaplayer to be a good lightweight player which I like very much and would be very sadened to see it removed from the Gentoo tree.
http://www.gentoo-sunrise.org/sunrise Feel free to put it there after it's removed here. Otherwise, yes it needs a maintainer.
@sound do you still want to remove it or patch since one is now available?
GLSA 200608-24 setting to enhancement scope for removal.
Has upstream been contacted regarding this issue? I would really like to see this package stay in as it's a really nice audio library.
(In reply to comment #13) > Has upstream been contacted regarding this issue? I would really like to see > this package stay in as it's a really nice audio library. > See comment #4
I'd like to get this unmasked and patched, but i need a bit of time to update myself after the forced 1 month downtime.
Using debian's patchset 8 I still get a segmentation fault for (A). I cannot reproduce (C) right now as I have no clue how to change the freedb server. (B) is not pertinent to us (no GTK interface anymore).
I did a cursory look through of the debian bugs descriptions /affected files. Also the descriptions and affected files for this set of bugs. The debian patches do not address the current bugs. An attempt to fix these 3 bugs is on my todo list.
17:48 <@antarus> Flameeyes: ping 17:48 <@Flameeyes> pong 17:48 <@antarus> Flameeyes: alsaplayer; it staying or going? 17:48 <@Flameeyes> antarus, going 17:48 <@antarus> Flameeyes: k
Removed, Close at your leisure.
Closing.
It seems the debian patchset 9 fixes this problem: http://packages.debian.org/changelogs/pool/main/a/alsaplayer/alsaplayer_0.99.76-9/changelog Does this change this in any way?
(In reply to comment #21) > It seems the debian patchset 9 fixes this problem: > > http://packages.debian.org/changelogs/pool/main/a/alsaplayer/alsaplayer_0.99.76-9/changelog > > Does this change this in any way? > It's removed from the tree; so unless you can convince someone to bring it back; no.
I only just noticed this package disappeared from the tree when I tried to install an app that depends on it (Dancing Qt; not in portage tree yet). Looking at the upstream site, it seems they've appointed new administrators, and are looking into restarting the project. What are people's thoughts about re-adding this to the tree? I'm happy to maintain it if the sound herd are reluctant. The thing about this player, is it's the only one I know of, that supports variable speed playback... I'm involved with a Scottish country dance group here in Brisbane, who have a need for such a facility... hence my interest in the package. Anyway... thoughts people?
I'd like to see it back. Bug #166464.
(In reply to comment #23) > The thing about this player, is > it's the only one I know of, that supports variable speed playback... I'm not too bothered whether it returns or not, but I believe mplayer already supports this.
