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.
Could this bug be closed please? Or are you waiting for it to die of old age? ;)
