Likes Likes:  0
Resultaten 1 tot 3 van de 3
Geen
  1. #1
    Benjamin Tober
    Re: Local/remote mpg123 exploit
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Local/remote mpg123 exploit

    In-Reply-To: <200301131823.h0DINJbE014752@mailserver3.hushmail. com>

    I'm not going to address the veracity of the narrative
    text of this posting, however the exploit is real. I
    believe that the patch to mpg123 given below closes
    this particular hole. I have no affiliation with the
    authors of mpg123 and haven't contacted them, but am
    providing this patch now because an exploit is
    publically available.
    I can, if necessary, provide further explanation of the
    exploit and the rationale behind the patch but will not
    do so at this late hour. This patch is with respect to
    mpg123-pre0.59s and is to the file common.c:

    --- common.c.orig Wed Jan 15 02:16:08 2003
    +++ common.c Wed Jan 15 02:18:52 2003
    @@ -579,6 +579,11 @@
    fprintf(stderr,"Sorry, unknown layer
    type.\n");
    return (0);
    }
    + if (fr->framesize>MAX_INPUT_FRAMESIZE) {
    + fprintf(stderr,"Frame size too big.\n");
    + fr->framesize = MAX_INPUT_FRAMESIZE;
    + return 0;
    + }

    if(!fr->bitrate_index) {
    /* fprintf(stderr,"Warning, Free format not
    heavily tested: (head %08lx)\n",newhead); */


    Sincerely,
    Benjamin Tober

  2. #2
    3APA3A
    Re: Local/remote mpg123 exploit
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Local/remote mpg123 exploit

    Dear gobbles@hushmail.com,


    Beside all the noise: it's trivial stack overflow due to invalid maximum
    frame size calculation in mpg123. Maximum frame size is defined to be
    1792 (mpglib/mpg123.h) and 1920 (common.c where overflow probably
    actually occures). Gobblez construct frame (160 * 144000)/8000 + 1 - 4 =
    2877 bytes. Maximum frame may be constructed is probably (384 *
    144000)/16000 + 1 - 4 = 3453 bytes. Redefining MAX_INPUT_FRAMESIZE to
    4096 should probably fix the problem. mpg123.h (not one from mpglib, but
    one from mpg123 itself) already has MAXFRAMESIZE defined as 4096. It
    also could be nice to add fr->framesize check. Fix below. I'm too lazy
    to test it.

    If there are any programs using same mpglib they are vulnerable too.

    --- common.old 2003-01-15 20:18:14.000000000 +0300
    +++ common.c 2003-01-15 20:25:26.000000000 +0300
    @@ -140,7 +140,7 @@
    * -1: giving up
    * 1: synched
    */
    -#define MAX_INPUT_FRAMESIZE 1920
    +#define MAX_INPUT_FRAMESIZE 4096
    #define SYNC_HEAD_MASK 0xffff0000
    #define SYNC_HEAD_MASK_FF 0x0000f000
    #define LOOK_AHEAD_NUM 3
    @@ -237,6 +237,8 @@
    }
    }
    else {
    + if(frameInfo.framesize > MAX_INPUT_FRAMESIZE) return 0;
    +
    if(!rds->read_frame_body(rds,dummybuf,frameInfo.framesize) )
    return 0;

    --Monday, January 13, 2003, 9:23:18 PM, you wrote to bugtraq@securityfocus.com:

    ghc> Affected Software: mpg123 (pre0.59s) http://www.mpg123.de


    --
    ~/ZARAZA
    You know my name - look up my number (Beatles)


  3. #3
    Daniel Kobras
    Re: Local/remote mpg123 exploit
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Local/remote mpg123 exploit

    --DocE+STaALJfprDB
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline

    Hi!

    I'd like to stress that the mpg123 exploit posted recently does not
    affect versions up to 0.59r. The vulnerable code was added as part of
    a rewrite of mpg123's prefetch. CVS checkouts after Oct. 25th, 2000
    will be affected, as is the pre0.59s development snapshot. There has
    been no stable release in that timeframe.

    The exploitable code is accompanied by the following entry to CHANGES, by
    the way:

    - major change in the stream reader: support for free format
    streams and better 'resync-on-error'. May still contain some bugs, so
    please TEST and TEST and TEST

    Anyway, if you're running 0.59r, you're not vulnerable. (Well, not to
    this exploit, at least.)

    Regards,

    Daniel.


    --DocE+STaALJfprDB
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQE+JdBPpOKIA4m/fisRAkyFAJwO9XK65s6beYNmLyXd5FmRWoINuACgkCvE
    m1reXlQDdVSZVZN5uas1HFY=
    =hGiw
    -----END PGP SIGNATURE-----

    --DocE+STaALJfprDB--

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics