Bugzilla Bug 143402

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.