9:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is there an established procedure for dealing with bugs like the
following? Is there an established for noticing & tracking security
issues?
I am unaware of any process for doing either. I happened to stumble
upon this one simply because it was visible without having to scroll
my browser window.)
Absent any instruction, I will file a high priority bug. (Is it
possible mark bugs as security-related in Tracker?)
- --- Vladimir
http://lwn.net/Articles/320484/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: GNU Emacs, XEmacs: Multiple vulnerabilities
Date: February 23, 2009
Bugs: #221197, #236498
ID: 200902-06
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Two vulnerabilities were found in GNU Emacs, possibly leading to
user-assisted execution of arbitrary code. One also affects edit-utils
in XEmacs.
Background
==========
GNU Emacs and XEmacs are highly extensible and customizable text
editors. edit-utils are miscellaneous extensions to XEmacs.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 app-editors/emacs < 22.2-r3 >= 22.2-r3
*>= 21.4-r17
< 19
2 app-xemacs/edit-utils < 2.39 >= 2.39
-------------------------------------------------------------------
2 affected packages on all of their supported architectures.
-------------------------------------------------------------------
Description
===========
Morten Welinder reports about GNU Emacs and edit-utils in XEmacs: By
shipping a .flc accompanying a source file (.c for example) and setting
font-lock-support-mode to fast-lock-mode in the source file through
local variables, any Lisp code in the .flc file is executed without
warning (CVE-2008-2142).
Romain Francoise reported a security risk in a feature of GNU Emacs
related to interacting with Python. The vulnerability arises because
Python, by default, prepends the current directory to the module search
path, allowing for arbitrary code execution when launched from a
specially crafted directory (CVE-2008-3949).
Impact
======
Remote attackers could entice a user to open a specially crafted file
in GNU Emacs, possibly leading to the execution of arbitrary Emacs Lisp
code or arbitrary Python code with the privileges of the user running
GNU Emacs or XEmacs.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All GNU Emacs users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-editors/emacs-22.2-r3"
All edit-utils users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-xemacs/edit-utils-2.39"
References
==========
[ 1 ] CVE-2008-2142
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2142
[ 2 ] CVE-2008-3949
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3949
- --
Vladimir G. Ivanovic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmnB4wACgkQtoykdjDhdFu4XACbBWK0IOolc4zzXyW43288rcQH
AXQAnAzQEwzjR1SGqMnUc5q96RqpuQCj
=YpdN
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:21 p.m.
On Thursday 26 February 2009, Vladimir G. Ivanovic wrote:
Absent any instruction, I will file a high priority bug. (Is it
possible mark bugs as security-related in Tracker?)
[...]
Morten Welinder reports about GNU Emacs and edit-utils in XEmacs: By
shipping a .flc accompanying a source file (.c for example) and setting
font-lock-support-mode to fast-lock-mode in the source file through
local variables, any Lisp code in the .flc file is executed without
warning (CVE-2008-2142).
This was already fixed in June, and the fix is included in edit-utils package
version 2.40 which is also in the latest sumo tarballs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
12:05 a.m.
Vladimir G. Ivanovic writes:
Is there an established procedure for dealing with bugs like the
following? Is there an established for noticing & tracking security
issues?
No and no. If somebody has time to fix such things, that would be
nice, but there are so many ways to get code executed in Emacsen I
shiver to think there's anybody out there who would refuse to use an
Emacs without a patch for this bug, but would use an Emacs with a
patch for it.
Before we go spending energy on alleged security bugs, we should think
more carefully about what we want our security posture to be. I note
that the Python developers eventually gave up on "restricted mode",
etc.
Absent any instruction, I will file a high priority bug. (Is it
possible mark bugs as security-related in Tracker?)
Yes, in the severity field, there's a "security" tag.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:28 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
on 02/26/2009 04:05 PM Stephen J. Turnbull said the following:
...but there are so many ways to get code executed in Emacsen I
shiver to think there's anybody out there who would refuse to use an
Emacs without a patch for this bug, but would use an Emacs with a
patch for it.
The issue, I believe, is the silent (i.e. inadvertent) execution of
code, say "rm -rf $HOME &".
Before we go spending energy on alleged security bugs, we should
think
more carefully about what we want our security posture to be. I note
that the Python developers eventually gave up on "restricted mode",
etc.
Agreed. I don't recall any such discussion, but maybe there has been.
- --- Vladimir
- --
Vladimir G. Ivanovic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmna+8ACgkQtoykdjDhdFtpOwCfSpEdPHnZ1wKC9vvOVEQBhijs
A1oAn0pRkrCoTtppUQISHXMdplzrOua3
=ediN
-----END PGP SIGNATURE-----
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:19 p.m.
Vladimir G. Ivanovic writes:
on 02/26/2009 04:05 PM Stephen J. Turnbull said the following:
> ...but there are so many ways to get code executed in Emacsen I
> shiver to think there's anybody out there who would refuse to use an
> Emacs without a patch for this bug, but would use an Emacs with a
> patch for it.
The issue, I believe, is the silent (i.e. inadvertent) execution of
code, say "rm -rf $HOME &".
Which can also be done through .vm, .gnus, .bbdb, and auto-autoloads
(to mention four possibilities right off the top of my head), all of
which are commonly installed in user directories. Worse yet, the very
person who reported this bug is personally responsible for
.emacs.desktop!! which is capable of evil in *any* directory, unlike
the dot-files which need to be in $HOME and auto-autoloads which need
to be on `load-path'.
> Before we go spending energy on alleged security bugs, we should
think
> more carefully about what we want our security posture to be. I note
> that the Python developers eventually gave up on "restricted mode",
> etc.
Agreed. I don't recall any such discussion, but maybe there has been.
No, there hasn't been any discussion here. There has been some work
done in GNU Emacs on improving security against file-local variables,
but an explicit `load' by a user-invoked mode is just undefendable as
far as I can see, unless we implement something like a restricted
execution mode.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:37 a.m.
Ar an séú lá is fiche de mí Feabhra, scríobh Vladimir G. Ivanovic:
Is there an established procedure for dealing with bugs like the
following?
I don’t think we’ve formalised anything. Posting a message to xemacs-review,
which doesn’t have public archives, has worked well in the past.
Is there an established for noticing & tracking security issues?
I am unaware of any process for doing either. I happened to stumble
upon this one simply because it was visible without having to scroll
my browser window.)
Absent any instruction, I will file a high priority bug. (Is it
possible mark bugs as security-related in Tracker?)
Don’t do that, the latest version (2.40) of the edit-utils package doesn’t
have the bug.
Package / Vulnerable /
Unaffected
[...]
2 app-xemacs/edit-utils < 2.39 >= 2.39
-------------------------------------------------------------------
2 affected packages on all of their supported architectures.
-------------------------------------------------------------------
Description
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, 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
5744
days inactive
5748
days old
5 comments
4 participants
participants (4)
-
Aidan Kehoe -
Stephen J. Turnbull -
Ville Skyttä -
Vladimir G. Ivanovic