Hi, your 2.6.1 release fixes a security issue which I work on currently for Debian. Currently this is tracked as http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5244 (which is exactly this issue: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=18c0264660b9;style=gitweb) and is also part of http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4610 I confirmed that this is fixed in 2.6.1 since xine doesn''t crash with this file anymore and the 2.6.1 changes are included in the latest xine version. But looking at the patch the xine people applied I am not sure what the fix is, this patch is just too large to find that out. As this also affects mplayer for Debian, can you tell me what fixed this issue and what was the nature of this? My comments regarding this are online at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407010#91 Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20081203/55e4b2dd/attachment.pgp
This security fix does not apply to any of those applications, unless they made their own security bugs :P The fix only applied to the FAAD2 frontend, so it is not in the actual decoding library. Menno On Wed, Dec 3, 2008 at 11:36 AM, Nico Golde <nion at debian.org> wrote:> Hi, > your 2.6.1 release fixes a security issue which I work on > currently for Debian. > Currently this is tracked as > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5244 > (which is exactly this issue: > http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=18c0264660b9;style=gitweb) > and is also part of > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4610 > > I confirmed that this is fixed in 2.6.1 since xine doesn''t > crash with this file anymore and the 2.6.1 changes are > included in the latest xine version. > > But looking at the patch the xine people applied I am not > sure what the fix is, this patch is just too large to find > that out. As this also affects mplayer for Debian, can you > tell me what fixed this issue and what was the nature of > this? > > My comments regarding this are online at: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407010#91 > > Cheers > Nico > > -- > Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF > For security reasons, all text in this mail is double-rot13 encrypted. >
Hi, * Menno Bakker <info at audiocoding.com> [2008-12-03 22:09]:> This security fix does not apply to any of those applications, unless > they made their own security bugs :P > The fix only applied to the FAAD2 frontend, so it is not in the actual > decoding library.I am aware of the issue you are talking about but this is CVE-2008-4201 which is different. The issue I was talking about is a crash for http://sam.zoy.org/zzuf/lol-mplayer.aac (not related to the frontend) which doesn''t crash since 2.6.1 anymore. Cheers Nico -- Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20081203/3a57197e/attachment.pgp
Ah yes, I''m sorry. I seem to remember that it is this one (hope the link works for you): http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/specrec.c?r1=1.60&r2=1.61&diff_format=u If that''s not it, please let me know, then I will have to look a bit deeper. Regards, Menno On Wed, Dec 3, 2008 at 1:15 PM, Nico Golde <nico at ngolde.de> wrote:> Hi, > * Menno Bakker <info at audiocoding.com> [2008-12-03 22:09]: >> This security fix does not apply to any of those applications, unless >> they made their own security bugs :P >> The fix only applied to the FAAD2 frontend, so it is not in the actual >> decoding library. > > I am aware of the issue you are talking about but this is > CVE-2008-4201 which is different. The issue I was talking > about is a crash for http://sam.zoy.org/zzuf/lol-mplayer.aac > (not related to the frontend) which doesn''t crash since > 2.6.1 anymore. > > Cheers > Nico > -- > Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF > For security reasons, all text in this mail is double-rot13 encrypted. >
Hi Nico, Ok I did some more digging: Together with that patch for specrec.c you should at least include the following patches: http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/error.c?r1=1.32&r2=1.33&diff_format=u http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/error.h?r1=1.26&r2=1.27&diff_format=u I''m not sure if that solves the crash you mention though. But the returned error value might cause the array of error strings to be accessed out of bounds if you don''t apply those 2 patches. There were a couple of patches I applied a few days after that specrec.c one: http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/structs.h?r1=1.47&r2=1.48&diff_format=u http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/ps_dec.c?r1=1.14&r2=1.15&diff_format=u http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/decoder.c?r1=1.114&r2=1.115&diff_format=u Other than that only 1 file changed, twice even, common.h. But those were not affecting GCC compiles as far as I can see. Hope this helps. Regards, Menno On Sun, Dec 14, 2008 at 9:07 AM, Nico Golde <debian-secure-testing+ml at ngolde.de> wrote:> Hi, > sorry for coming back to you that late... > * Menno Bakker <info at audiocoding.com> [2008-12-04 00:51]: >> Ah yes, I''m sorry. I seem to remember that it is this one (hope the >> link works for you): >> >> http://faac.cvs.sourceforge.net/viewvc/faac/faad2/libfaad/specrec.c?r1=1.60&r2=1.61&diff_format=u >> >> If that''s not it, please let me know, then I will have to look a bit deeper. > > It indeed changed the behaviour but it still segfaults > around (filtbank.c): > 245 for (i = 0; i < nlong; i+=4) > 246 { > 247 time_out[i] = overlap[i] + MUL_F(transf_buf[i],window_long_prev[i]); > 248 time_out[i+1] = overlap[i+1] + MUL_F(transf_buf[i+1],window_long_prev[i+1]); > 249 time_out[i+2] = overlap[i+2] + MUL_F(transf_buf[i+2],window_long_prev[i+2]); > 250 time_out[i+3] = overlap[i+3] + MUL_F(transf_buf[i+3],window_long_prev[i+3]); > 251 } > > > A complete backtrace is attached. Can you remember of any other fix related to this? > > Cheers > Nico > > -- > Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF > For security reasons, all text in this mail is double-rot13 encrypted. >