4:22 p.m.
Hi,
during the analysis of CVE-2007-6109 and if this affects
xemacs Florian Weimer and me recognized a problem in the
xemacs code:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion(a)jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:41 a.m.
Nico Golde writes:
during the analysis of CVE-2007-6109 and if this affects
xemacs Florian Weimer and me recognized a problem in the
xemacs code:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
Do you actually have an exploit? If so, we should fix the particular
use, not change the macro.
As you must know, alloca is a performance optimization. Any extra
checks will tend to defeat that purpose.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:43 a.m.
Hi Stephen,
* Stephen J. Turnbull <stephen(a)xemacs.org> [2008-01-23 12:32]:
Nico Golde writes:
> during the analysis of CVE-2007-6109 and if this affects
> xemacs Florian Weimer and me recognized a problem in the
> xemacs code:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
Do you actually have an exploit? If so, we should fix the particular
use, not change the macro.
xemacs21 -batch -eval '(format "%30000000d" 0)'
this is the same proof of concept like for CVE-2007-6109
that already has been fixed in emacs.
As you must know, alloca is a performance optimization. Any extra
checks will tend to defeat that purpose.
How is alloca related to performance? I mean you should
really fix this macro its used all over the code and it is
dangerous.
Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion(a)jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:05 p.m.
Ar an tríú lá is fiche de mí Eanair, scríobh Nico Golde:
Hi Stephen,
* Stephen J. Turnbull <stephen(a)xemacs.org> [2008-01-23 12:32]:
> Nico Golde writes:
>
> > during the analysis of CVE-2007-6109 and if this affects
> > xemacs Florian Weimer and me recognized a problem in the
> > xemacs code:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
>
> Do you actually have an exploit? If so, we should fix the particular
> use, not change the macro.
xemacs21 -batch -eval '(format "%30000000d" 0)'
this is the same proof of concept like for CVE-2007-6109
that already has been fixed in emacs.
And in XEmacs.
$ ./xemacs -batch -eval '(format "%30000000d" 0)'
$ echo $?
0
$
The fix was not included in beta 28, though. 21.4 never had the problem.
Also, that is not an exploit, not even a proof-of-concept exploit.
> As you must know, alloca is a performance optimization. Any
extra
> checks will tend to defeat that purpose.
How is alloca related to performance? I mean you should
really fix this macro its used all over the code and it is
dangerous.
No, it’s not.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:13 p.m.
Ar an tríú lá is fiche de mí Eanair, scríobh Aidan Kehoe:
Ar an tríú lá is fiche de mí Eanair, scríobh Nico Golde:
> Hi Stephen,
> * Stephen J. Turnbull <stephen(a)xemacs.org> [2008-01-23 12:32]:
> > Nico Golde writes:
> >
> > > during the analysis of CVE-2007-6109 and if this affects
> > > xemacs Florian Weimer and me recognized a problem in the
> > > xemacs code:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
> >
> > Do you actually have an exploit? If so, we should fix the particular
> > use, not change the macro.
>
> xemacs21 -batch -eval '(format "%30000000d" 0)'
> this is the same proof of concept like for CVE-2007-6109
> that already has been fixed in emacs.
And in XEmacs.
$ ./xemacs -batch -eval '(format "%30000000d" 0)'
$ echo $?
0
$
The fix was not included in beta 28, though. 21.4 never had the problem.
My mistake; there is a related problem that 21.5 had and 21.4 never did, but
21.4 does have this one.
Also, that is not an exploit, not even a proof-of-concept exploit.
[...]
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:10 p.m.
Nico Golde writes:
How is alloca related to performance?
Excuse me? alloca is used to avoid a malloc/free pair in performance-
critical places, often in inner loops. It's a dirty hack, of course,
but essential for performance reasons.
I mean you should really fix this macro its used all over the code
and it is dangerous.
So is crossing streets used by automobiles, but billions of
pedestrians do that every day, as a performance optimization.
The specific problem with `format' has already been fixed in XEmacs
21.5, I believe (it does not segfault), and probably is slated for the
next release of XEmacs 21.4.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:26 p.m.
Hi Stephen,
* Stephen J. Turnbull <stephen(a)xemacs.org> [2008-01-23 19:08]:
Nico Golde writes:
> How is alloca related to performance?
Excuse me? alloca is used to avoid a malloc/free pair in performance-
critical places, often in inner loops. It's a dirty hack, of course,
but essential for performance reasons.
Ah ok you wanted to point to this, true alloca is basically
just add on bsp.
> I mean you should really fix this macro its used all over the
code
> and it is dangerous.
So is crossing streets used by automobiles, but billions of
pedestrians do that every day, as a performance optimization.
;)
Ok anyway its your code so I don't care. To get a more
friendlier discussion again ... when I checked CVE-2007-6109 I looked
at the code and saw that there should be no problem unless I
saw this macro. That's why I did mail you, I did however not
check any other upstream release I assumed we have the
latest release in Debian. If not ok, thanks for pointing
that out.
The specific problem with `format' has already been fixed in
XEmacs
21.5, I believe (it does not segfault), and probably is slated for the
next release of XEmacs 21.4.
Ok thanks for this information. I am going to ping the
xemacs maintainer to update our builds then. Do you have a
patch read in case he is missing in action?
Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion(a)jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:58 p.m.
Ar an chéad lá is fiche de mí Eanair, scríobh Nico Golde:
Hi,
during the analysis of CVE-2007-6109 and if this affects
xemacs Florian Weimer and me recognized a problem in the
xemacs code:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
[whence]
It turned out that this is actually no bug in the quoted
code because the precision is taken into account when
reserving memory for the buffer. Unfortunately this is the
problem because:
#define alloca_array(type, len) ((type *) alloca ((len) * sizeof (type)))
this does not do any checks and also includes an integer
overflow and thus it is still possible to reproduce this
problem. So the obvious thing is to fix this macro which
should be quite important because alloca_array is used at a
bunch of different places in the code.
(format "%.*d" -1 25)
=> "25"
I don’t see any bug here. The particular use of alloca_array you’re talking
about has its length argument checked; it’s zero at a minimum. The function
#'gtk-pixmap-get in ui-byhand.c doesn’t check that the argument to
alloca_array is non-negative, but anyone who can call #'gtk-pixmap-get
mailiciously can call #'make-vector maliciously too, where allocating memory
is the documented and intentional behaviour of the API.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6495
days inactive
6497
days old
7 comments
3 participants
participants (3)
-
Aidan Kehoe -
Nico Golde -
Stephen J. Turnbull