Bug 773023 (CVE-2012-0035)

Summary:	CVE-2012-0035 emacs: CEDET global-ede-mode file loading vulnerability
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	jonathan.underwood, loganjerry, rvokal, steve.traylen
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-10 21:39:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	773024, 773025
Bug Blocks:

Description Vincent Danen 2012-01-10 17:23:00 UTC

A flaw was found in EDE (part of CEDET, and included in emacs and xemacs in Fedora).  Quoting the report from emacs-devel [1]:


Hiroshi Oota has found a security flaw in EDE (part of CEDET), a
development tool included in Emacs.  EDE can store various information
about a project, such as how to build the project, in a file named
Project.ede in the project directory tree.  When the minor mode
`global-ede-mode' is enabled, visiting a file causes Emacs to look for
Project.ede in the file's directory or one of its parent directories.
If Project.ede is present, Emacs automatically reads and evaluates the
first Lisp expression in it.

This design exposes EDE users to the danger of loading malicious code
from one file (Project.ede), simply by visiting another file in the same
directory tree.


A patch for emacs 23.3 is attached to the initial report [1], and emacs 23.4 will be released to correct this flaw.

This has also been corrected upstream [2] in CEDET (which we do not ship on its own).

I am not 100% sure that this affects xemacs; there is the implication that it does as an upstream bug [3] was filed, however it is currently private so I cannot see the status of the report.

For Red Hat Enterprise Linux, the shipped versions of emacs do not include CEDET; it was merged into emacs with version 23.2 (RHEL6 has 23.1).

[1] http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00387.html
[2] http://cedet.bzr.sourceforge.net/bzr/cedet/code/trunk/revision/8114
[3] http://tracker.xemacs.org/XEmacs/its/issue825


Statement:

Not vulnerable. This issue did not affect the versions of emacs as shipped with Red Hat Enterprise Linux 4, 5 or 6 as they did not include support for CEDET.

Comment 1 Vincent Danen 2012-01-10 17:24:50 UTC

Created emacs tracking bugs for this issue

Affects: fedora-all [bug 773024]

Comment 2 Vincent Danen 2012-01-10 17:24:53 UTC

Created xemacs tracking bugs for this issue

Affects: fedora-all [bug 773025]

Comment 3 Steve Traylen 2012-01-12 12:49:51 UTC

For RHEL5 and 6 xemacs is within EPEL5 and 6  and this does contain:

/usr/share/xemacs/xemacs-packages/lisp/ede

so checking if its really not vulnerable. The package is very close to the fedora one so I expect so.

Steve.

Comment 4 Vincent Danen 2012-01-12 20:06:26 UTC

Oh, it most likely would affect xemacs in EPEL then, since it's pretty close to the version in Fedora.  Again, with the upstream xemacs bug being private, it's difficult to tell whether or not xemacs is affected at all (I suspect it is, but don't know for sure).  I can file an EPEL tracker for xemacs if you like (sorry, I completely missed it).

Comment 5 Fedora Update System 2012-01-23 21:57:18 UTC

emacs-23.3-8.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2012-01-23 21:57:52 UTC

emacs-23.3-9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Murray McAllister 2014-01-28 02:45:04 UTC

(In reply to Steve Traylen from comment #3)
> For RHEL5 and 6 xemacs is within EPEL5 and 6  and this does contain:
> 
> /usr/share/xemacs/xemacs-packages/lisp/ede
> 
> so checking if its really not vulnerable. The package is very close to the
> fedora one so I expect so.
> 
> Steve.

Hi Steve,

Did you find if xemacs in EPEL was vulnerable?

From a brief look at EPEL 6 it was missing some of the files the patch changes. Should I test further or you have already done that?

Thanks