Bugzilla Bug 200297

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

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?

> 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.

Adding Arch Security liaisons and Chris for RelEng.

Please test and mark stable (in CVS) the two Emacs ebuilds mentioned in comment
#1.

XEmacs is also affected, CCing graaff.

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.

Both stable for HPPA.

Just a quick note to mention that XEmacs 21.5 in the emacs overlay has now been
patched. 

  26 Nov 2007; Christian Faulhammer <opfer@gentoo.org>
  emacs-21.4-r14.ebuild, emacs-22.1-r3.ebuild:
  stable x86

(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.

> 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).

ppc64 stable

Add Raúl for alpha

ppc stable

  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).

amd64 has been done.

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.

(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.

(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.

CVE-2007-6109 was published today.
Could this bug be unrestricted then?

(In reply to comment #19)
> CVE-2007-6109 was published today.
> Could this bug be unrestricted then?

yes.

Missing keywords: "arm s390 sh"

GLSA 200712-03

(In reply to comment #20)
> Missing keywords: "arm s390 sh"

arm is done (already several days ago), thanks vapier.

(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

xemacs, please advise.

(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

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.

(In reply to comment #18)
> Please keyword/stabilise emacs-21.4-r14 for arm/s390/sh.

All done, removing remaining arches from CC.

So should I wait for Xemacs for release or am I good?  We do ship Xemacs on the
LiveDVD.

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.

Thanks...

Add us back if anything changes.

Hans, I had the understanding these LISP statements could be executed from
within documents opened in XEmacs. Is that wrong?

(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. 

Emacs team is out of here...

any reason to keep this open? this is probably covered with GLSA 200902-06
anyway...

> 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.