Secure testing team - Dec 2007 - r7571 - data/CVE

Author: nion
Date: 2007-12-10 02:04:31 +0000 (Mon, 10 Dec 2007)
New Revision: 7571

Modified:
   data/CVE/list
Log:
new issue: emacs (CVE-2007-6109)


Modified: data/CVE/list
==================================================================---
data/CVE/list	2007-12-09 20:42:00 UTC (rev 7570)
+++ data/CVE/list	2007-12-10 02:04:31 UTC (rev 7571)
@@ -363,8 +363,9 @@
 	- htdig 1:3.2.0b6-4 (low; bug #453278)
 	[sarge] - htdig <not-affected> (Vulnerable code not present)
 CVE-2007-6109 (Buffer overflow in emacs allows attackers to have an unknown
impact, ...)
-	TODO: check
-	NOTE: poked Marcus from Novell for the patch
+	- emacs22 <unfixed> (bug #455432)
+	- emacs21 <unfixed> (bug #455433)
+	- xemacs21 <not-affected> (Vulnerable code not present)
 CVE-2007-6108
 	RESERVED
 CVE-2007-6107

>  CVE-2007-6109 (Buffer overflow in emacs allows attackers to have an
unknown impact, ...)
> -	TODO: check
> -	NOTE: poked Marcus from Novell for the patch
> +	- emacs22 <unfixed> (bug #455432)
> +	- emacs21 <unfixed> (bug #455433)
> +	- xemacs21 <not-affected> (Vulnerable code not present)
I''m sorry to report that xemacs21 is affected as well.  The affected
code is in src/doprnt.c:

              /* Mostly reconstruct the spec and use sprintf() to
                 format the string. */

              *p++ = ''%'';
              if (spec->plus_flag)   *p++ = ''+'';
              if (spec->space_flag)  *p++ = '' '';
              if (spec->number_flag) *p++ = ''#'';
              if (spec->minus_flag)  *p++ = ''-'';
              if (spec->zero_flag)   *p++ = ''0'';

              if (spec->minwidth >= 0)
                p = long_to_string (p, spec->minwidth);
              if (spec->precision >= 0)
                {
                  *p++ = ''.'';
                  p = long_to_string (p, spec->precision);
                }

              if (strchr (double_converters, ch))
                {
                  *p++ = ch;
                  *p++ = ''\0'';
                  sprintf (text_to_print, constructed_spec, arg.d);
                }
              else
                {
                  *p++ = ''l'';   /* Always use longs with
sprintf() */
                  *p++ = ch;
                  *p++ = ''\0'';

                  if (strchr (unsigned_int_converters, ch))
                    sprintf (text_to_print, constructed_spec, arg.ul);
                  else
                    sprintf (text_to_print, constructed_spec, arg.l);
                }

I haven''t compared it to the emacs21/emacs22 code, I don''t
know if the
same patch applies.

Hi Florian,
* Florian Weimer <fw at deneb.enyo.de> [2007-12-24
22:03]:
> >  CVE-2007-6109 (Buffer overflow in emacs allows attackers to have an
unknown impact, ...)
> > -	TODO: check
> > -	NOTE: poked Marcus from Novell for the patch
> > +	- emacs22 <unfixed> (bug #455432)
> > +	- emacs21 <unfixed> (bug #455433)
> > +	- xemacs21 <not-affected> (Vulnerable code not present)
> 
> I''m sorry to report that xemacs21 is affected as well.  The
affected
> code is in src/doprnt.c:
[...] 
> I haven''t compared it to the emacs21/emacs22 code, I
don''t know if the
> same patch applies.
Thanks very much for finding that. I did not see it when 
checking the xemacs code because the code is located 
somewhere else and the code itself is also different. This 
also means that we have to write our own patch or do you 
have one?

How did you spot that?
Kind regards and thanks
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: 189 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071224/4b81c582/attachment.pgp

* Nico Golde:
> Thanks very much for finding that. I did not see it when 
> checking the xemacs code because the code is located 
> somewhere else and the code itself is also different. This 
> also means that we have to write our own patch or do you 
> have one?
Sorry, I haven''t.  The easiest route would probably replace the sprintf
calls with snprintf, and erroring out when the buffer is not large
enough.
> How did you spot that?
On a hunch, I tried to trigger the bug on XEmacs.  Perhaps I
misremembered the reproducer, but it eventually crashed.