Mi0r4sora

This vulnerability can be exploited by an attacker through an infected mp3 and has the potential to implement different scenarios in the mp3 structure through the clubhouse android app like rce

the vulnerable lib –> libmpg123 https://github.com/gypified/libmpg123/

the attacker send the mp3 –> client play –> attacker got rce

https://de.wikipedia.org/wiki/MP3
https://id3.org/id3v2.4.0-structure

structure of mono and stereo conditions

                  mpeg 1                   mpeg 2/2.5
stereo   32                              17
 mono    17                               9

lame_offset = (fr->stereo == 2) ? (fr->lsf ? 17 : 32 ) : (fr->lsf ? 9 : 17);

The stereo and lsf values ​​in this code can be controlled through mp3 and also the flags are read from the file according to this structure.

// input frames
    off_t track_frames;
    off_t track_samples;
    double mean_framesize;
    off_t mean_frames;
    int fsizeold;
    int ssize;
    unsigned int bitreservoir;
    unsigned char bsspace[2][MAXFRAMESIZE+512]; /* MAXFRAMESIZE */
    unsigned char *bsbuf;
    unsigned char *bsbufold;
    int bsnum;

to handle by these function code the xing header must be 120 byte

if(fr->framesize >= 120+lame_offset)

After that here as you can see fr->bsbuf[i] all of them can be controlled by the attacker without any restrictions and they will check and search it. attacker can control the bsbuf and can control it to where it point on frame so the array controllable by attacker

idk why its marked as informative? :/

for(i=2; i < lame_offset; ++i) if(fr->bsbuf[i] != 0) break;

            (
                       (fr->bsbuf[lame_offset] == 'I')
                && (fr->bsbuf[lame_offset+1] == 'n')
                && (fr->bsbuf[lame_offset+2] == 'f')
                && (fr->bsbuf[lame_offset+3] == 'o')
            )