Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
I'm going to prepare an NMU (sponsored by Adeodato Simó) which may or may not fix this bug (but will fix various others, particularly the build failure on sparc, which is due to a missing "-I "). It should also fix the "sorry, unimplemented" failures on some other architectures, which is due to use of inline functions after declaration but before definition and a couple of other bugs, two of which are security-related. (The failure on m68k was due to a compiler bug.) We could stick with 1.1.1 but that won't fix this bug because, basically, I'm fairly sure that it's been fixed as a side-effect of an ffmpeg update or, possibly, some hacking on the win32 codec support. (Unfortunately, this means that we (xine developers) can't sensibly provide a patch for stable at this time.) The alternative is a CVS snapshot; most of the patches which I would be applying are already in CVS (I'll need to check and possibly apply the inline fixups). The two security fixes mentioned above are reported in bug 369876. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) # rm -rf /bin/laden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
On Thu, Jun 01, 2006 at 11:17:48PM +0100, Darren Salt wrote: > I'm going to prepare an NMU (sponsored by Adeodato Simó) which may or may > not fix this bug (but will fix various others, particularly the build failure > on sparc, which is due to a missing "-I "). It should also fix the > "sorry, unimplemented" failures on some other architectures, which is due to > use of inline functions after declaration but before definition and a couple > of other bugs, two of which are security-related. (The failure on m68k was > due to a compiler bug.) Interesting, I tried to look at the FTBFS on a mips machine, and succeeded to build it with external ffmpeg. If it turns out that it was just a missing -I, even better. > We could stick with 1.1.1 but that won't fix this bug because, basically, I'm > fairly sure that it's been fixed as a side-effect of an ffmpeg update or, > possibly, some hacking on the win32 codec support. (Unfortunately, this means > that we (xine developers) can't sensibly provide a patch for stable at this > time.) Btw, is #369876 the same issue as #363127 or is this something else? > The alternative is a CVS snapshot; most of the patches which I would be > applying are already in CVS (I'll need to check and possibly apply the inline > fixups). The two security fixes mentioned above are reported in bug 369876. Hm. Given security issues being fixed in cvs, I think uploading a CVS snapshot would be a good option. How about uploading it to experimental first, and give more ppl the chance of actually testing it? Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
I demand that Reinhard Tartler may or may not have written... > On Thu, Jun 01, 2006 at 11:17:48PM +0100, Darren Salt wrote: >> I'm going to prepare an NMU (sponsored by Adeodato Simó) which may or may >> not fix this bug (but will fix various others, particularly the build >> failure on sparc, which is due to a missing "-I "). It should also >> fix the "sorry, unimplemented" failures on some other architectures, which >> is due to use of inline functions after declaration but before definition >> and a couple of other bugs, two of which are security-related. (The >> failure on m68k was due to a compiler bug.) > Interesting, I tried to look at the FTBFS on a mips machine, and succeeded > [in building] it with external ffmpeg. If it turns out that it was just a > missing -I, even better. On sparc, yes - the error in the buildd log concerns a header file which just happens to be in the directory referenced in the diff between revisions 1.1 and 1.2 of src/libffmpeg/libavcodec/sparc/Makefile.am. On mips, the problem in the buildd log is too-early use of inline functions; you should find that my VDR-patched version is buildable there, or at least fails differently. >> We could stick with 1.1.1 but that won't fix this bug because, basically, >> I'm fairly sure that it's been fixed as a side-effect of an ffmpeg update >> or, possibly, some hacking on the win32 codec support. (Unfortunately, >> this means that we (xine developers) can't sensibly provide a patch for >> stable at this time.) > Btw, is #369876 the same issue as #363127 or is this something else? It's for the two security problems for which we have patches, and it's filed since it looks like they affect the version in sarge. >> The alternative is a CVS snapshot; most of the patches which I would be >> applying are already in CVS (I'll need to check and possibly apply the >> inline fixups). The two security fixes mentioned above are reported in bug >> 369876. > Hm. Given security issues being fixed in cvs, I think uploading a CVS > snapshot would be a good option. . > How about uploading it to experimental first, and give more ppl the chance > of actually testing it? That seems reasonable; I'll prepare a source package. Any objections? -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. "The name's Borg, James Borg. Prepare to be assimilated, Miss Moneypenny." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
On Fri, Jun 02, 2006 at 07:14:05PM +0100, Darren Salt wrote: > I demand that Reinhard Tartler may or may not have written... > > >> I'm going to prepare an NMU (sponsored by Adeodato Simó) which may or may > >> not fix this bug (but will fix various others, particularly the build > >> failure on sparc, which is due to a missing "-I "). It should also > >> fix the "sorry, unimplemented" failures on some other architectures, which > >> is due to use of inline functions after declaration but before definition > >> and a couple of other bugs, two of which are security-related. (The > >> failure on m68k was due to a compiler bug.) > > > Interesting, I tried to look at the FTBFS on a mips machine, and succeeded > > [in building] it with external ffmpeg. If it turns out that it was just a > > missing -I, even better. > > On sparc, yes - the error in the buildd log concerns a header file which just > happens to be in the directory referenced in the diff between revisions 1.1 > and 1.2 of src/libffmpeg/libavcodec/sparc/Makefile.am. > > On mips, the problem in the buildd log is too-early use of inline functions; > you should find that my VDR-patched version is buildable there, or at least > fails differently. Interesting. Care to give me a pointer to your patches for fixing this FTBFS? > > How about uploading it to experimental first, and give more ppl the chance > > of actually testing it? > > That seems reasonable; I'll prepare a source package. Any objections? No, I think you can get it uploaded straight to experimental. If you have problems finding a sponsor, please give me a link to your source package, I'd like to test it locally here. (No, I'm not a DD yet, sorry) Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
* Reinhard Tartler [Fri, 02 Jun 2006 21:41:02 +0200]: Hey, > On Fri, Jun 02, 2006 at 07:14:05PM +0100, Darren Salt wrote: > > I demand that Reinhard Tartler may or may not have written... > > > How about uploading it to experimental first, and give more ppl the chance > > > of actually testing it? > > That seems reasonable; I'll prepare a source package. Any objections? > No, I think you can get it uploaded straight to experimental. If you > have problems finding a sponsor, please give me a link to your source > package, I'd like to test it locally here. (No, I'm not a DD yet, sorry) Well, if you both think that pulling fixes from CVS means the package should go to experimental first, okay, I'll respect that. However, I really really don't want #358429 (the shlibs bug) to remain open for any longer, but alas, I'm a bit doubtful of making an upload to fix that without fixing the various FTBFS bugs, since otherwise we may prevent a chunk of packages from entering testing. So: would it be much effort (read: would either of you be willing) to create a package targetted at unstable fixing shlibs+FTBFS? If you'd rather not, can I get a brief summary of what the patches to fix the FTBFS are, and then I'll give a shot to making the upload myself? Thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Guy: My dad made my mom have a cesarean when she had my little brother. He wanted to make sure he was born in the 1986 tax year so he could get another tax credit. -- http://www.overheardinnewyork.com/archives/002968.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
I demand that Adeodato Simó may or may not have written... > * Reinhard Tartler [Fri, 02 Jun 2006 21:41:02 +0200]: >> On Fri, Jun 02, 2006 at 07:14:05PM +0100, Darren Salt wrote: >>> I demand that Reinhard Tartler may or may not have written... How about uploading it to experimental first, and give more ppl the chance of actually testing it? >>> That seems reasonable; I'll prepare a source package. Any objections? >> No, I think you can get it uploaded straight to experimental. If you have >> problems finding a sponsor, please give me a link to your source package, >> I'd like to test it locally here. (No, I'm not a DD yet, sorry) > Well, if you both think that pulling fixes from CVS means the package > should go to experimental first, okay, I'll respect that. However, I really > really don't want #358429 (the shlibs bug) to remain open for any longer, > but alas, I'm a bit doubtful of making an upload to fix that without fixing > the various FTBFS bugs, since otherwise we may prevent a chunk of packages > from entering testing. Bug 363127 will keep it out of testing anyway since it's filed against 1.1.1-1. (The bug's probably also in 1.0.3, but since I couldn't trigger it with 1.1.1...) > So: would it be much effort (read: would either of you be willing) to > create a package targetted at unstable fixing shlibs+FTBFS? If you'd rather > not, can I get a brief summary of what the patches to fix the FTBFS are, > and then I'll give a shot to making the upload myself? The .diff.gz, .dsc etc. for 1.1.1-1.2 are at http://zap.tartarus.org/~ds/debian/> I've not uploaded the source tarball or the .debs since that'd take too long, and the .diff.gz is a bit bulky because I've had to re-run autogen.sh... hmm, I've forgotten to add an "NMU" changelog item... oh well. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Let's keep the pound sterling Nobody ever ruined their eyesight by looking at the bright side of something. signature.asc Description: PGP signature
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
I demand that Reinhard Tartler may or may not have written... > On Fri, Jun 02, 2006 at 10:10:01PM +0100, Darren Salt wrote: >> The .diff.gz, .dsc etc. for 1.1.1-1.2 are at >> http://zap.tartarus.org/~ds/debian/> > Btw, why aren't you in Uploaders: and prepare a new maintainer upload? Siggi - any objections? > I took your source package and gave it the version 1.1.1-2. I sucessfully > built it on amd64, but got no sound at all (but might be chroot related, so > I'm not sure). Bind-mounting /dev should fix that :-) (I can test on amd64 here, as it happens, and I've had no problems with sound during my normal use of gxine.) > I tried to build it on tbm's mips machine as well, and it still FTBFS. I > attached the build log to this mail. It seems that the inline problems have > been solved, but now there is another problem. h264.c:5659: sorry, unimplemented: inlining failed in call to 'compute_mb_neighboors': function body not available h264.c:5718: sorry, unimplemented: called from here Which is weird, because I don't recall it falling over on that one here... hmm, the difference seems to be the optimisation level, at least on i386: -O2 provokes this, -O3 doesn't. Basically, if you see any more of these, comment out or remove the 'inline' in the offending function declaration. --- ./src/libffmpeg/libavcodec/h264.c~ 2006-06-03 14:21:41.0 +0100 +++ ./src/libffmpeg/libavcodec/h264.c 2006-06-03 14:21:41.0 +0100 @@ -5655,7 +5655,7 @@ return 0; } -void inline compute_mb_neighboors(H264Context *h) +static void /*inline*/ compute_mb_neighboors(H264Context *h) { MpegEncContext * const s = &h->s; const int mb_xy = s->mb_x + s->mb_y*s->mb_stride; -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Bugs do not exist. Programs merely have undocumented features. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
And another patch, prompted by Martin Michlmayr's posting in debian-devel about gcc 4.1 being the default for etch. Changelog entry addition: * Kill some pointer<->int casting warnings on 64-bit architectures. (All three fixes are in CVS HEAD; I've just committed two of them.) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. "Well! I've often seen a cat without a grin, but a grin without a cat!" diff -u xine-lib-1.1.1/src/libffmpeg/libavcodec/h264.c xine-lib-1.1.1/src/libffmpeg/libavcodec/h264.c --- xine-lib-1.1.1/src/libffmpeg/libavcodec/h264.c +++ xine-lib-1.1.1/src/libffmpeg/libavcodec/h264.c @@ -386,7 +386,7 @@ w *= size; stride *= size; -assertint)vp)&(FFMIN(w, STRIDE_ALIGN)-1)) == 0); +assertlong)vp)&(FFMIN(w, STRIDE_ALIGN)-1)) == 0); assert((stride&(w-1))==0); //FIXME check what gcc generates for 64 bit on x86 and possibly write a 32 bit ver of it if(w==2 && h==2){ --- xine-lib-1.1.1.orig/src/post/goom/goomsl_heap.c +++ xine-lib-1.1.1/src/post/goom/goomsl_heap.c @@ -39,7 +39,7 @@ { if ((alignment > 1) && (_this->number_of_arrays>0)) { void *last_array = _this->arrays[_this->number_of_arrays - 1]; -int last_address = (int)last_array + _this->consumed_in_last_array; +long last_address = (long)last_array + _this->consumed_in_last_array; int decal = (last_address % alignment); if (decal != 0) { _this->consumed_in_last_array += alignment - decal; --- xine-lib-1.1.1.orig/src/dxr3/video_out_dxr3.c +++ xine-lib-1.1.1/src/dxr3/video_out_dxr3.c @@ -1203,7 +1203,7 @@ break; case XINE_GUI_SEND_VIDEOWIN_VISIBLE: { - int window_showing = (int)data; + long window_showing = (long)data; int val; if (!window_showing) { llprintf(LOG_VID, "Hiding video window and diverting video to TV\n");
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
Package: libxine1 Version: 1.1.1-1 Severity: grave Tags: security Justification: user security hole According to CVE-2006-1664, there is a "buffer overflow in xine_list_delete_current in libxine 1.14 and earlier, as distributed in xine-lib 1.1.1 and earlier, allows remote attackers to execute arbitrary code via a crafted MPEG stream." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
Stefan Fritsch wrote: > Package: libxine1 > Version: 1.1.1-1 > Severity: grave > Tags: security > Justification: user security hole > > > > According to CVE-2006-1664, there is a "buffer overflow in > xine_list_delete_current in libxine 1.14 and earlier, as distributed > in xine-lib 1.1.1 and earlier, allows remote attackers to execute > arbitrary code via a crafted MPEG stream." Are you able to reproduce this? If so, we need your help as I can't since xine pretends not to know about the file format of the created egg file. However, I was using xine instead of gxine since the latter is not available in Debian. Maybe some non-free decoders are required? In that case, Debian is not vulnerable per definition since they aren't shipped by Debian. Regards, Joey -- Experience is something you don't get until just after you need it. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
No, I didn't test the exploit when I filed the bug. I can't reproduce the crash now, neither with xine nor gxine (gxine is in a separate package). The file seems to be asf, and normally the xine in debian can play (or at least demux) asf. Either Debian's xine is not vulnerable because some feature is missing or the exploit is just not working for some other reason. Unfortunately I don't know which. http://bugs.gentoo.org/show_bug.cgi?id=128838 says that the gentoo guys could reproduce it with 1.1.1. Cheers, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354436: Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
On Sat, Jun 03, 2006 at 02:37:47PM +0100, Darren Salt wrote: > > I took your source package and gave it the version 1.1.1-2. I sucessfully > > built it on amd64, but got no sound at all (but might be chroot related, so > > I'm not sure). > > Bind-mounting /dev should fix that :-) > > (I can test on amd64 here, as it happens, and I've had no problems with > sound during my normal use of gxine.) Ah, thanks for the tip, that worked for me, and now I can verify that xine does play sound on amd64 :) > > I tried to build it on tbm's mips machine as well, and it still FTBFS. I > > attached the build log to this mail. It seems that the inline problems have > > been solved, but now there is another problem. > > h264.c:5659: sorry, unimplemented: inlining failed in call to > 'compute_mb_neighboors': function body not available > h264.c:5718: sorry, unimplemented: called from here > > Basically, if you see any more of these, comment out or remove the 'inline' > in the offending function declaration. ok, I rewent through this again on mips, and indeed, I managed to make it build on mips. I also tested latest cvs, but thats broken as well. Oh, well, I think I need to extract our local changes and post it as patch to xine-devel mailing list. anyway. I prepared an upload here: http://siretart.tauware.de/upload-queue/xine-lib_1.1.1-2.dsc I don't think that this upload fixes #363127 however. All other distros seem to have 'fixed' this by uploading a xine snapshot, what we agreed to do in experimental for now, but not yet in unstable. But I'd like to hear siggi's opinion on this matter, if we should upload a cvs snapshot to debian anyway. Siggi, If you agree, could you please check and upload the package, I mentioned above? Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354436: Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
I demand that Reinhard Tartler may or may not have written... [snip] > I prepared an upload here: > http://siretart.tauware.de/upload-queue/xine-lib_1.1.1-2.dsc It needs the attached patch (committed to CVS by Matthias Hopf). -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 => avoid massive flooding.TIME IS RUNNING OUT *FAST*. Buy a P4 so that you can reboot faster. diff -u -r1.117 -r1.118 --- xine-lib/src/input/input_http.c 2 Jun 2006 22:44:58 - 1.117 +++ xine-lib/src/input/input_http.c 6 Jun 2006 16:39:25 - 1.118 @@ -900,10 +900,10 @@ len = 0; } else len ++; -if ( len >= buflen ) { +if ( len >= BUFSIZE ) { _x_message(this->stream, XINE_MSG_PERMISSION_ERROR, this->mrl, NULL); xine_log (this->stream->xine, XINE_LOG_MSG, - _("input_http: buffer exhausted after %d bytes."), buflen); + _("input_http: buffer exhausted after %d bytes."), BUFSIZE); return 0; } }
Bug#354436: Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability
On Tue, Jun 06, 2006 at 11:04:40PM +0100, Darren Salt wrote: > I demand that Reinhard Tartler may or may not have written... > > [snip] > > I prepared an upload here: > > http://siretart.tauware.de/upload-queue/xine-lib_1.1.1-2.dsc > > It needs the attached patch (committed to CVS by Matthias Hopf). I included that patch and updated the package. The url above now includes an updated package including that patch. thanks for pointing out! Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#363127: xine-lib patches (was: Bug#363127: CVE-2006-1664: Malformed MPEG Stream Buffer Overflow Vulnerability)
I demand that Reinhard Tartler may or may not have written... > On Fri, Jun 02, 2006 at 07:14:05PM +0100, Darren Salt wrote: [snip] >> On mips, the problem in the buildd log is too-early use of inline >> functions; you should find that my VDR-patched version is buildable there, >> or at least fails differently. > Interesting. Care to give me a pointer to your patches for fixing this > FTBFS? http://zap.tartarus.org/~ds/debian/dists/unstable/main/source/xine-lib-vdr_1.1.1-1.1vdr2.dsc> Apply the correspondng .diff.gz in an empty directory and look at debian/patches/23_inline_use_before_define.dpatch. (Note that that package is not intended for upload.) >>> How about uploading it to experimental first, and give more ppl the >>> chance of actually testing it? >> That seems reasonable; I'll prepare a source package. Any objections? > No, I think you can get it uploaded straight to experimental. If you have > problems finding a sponsor, Already sorted out. > please give me a link to your source package, I'd like to test it locally > here. (No, I'm not a DD yet, sorry) Will do regardless. I'm currently going through Gentoo's patches to see what should go into CVS; there are a few useful fixes there... -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Generate power using sun, wind, water, nuclear. FORGET COAL AND OIL. Think twice before speaking. But don't say "think think click click". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]