Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 200297 (CVE-2007-6109) - app-editors/emacs < 22.1-r3 Buffer overflow in format function (CVE-2007-6109)
Summary: app-editors/emacs < 22.1-r3 Buffer overflow in format function (CVE-2007-6109)
Status: RESOLVED FIXED
Alias: CVE-2007-6109
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A3 [glsa | ebuild]
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-25 16:33 UTC by Ulrich Müller
Modified: 2013-09-03 04:35 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Müller gentoo-dev 2007-11-25 16:33:03 UTC
The following was pointed out to me by solar, who asked me not to disclose it (so restricting to Security for the time being) since the corresponding CVE-2007-6109 is not yet public.

Andreas Schwab from SuSE found a buffer overflow in the Emacs format function for conversion of integers. This is SuSE bug 342158.

To reproduce:
$ emacs -batch -eval '(format "%.1000d" 1)'
Fatal error (11)Segmentation fault
Comment 1 Ulrich Müller gentoo-dev 2007-11-25 17:35:28 UTC
Fixed in app-editors/emacs-21.4-r14 and emacs-22.1-r3.

Please note:
- app-editors/emacs-cvs ebuilds are already fixed by upstream or hardmasked.
- The format fuction in emacs-18.59 doesn't support precision, this version
  is therefore unaffected.

Vulnerable versions: <22.1-r3
Unaffected versions: >=22.1-r3, revision >=21.4-r14, <19

Target keywords for stabilisation are:
emacs-21.4-r14: alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86
emacs-22.1-r3:  alpha amd64 ia64 ppc ppc64 sparc x86

Security team, please advise. How should stabilisation be handled for a confidential issue?
Comment 2 Ulrich Müller gentoo-dev 2007-11-25 18:15:52 UTC
> Security team, please advise. How should stabilisation be handled for a
> confidential issue?

Excuse the sloppy wording. I just learned that (according to the Coordinator Guide) the issue should be "SEMI-PUBLIC" since the patch has already been committed to upstream CVS.
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2007-11-25 18:23:02 UTC
Adding Arch Security liaisons and Chris for RelEng.

Please test and mark stable (in CVS) the two Emacs ebuilds mentioned in comment #1.
Comment 4 Ulrich Müller gentoo-dev 2007-11-25 19:26:55 UTC
XEmacs is also affected, CCing graaff.
Comment 5 Hans de Graaff gentoo-dev 2007-11-25 19:39:07 UTC
I've just verified that app-editors/xemacs-21.4.21 is not affected by this bug. It calculates the buffer size taking the precision argument into account, as can be seen on line 599 of src/doprnt.c.

