Bug 152898 - CAN-2005-0100 Emacs string format issue
Summary: CAN-2005-0100 Emacs string format issue
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: emacs
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact:
URL: https://rhn.redhat.com/errata/RHSA-20...
Whiteboard: 1, LEGACY, rh73, rh90
: 164471 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-10 18:58 UTC by Marc Deslauriers
Modified: 2007-04-18 17:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-05-13 00:51:09 UTC

Attachments (Terms of Use)
Possibly better emacs.spec file (30.48 KB, text/plain)
2006-03-14 21:55 UTC, David Eisenstein
no flags Details
Log-file of build on FC1 system of emacs-21.3-8.legacy.src.rpm (44.83 KB, text/plain)
2006-03-15 12:07 UTC, David Eisenstein
no flags Details
emacs.spec file for emacs-21.3-9.1.legacy; works (31.05 KB, text/plain)
2006-03-15 12:23 UTC, David Eisenstein
no flags Details
Corrected emacs.spec for FC1 (31.31 KB, text/plain; content-encoding: utf-8)
2006-03-16 05:40 UTC, David Eisenstein
no flags Details
Logfile from build of emacs-21.3-9.2.legacy on my FC1 machine. (61.83 KB, application/x-gzip)
2006-03-16 06:07 UTC, David Eisenstein
no flags Details

Description David Lawrence 2005-03-30 23:31:23 UTC
Max Vozeler discovered several format string vulnerabilities in the
movemail utility of Emacs. If a user connects to a malicious POP server, an
attacker can execute arbitrary code as the user running emacs. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name
CAN-2005-0100 to this issue.


------- Additional Comments From bishop@platypus.bc.ca 2005-02-28 23:30:05 ----

Marc, Jesse,

I see the patch.  It rolls cleanly on my RH9 chroot.  I can test the roll for
RH73 on a chroot too, if you want.  I cannot test the exploit, however.

It looks like the same patch went into this past month's release - character for
character - of emacs for RHEL2.1, 3 and just 4.  It's a one-line fix.

 - bish

------- Bug moved to this database by dkl@redhat.com 2005-03-30 18:31 -------

This bug previously known as bug 2422 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and Package request component.

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Marc Bejarano 2005-07-28 03:55:02 UTC
*** Bug 164471 has been marked as a duplicate of this bug. ***

Comment 3 Jesse Keating 2006-03-13 06:55:46 UTC
Hash: SHA1

Fixing emacs bug.


Used patches from RHEL4, FC2


ebcf4de9912221b01ead941fb0f522f4e2972b42  emacs/7.3/emacs-21.2-3.legacy.src.rpm
f20a97003cd04827fa0283bf404ad664c4ee0552  emacs/9/emacs-21.2-34.legacy.src.rpm
beaed519dad5eab0cba7f0b2ce20fe122a60f8c6  emacs/fc1/emacs-21.3-8.legacy.src.rpm
Version: GnuPG v1.2.6 (GNU/Linux)


Comment 4 Pekka Savola 2006-03-13 16:02:55 UTC
Hash: SHA1

QA w/ rpm-build-compare.sh:
 - source integrity good
 - spec file changes minimal, though maybe setarch stuff in fc1 didn't need
to change
 - patches verified to be based on RHEL3


f20a97003cd04827fa0283bf404ad664c4ee0552  emacs-21.2-34.legacy.src.rpm
ebcf4de9912221b01ead941fb0f522f4e2972b42  emacs-21.2-3.legacy.src.rpm
beaed519dad5eab0cba7f0b2ce20fe122a60f8c6  emacs-21.3-8.legacy.src.rpm
Version: GnuPG v1.0.7 (GNU/Linux)


Comment 5 Jesse Keating 2006-03-13 16:07:04 UTC
I had to change the setarch stuff, or else it wouldn't build in the build
system.  Lets just say that FC1's setarch is a little broken when being called
from the same arch.  *sigh*

I'll work up some packages for publish QA

Comment 6 David Eisenstein 2006-03-14 21:55:31 UTC
Created attachment 126123 [details]
Possibly better emacs.spec file

