Bug#408929: emacs21 crash on spam
Joey if you could allocate a CVE ID I'll handle an upload for Etch. Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: emacs21 crash on spam
Steve Kemp wrote: Joey if you could allocate a CVE ID I'll handle an upload for Etch. Please use CVE-2007-2833. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: Fwd: Processed: Re: Bug#408929: emacs21: crash on spam
* Moritz Muehlenhoff: glibc 2.3.4 introduced more secure heap management, which renders several code injection attacks moot. I think these additional checks have already been bypassed. Shall I dig up a reference? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: Fwd: Processed: Re: Bug#408929: emacs21: crash on spam
Steve Langasek [EMAIL PROTECTED] writes: So if there's no evidence of arbitrary code execution, I think it's appropriate here to downgrade the bug -- but the security team should also be apprised. Fine with me. -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: emacs21: crash on spam
On Sun, Feb 04, 2007 at 01:12:21PM +0100, Romain Francoise wrote: reassign 408929 emacs21 tags 408929 patch quit This is a known bug in the way Emacs computes the size of some GIF images; the attached patch (adapted from a similar change in CVS) fixes the crash for me. Ok, thanks for the quick fix. I've tagged this bug security, because it wasn't clear to me whether this was a potentially exploitable problem. Do you think that tag applies here? If not, I think the bug should be downgraded. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: emacs21: crash on spam
reassign 408929 emacs21 tags 408929 patch quit This is a known bug in the way Emacs computes the size of some GIF images; the attached patch (adapted from a similar change in CVS) fixes the crash for me. Thanks, -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- --- emacs21-21.4a+1.orig/src/xfns.c +++ emacs21-21.4a+1/src/xfns.c @@ -9805,8 +9805,17 @@ return 0; } - width = img-width = max (gif-SWidth, gif-Image.Left + gif-Image.Width); - height = img-height = max (gif-SHeight, gif-Image.Top + gif-Image.Height); + image_top = gif-SavedImages[ino].ImageDesc.Top; + image_left = gif-SavedImages[ino].ImageDesc.Left; + image_width = gif-SavedImages[ino].ImageDesc.Width; + image_height = gif-SavedImages[ino].ImageDesc.Height; + + width = img-width = max (gif-SWidth, + max (gif-Image.Left + gif-Image.Width, + image_left + image_width)); + height = img-height = max (gif-SHeight, + max (gif-Image.Top + gif-Image.Height, + image_top + image_height)); /* Create the X image and pixmap. */ if (!x_create_x_image_and_pixmap (f, width, height, 0, ximg, img-pixmap)) @@ -9839,11 +9848,6 @@ requires more than can be done here (see the gif89 spec, disposal methods). Let's simply assume that the part not covered by a sub-image is in the frame's background color. */ - image_top = gif-SavedImages[ino].ImageDesc.Top; - image_left = gif-SavedImages[ino].ImageDesc.Left; - image_width = gif-SavedImages[ino].ImageDesc.Width; - image_height = gif-SavedImages[ino].ImageDesc.Height; - for (y = 0; y image_top; ++y) for (x = 0; x width; ++x) XPutPixel (ximg, x, y, FRAME_BACKGROUND_PIXEL (f));
Bug#408929: emacs21: crash on spam
Steve Langasek [EMAIL PROTECTED] writes: I've tagged this bug security, because it wasn't clear to me whether this was a potentially exploitable problem. Do you think that tag applies here? Yes, I think it does. Crashing Emacs is a denial of service attack against the various applications that run inside it, and can cause data loss... Whether code execution is actually possible, I don't know. (On the other hand, VM should not display images by default, but that is a separate issue.) -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: Fwd: Processed: Re: Bug#408929: emacs21: crash on spam
severity 408929 important thanks On Sun, Feb 04, 2007 at 01:56:40PM +0100, Jérôme Marant wrote: I'll ask that we tag this bug as etch-ignore: there are tons of bugs like this one in Emacs and there are multiple chances to expose such bugs by using many different packages. Futhermore, emacs21 is (and more generally stable emacs releases are) not supported upstream so we have no chances to get help from them (they are preparing the next release BTW). This last is certainly not a reason to etch-ignore a bug; on the contrary, it speaks to the overall releasability of the package if neither upstream nor the maintainers are prepared to cope with possible security bugs that are uncovered in the version releasing with etch. However, the current argument in favor of treating this as a grave, security bug is that it's a DoS causing data loss of unsaved files: On Sun, Feb 04, 2007 at 02:38:39PM +0100, Romain Francoise wrote: Steve Langasek [EMAIL PROTECTED] writes: I've tagged this bug security, because it wasn't clear to me whether this was a potentially exploitable problem. Do you think that tag applies here? Yes, I think it does. Crashing Emacs is a denial of service attack against the various applications that run inside it, and can cause data loss... Whether code execution is actually possible, I don't know. DoSes, while security bugs, are not treated as grave security bugs; that severity is reserved for bugs that allow code execution under the attacker's control. And data loss because you didn't save before the application crashed is not the sense in which data loss is taken to mean in the policy definition of grave bugs -- the data loss argument is reserved for bugs that eat your data directly, not as a side effect of you not having saved your data. So if there's no evidence of arbitrary code execution, I think it's appropriate here to downgrade the bug -- but the security team should also be apprised. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#408929: Fwd: Processed: Re: Bug#408929: emacs21: crash on spam
Steve Langasek wrote: So if there's no evidence of arbitrary code execution, I think it's appropriate here to downgrade the bug -- but the security team should also be apprised. glibc 2.3.4 introduced more secure heap management, which renders several code injection attacks moot. (most notably double frees) The message that was posted in the bug report appears to trigger such a sanity check. But it might be possible that smarter attacks might circumvent the glibc checks in the future, so we should err on the safe side and apply Romain's patch. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408929: emacs21: crash on spam
Package: emacs21 Version: 21.4a+1-3 Severity: critical The spam email appended below causes emacs to crash with *** glibc detected *** free(): invalid next size (normal): 0x08706488 *** Fatal error (6). or even simply with Fatal error (11).Segmentation fault To reproduce: start emacs with emacs -q --no-site-file inside emacs, evaluate (setq load-path (nconc load-path (list /usr/share/emacs21/site-lisp/vm))) (autoload 'vm-mode vm Run VM major mode on a buffer t) then visit the file spam-bug do M-x vm-mode --everything fine up to here-- hit space -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages emacs21 depends on: ii emacs21-bin-common21.4a+1-3 The GNU Emacs editor's shared, arc ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libncurses5 5.5-5 Shared libraries for terminal hand ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libsm61:1.0.1-3 X11 Session Management library ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra ii libungif4g4.1.4-4shared library for GIF images ii libx11-6 2:1.0.3-4 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii xaw3dg1.5+E-14 Xaw3d widget set ii zlib1g1:1.2.3-13 compression library - runtime emacs21 recommends no packages. Package: vm Version: 7.19-11 Versions of packages vm depends on: ii emacs21 21.4a+1-3 The GNU Emacs editor ii ucf 2.0018.1 Update Configuration File: preserv Versions of packages vm recommends: ii make 3.81-2 The GNU version of the make util -- no debconf information Here is the problematic spam: spam-bug Description: Binary data