Interestingly enough XEmacs 21.5 is vulnerable, but we only have a copy of that in the emacs overlay.
Comment 6 Jeroen Roovers gentoo-dev 2007-11-26 00:40:22 UTC
Both stable for HPPA.
Comment 7 Hans de Graaff gentoo-dev 2007-11-26 20:19:39 UTC
Just a quick note to mention that XEmacs 21.5 in the emacs overlay has now been patched. 
Comment 8 Ulrich Müller gentoo-dev 2007-11-26 20:43:03 UTC
  26 Nov 2007; Christian Faulhammer <opfer@gentoo.org>
  emacs-21.4-r14.ebuild, emacs-22.1-r3.ebuild:
  stable x86
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2007-11-27 14:13:15 UTC
(In reply to comment #1)
> Please note:
> - app-editors/emacs-cvs ebuilds are already fixed by upstream or hardmasked.
> - The format fuction in emacs-18.59 doesn't support precision, this version
>   is therefore unaffected.

 Although of all above I did a revbump for all CVS packages so people are forced to rebuild with a newer code-base avoiding this security flaw.  No GLSA for any of them needed (not stable or masked).  ulm, maybe we should remove the CVS reference snapshots now or move them to the overlay.
Comment 10 Ulrich Müller gentoo-dev 2007-11-27 16:20:20 UTC
> ulm, maybe we should remove the CVS reference snapshots now or move them
> to the overlay.

I've patched them for now. The bug is fixed in emacs-cvs-22.1.50_p20070829-r2 and emacs-cvs-23.0.0_p20070920-r1; vulnerable versions have been removed (as I have said before, both were hardmasked anyway).
Comment 11 Markus Rothe (RETIRED) gentoo-dev 2007-11-27 16:56:24 UTC
ppc64 stable
Comment 12 Fernando J. Pereda (RETIRED) gentoo-dev 2007-11-27 17:15:54 UTC
Add Raúl for alpha
Comment 13 Tobias Scherbaum (RETIRED) gentoo-dev 2007-11-27 17:19:25 UTC
ppc stable
Comment 14 Ulrich Müller gentoo-dev 2007-11-27 19:25:10 UTC
  27 Nov 2007; Raúl Porcel <armin76@gentoo.org> emacs-21.4-r14.ebuild,
  emacs-22.1-r3.ebuild:
  alpha/ia64/sparc stable

Only amd64 missing (of the supported arches).
Comment 15 Peter Weller (RETIRED) gentoo-dev 2007-11-28 19:43:46 UTC
amd64 has been done.
Comment 16 Ulrich Müller gentoo-dev 2007-11-28 22:03:04 UTC
All supported arches stable, therefore setting status to "glsa" (assuming that severity will stay at A3).

Ebuilds of vulnerable revisions 21.4-r13 and 22.1-r2 have been removed. However, 21.4-r{4,8,12} cannot be punted yet, because keywords for arm, s390, and sh are still missing for -r14.
Comment 17 Robert Buchholz (RETIRED) gentoo-dev 2007-11-29 00:06:18 UTC
(In reply to comment #16)
> All supported arches stable, therefore setting status to "glsa" (assuming that
> severity will stay at A3).

request filed.

> Ebuilds of vulnerable revisions 21.4-r13 and 22.1-r2 have been removed.
> However, 21.4-r{4,8,12} cannot be punted yet, because keywords for arm, s390,
> and sh are still missing for -r14.

feel free to ping them or add relevant persona to this bug.

Comment 18 Ulrich Müller gentoo-dev 2007-11-29 00:33:21 UTC
(In reply to comment #17)
> > However, 21.4-r{4,8,12} cannot be punted yet, because keywords for
> > arm, s390, and sh are still missing for -r14.
> 
> feel free to ping them or add relevant persona to this bug.

CCing vapier.
Please keyword/stabilise emacs-21.4-r14 for arm/s390/sh.
Comment 19 Ulrich Müller gentoo-dev 2007-12-07 13:46:10 UTC
CVE-2007-6109 was published today.
Could this bug be unrestricted then?
Comment 20 Robert Buchholz (RETIRED) gentoo-dev 2007-12-07 14:03:19 UTC
(In reply to comment #19)
> CVE-2007-6109 was published today.
> Could this bug be unrestricted then?

yes.

Missing keywords: "arm s390 sh"
Comment 21 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-12-09 19:54:40 UTC
GLSA 200712-03
Comment 22 Ulrich Müller gentoo-dev 2007-12-21 18:16:50 UTC
(In reply to comment #20)
> Missing keywords: "arm s390 sh"

arm is done (already several days ago), thanks vapier.
Comment 23 nion 2008-01-05 13:32:58 UTC
(In reply to comment #6)
> Both stable for HPPA.
> 

(In reply to comment #5)
> I've just verified that app-editors/xemacs-21.4.21 is not affected by this bug.
> It calculates the buffer size taking the precision argument into account, as
> can be seen on line 599 of src/doprnt.c.
> 
> Interestingly enough XEmacs 21.5 is vulnerable, but we only have a copy of that
> in the emacs overlay.


xemacs is vulnerable. did you try to reproduce the problem? it will segfault perfectly. you are right that this is not a problem in src/doprnt.c. The function takes the precision into account. But there is still a problem with this. #define alloca_array(type, len) ((type *) alloca ((len) * sizeof (type)))

There is no check here and this is also prone to an integer overflow. Thats why xemacs21 still crashes even if the precision is taken into account.
Cheers
nion

Comment 24 Robert Buchholz (RETIRED) gentoo-dev 2008-01-05 13:42:10 UTC
xemacs, please advise.
Comment 25 Hans de Graaff gentoo-dev 2008-01-20 07:54:32 UTC
(In reply to comment #23)

> xemacs is vulnerable. did you try to reproduce the problem? it will segfault
> perfectly. you are right that this is not a problem in src/doprnt.c. The
> function takes the precision into account. But there is still a problem with
> this. #define alloca_array(type, len) ((type *) alloca ((len) * sizeof (type)))
> 
> There is no check here and this is also prone to an integer overflow. Thats why
> xemacs21 still crashes even if the precision is taken into account.

I'm afraid that this additional report is too vague to be helpful. I did try to reproduce the problem with both XEmacs 21.4 and XEmacs 21.5. XEmacs 21.4 did not show the problem nor did it segfault, but XEmacs 21.5 did. However, XEmacs 21.5 is not in our CVS tree, so for the GLSA (and thus this bug) this last part doesn't matter. Note that XEmacs 21.5 in the Emacs project overlay did get patched, though.

nion, if I misunderstood anything then please be more clear with version numbers and the specific reproduceable case you are talking about.

Futhermore, XEmacs upstream and I agree with Redhat's assessment: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6109
Comment 26 Hans de Graaff gentoo-dev 2008-01-25 13:55:35 UTC
It seems that this is the original bug report that nion based his comment #23 on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10

He has discussed this with upstream, leading to the information that this applies to XEmacs 21.4.21 (which is in our tree). The bug can be reproduced with:

xemacs -batch -eval '(format "%30000000d" 0)'

It remains unclear how this is a security issue, but a patch is currently being created upstream.
Comment 27 Ulrich Müller gentoo-dev 2008-02-01 19:05:51 UTC
(In reply to comment #18)
> Please keyword/stabilise emacs-21.4-r14 for arm/s390/sh.

All done, removing remaining arches from CC.
Comment 28 Chris Gianelloni (RETIRED) gentoo-dev 2008-02-02 13:07:46 UTC
So should I wait for Xemacs for release or am I good?  We do ship Xemacs on the LiveDVD.
Comment 29 Hans de Graaff gentoo-dev 2008-02-02 13:26:54 UTC
As far as I'm concerned we are good to go with XEmacs for the release. Yes, there is still a bug parsing exceptional format parameters, but I don't see how this is a security issue and it's very unlikely to appear in normal code. There isn't a fix yet from upstream.
Comment 30 Chris Gianelloni (RETIRED) gentoo-dev 2008-02-02 14:28:59 UTC
Thanks...

Add us back if anything changes.
Comment 31 Robert Buchholz (RETIRED) gentoo-dev 2008-02-12 00:24:37 UTC
Hans, I had the understanding these LISP statements could be executed from within documents opened in XEmacs. Is that wrong?
Comment 32 Hans de Graaff gentoo-dev 2008-02-24 14:46:33 UTC
(In reply to comment #31)
> Hans, I had the understanding these LISP statements could be executed from
> within documents opened in XEmacs. Is that wrong?

Both Emacs and XEmacs have provisions to execute arbitrary elisp contained within a document when that document is opened. This should normally be used to set options for the specific editing mode (as can be done in vim), but since any lisp can be included this is also a security risk that the user accepts (or not). As a consequence of this it is also possible to include a format statement as mentioned in this bug and thus create a denial-of-service situation where the editor crashes. Given that this only happens when the user has accepted to execute arbitrary lisp code already, I don't think this constitutes an additional security risk. 
Comment 33 Ulrich Müller gentoo-dev 2008-03-12 17:54:48 UTC
Emacs team is out of here...
Comment 34 Pierre-Yves Rofes (RETIRED) gentoo-dev 2009-02-23 22:25:51 UTC
any reason to keep this open? this is probably covered with GLSA 200902-06 anyway...
Comment 35 Ulrich Müller gentoo-dev 2009-02-23 22:53:19 UTC
> any reason to keep this open? this is probably covered with GLSA 200902-06
> anyway...

For GNU Emacs, GLSA 200712-03 covered it.
For XEmacs, see comment #32.
Comment 36 Ulrich Müller gentoo-dev 2011-05-18 19:18:16 UTC
Could this bug be closed please? Or are you waiting for it to die of old age? ;)