I wonder if just taking out the setarch stuff will break building emacs 
for FC1 when building for the X86_64 architecture?  Or when building it
on a true Fedora Core 1 system?

Therefore, I suggest we use the attached spec-file, which re-instates
the setarch stuff, but uses it only if setarch isn't broken in a given
invocation of rpmbuild.

The reason we want to do this is that we don't want to break the build
process for our end-users, in case they will want to rebuild emacs for
their own FC1 systems on an actual FC1 system.	We cannot expect our end-
users to be using mock under FC4.  This change is less invasive in that 
it makes it more likely end-users will be able to build it, based upon
the workaround needed for Bug #101818.

Comment 7 Jesse Keating 2006-03-14 21:58:32 UTC
I had tried the patch you sent to builders, but that failed to build.  We won't
be building it for x86_64, and if we were, setarch i386 on make doesn't seem
like it would make a x86_64 package, so that seems broken period.  For our end
users, they can always do 'setarch i386 rpmbuild ' and the whole process will be
of the right arch.

Comment 8 David Eisenstein 2006-03-14 22:45:08 UTC
Ah, I had an error in that patch.  Sorry.

1)  I thought we would be building *everything* for x86_64, including FC1.

2)  If setarch i386 in selected places in rpmbuild wouldn't build x86_64, 
    then where did 
    come from?

3)  Yes, we can let users do 'setarch i386 rpmbuild' -- but will that really 
    have the same effect that individual setarch statements inside the rpmbuild
    process have?

This probably isn't a big deal, but I guess I would feel remiss if I didn't
bring up my concerns.

Comment 9 Jesse Keating 2006-03-14 22:49:26 UTC
So the FC1 x86_64 was a port that was done after FC1 released.  A lot of the
srpms changed between the 32bit and the 64bit build.  It is entirely possible
that the srpm that was used for emacs on x86_64 has something different going on.

As far as x86_64 for everything, we've made the decision (based on user input on
list) to just go forward w/ FC3 for x86_64 stuff.

Comment 10 David Eisenstein 2006-03-15 12:07:11 UTC
Created attachment 126148 [details]
Log-file of build on FC1 system of emacs-21.3-8.legacy.src.rpm

Hash: SHA1

beaed519dad5eab0cba7f0b2ce20fe122a60f8c6  emacs-21.3-8.legacy.src.rpm

Attached is a log-file of a failed build of emacs-21.3-8.legacy.src.rpm
on my FC1 system, an AMD K6-2/500 (i586 compatible).  It fails in the same
way as the build did for the reporter in Bug 101818 (see attachment #93479 [details]
from that bug report) at exactly the same point.  The setarch workaround is
not present in the emacs.spec file in this source package.


Version: GnuPG v1.2.3 (GNU/Linux)


Comment 11 Jesse Keating 2006-03-15 12:11:02 UTC
and what if you do 'setarch i386 rpmbuild' ?

Comment 12 David Eisenstein 2006-03-15 12:23:06 UTC
Created attachment 126152 [details]
emacs.spec file for emacs-21.3-9.1.legacy; works

Hash: SHA1

Attached is a proposed emacs.spec file for emacs-21.3-9.1.legacy.  It super-
sedes the emacs.spec I submitted in comment 6, as that one was incorrect.
It includes conditional applications of the 'setarch' command to various
'make' commands both in the %build and in the %install sections of this

I have used this spec-file in combination with all the other source and
patches in Jesse's emacs-21.3-8.legacy.src.rpm to compile emacs successfully
both on my FC1 box (the AMD K6-2/500) and on petra.

4e2c4838c31a6b0de75ac4b29e9c77b5413baf69  emacs.spec

Version: GnuPG v1.2.3 (GNU/Linux)


