Re[2]: Local/remote mpg123 exploit

[3APA3A]

Dear Benjamin Tober,

Latest release mpg123 0.59r uses large enough buffer size and may not be
exploited this way. But both versions have another one bug in frame size
calculation - zero bitrate will lead to negative frame size to be
calculated. Unchecked patches:

for 0.59r:

--- common.old 2003-01-15 21:42:15.000000000 +0300
+++ common.c 2003-01-15 21:42:38.000000000 +0300
@@ -123,7 +123,7 @@
return FALSE;
if(!((head>>17)&3))
return FALSE;
- if( ((head>>12)&0xf) == 0xf)
+ if( ((head>>12)&0xf) == 0xf || (head>>12)&0xf) == 0)
return FALSE;
if( ((head>>10)&0x3) == 0x3 )
return FALSE;

for pre0.59s:

--- common.old 2003-01-15 20:51:15.000000000 +0300
+++ common.c 2003-01-15 20:25:26.000000000 +0300
@@ -127,7 +127,7 @@
return FALSE;
if(!((head>>17)&3))
return FALSE;
- if( ((head>>12)&0xf) == 0xf || (head>>12)&0xf) == 0)
+ if( ((head>>12)&0xf) == 0xf)
return FALSE;
if( ((head>>10)&0x3) == 0x3 )
return FALSE;
@@ -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;

--Wednesday, January 15, 2003, 11:16:24 AM, you wrote to bugtraq@securityfocus.com:

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

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

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

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


BT> Sincerely,
BT> Benjamin Tober


--
~/ZARAZA
Áðîñüòå ñòàðàòüñÿ - íè÷åãî èç ýòîãî íå âûéäåò. (Òâåí)

[Gabucino]

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> mplayer (www.mplayerhq.org)
Gobbles must have been so busy coding a "robust exploit" for our
software that they forgot the URL of our site: http://www.mplayerhq.hu


> 1) If you participate in illegal file-sharing networks, your
> computer now belongs to the RIAA.
Although I like smiling over funny emails, we'd be more pleased if
a real vulnerability would be disclosed in our code - we don't do
security audits, nor do we have interest and time for it.

On to the topic, as far as I know we are NOT vulnerable to this
particular exploit. Our "mp3lib" was indeed forked from certain parts
of mpg123 years ago, but since then the code was optimized so much,
I highly doubt it resembles the current mpg123 codebase at all.

--=20
Gabucino
MPlayer Core Team

--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+KZe7Aq6GhkS0XDcRAjPjAJ9R9zrjAyU7kRSTkVkU/9nzYp/h4gCeL4XX
xLBc45MpD2VSzjf0gFGK4oM=
=e9Jt
-----END PGP SIGNATURE-----

--82I3+IH0IqGh5yIs--