Comment 13 David Eisenstein 2006-03-15 12:55:34 UTC
(In reply to comment #11)
> and what if you do 'setarch i386 rpmbuild' ?

I did not try that.  I imagine it would work.

To me, to require end-users to know that they have to type 
'setarch i386 rpmbuild <spec-file>' rather than 'rpmbuild <spec-file>'
to make it compile is not providing them with what they need.  Even if
the requirement to 'setarch i386 rpmbuild' is documented in the spec file
in the .src.rpm, someone could get bitten, and might not know where to look
to get it to build.  This is why I have put work into this.

Comment 14 David Eisenstein 2006-03-16 04:35:26 UTC
Jesse Keating and I discussed FC1 emacs on IRC, and we went over the spec file
posted in comment 12.  Although it worked to build FC1 emacs in both instances,
he pointed out some problems with it.  It had to do with awkward construction
of bash if and specfile %if statements surrounding the setarch problem and a
potential use of the setarch program without its being among the BuildRequres.

I am going to submit an updated spec file for FC1's emacs that should address
the shortcomings in the prior attempt, attachment 126152 [details].

Comment 15 David Eisenstein 2006-03-16 05:40:18 UTC
Created attachment 126195 [details]
Corrected emacs.spec for FC1

Hash: SHA1

Attached is an updated emacs.spec file, which hopefully will take care of
the issues.  It builds ok in all instances of its use to build FC1 emacs,
both on my FC1 machine and on petra.

(For petra's results, please see

It will build 'emacs-21.3-9.2.legacy' src.rpm and .rpms.

Please have a look at this and let us know what you think.  Thanks!


19e77f536025bbd7e610d2823d930c2e2e0a74d8  emacs.spec

Version: GnuPG v1.2.3 (GNU/Linux)


Comment 16 David Eisenstein 2006-03-16 06:07:16 UTC
Created attachment 126198 [details]
Logfile from build of emacs-21.3-9.2.legacy on my FC1 machine.

Attached, FYI, is the (gzipped) log-file from building emacs-21.3-9.2.legacy 
on my FC1 machine.

Comment 17 Pekka Savola 2006-03-17 06:20:54 UTC
The emacs spec file attached to #15 seems OK to me, though quite complex; can't
be avoided I fear..

I guess this can go to build stage with that modification, unless there are

Comment 18 David Eisenstein 2006-03-19 16:03:52 UTC
Hash: SHA1

I'll go ahead and make this official, unless anyone objects ...

Submitting these for PUBLISH QA.  The .src.rpm has the emacs.spec file
mentioned in comment #15.

The FC1 packages and log files that were made on petra are available at

Source RPM:

Binary RPMs:

The RPMs are also signed by my 0x7910794f gpg key (Legacy package signature

Version: GnuPG v1.2.3 (GNU/Linux)


Comment 19 David Eisenstein 2006-03-22 17:05:30 UTC
Pekkas, or someone, can you take a look at this one so it can be moved to 
updates-testing?  Jesse, maybe you could look at it and see if it is suitable?


Comment 20 Pekka Savola 2006-03-31 05:29:46 UTC
I think there has already been silent agreement that this is good to go..

Comment 21 David Eisenstein 2006-03-31 11:44:45 UTC
Thanks, Pekka.

Comment 22 David Eisenstein 2006-04-08 04:49:12 UTC
I have started a build for emacs-21.3-9.2.legacy on jane.  Job 76.  Once
it is built, then we should have all the packages built that need building
here, and they will need pushing to updates-testing.

Will you do that, Marc or Jesse?  Thanks.

Comment 23 David Eisenstein 2006-04-08 05:21:42 UTC
Oh, also built for RHL7.3 and RHL9.  So the packages ready to be pushed to
updates-testing are here on jane/turbosphere:



Comment 24 Marc Deslauriers 2006-04-27 00:01:05 UTC
Packages were pushed to updates-testing

Comment 25 Pekka Savola 2006-05-02 18:40:47 UTC
Timeout 2 weeks from packages being pushed to updates-testing.

Comment 26 Pekka Savola 2006-05-11 05:52:30 UTC
Timeout over.

Comment 27 Marc Deslauriers 2006-05-13 00:51:09 UTC
Packages were released to updates.

Note You need to log in before you can comment on or make changes to this bug.