Created attachment 589144 [details]
Patch for CVE-2014-3421

Upstream fix: http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00056.html

Link for patch CVE-2014-3421 is 
http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00055.html
not 
http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00056.html

Created attachment 589145 [details]
Patch for CVE-2014-3422

Upstream fix: http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00056.html

Created attachment 589147 [details]
Patch for CVE-2014-3423

Upstream note: http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00057.html

Created attachment 589149 [details]
Patch for CVE-2014-3424

Upstream fix: http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00060.html

Affected packages:

SLE-11-SP3: emacs
SLE-10-SP3-TERADATA: emacs
SLE-11-SP1: emacs
SLE-9-SP3-TERADATA: emacs

(In reply to comment #4)

This one is *not* a fix, it only adds a warning in the lips code as a comment!
Beside this nowadays there is no NCSA Mosaic in use I guess ... this was 1993 and the successor was the commercial Netscape.

(In reply to comment #6)

What is with openSUSE?

And do you have really checked the emacs source tar balls for SLES 11, 10, and 9 as the patches are for emacs-24?

The patch CVE-2014-3421.patch has folded lines included

Beside this the tabs had been converted into spaces

This isn't intended as a fix since it otherwise would break interaction with
Mosaic. I'm pretty sure that no one uses it anyways but it got a CVE assigned
so I wanted to document it as a bug. We can decide not to fix it.

SMASH only tracks SLES. I'm currently learning the process and it's my
understanding that openSUSE will be fixed after the submission for SLES is
coordinated via this bug.

I didn't check the tar balls since those vulnerabilities got introduced between
1990 and 2000 and weren't fixed since. It's likely that those packages are
affected.

I changed the heading of the bug to VUL-1 to indicate that a submission isn't 
immediately necessary.

Created attachment 589180 [details]
Patch for CVE-2014-3421

(In reply to comment #9)
They are already that way in the web interface to the mailing list. I fetched emacs trunk and extracted the patch from there.

bugbot adjusting priority

This is an autogenerated message for OBS integration:
This bug (876847) was mentioned in
https://build.opensuse.org/request/show/260690 13.1 / emacs

openSUSE-SU-2014:1460-1: An update that fixes four vulnerabilities is now available.

Category: security (moderate)
Bug References: 876847
CVE References: CVE-2014-3421,CVE-2014-3422,CVE-2014-3423,CVE-2014-3424
Sources used:
openSUSE 13.1 (src):    emacs-24.3-6.14.2

This one is fixed

(In reply to SMASH SMASH from comment #6)

> SLE-11-SP3: emacs
> SLE-10-SP3-TERADATA: emacs
> SLE-11-SP1: emacs
> SLE-9-SP3-TERADATA: emacs

On SLE-9-SP3-TERADATA only one patch does apply with

--- lisp/net/browse-url.el
+++ lisp/net/browse-url.el
          (kill-buffer nil)))
     (if (and pid (zerop (signal-process pid 0))) ; Mosaic running
        (save-excursion
+         ;; This is a predictable temp-file name, which is bad,
+         ;; but it is what Mosaic uses/used.
+         ;; So it's not Emacs's problem.  http://bugs.debian.org/747100
          (find-file (format "/tmp/Mosaic.%d" pid))
          (erase-buffer)
          (insert (if (browse-url-maybe-new-window new-window)

all other files do not exist on emacs emacs-21.3 (from 2003-03-18)

(In reply to Dr. Werner Fink from comment #17)

The same holds true for SUSE:SLE-10-SP3 as also emacs-21.3 (from 2003-03-18) is used.

(In reply to Dr. Werner Fink from comment #17)

Only SLES-11 the patches CVE-2014-3421.patch, CVE-2014-3422.patch, CVE-2014-3423.patch, and CVE-2014-3424.patch do apply partly.  Whereas patch CVE-2014-3423.patch is rather useless as a) the Mosaic is not in use anymore (had been Netscape an noadays Mozilla Firefoy are used) and b) the patch doe fix nothing.

Adding security team and Stefan to CC

In short: the patch CVE-2014-3423.patch does not fix anything but add a comment only as the API used for the old Mosaic browser was this way.

The other patches do not apply to emacs 21.3 nor is there any functionality in emacs 21.3 of SLES-9 and SLES-10 which are affected by the changes in the patches.

Remains only emacs 22.3 of SLES-11 which are partly affected.

For SLES-11-SP1 (which is also for SLES-11-SP3) SR #53574

For SLES-11-SP4 SR#53576

reassign to us for tracking. 

we might not start an update immediately.

SUSE-SU-2015:0834-1: An update that fixes four vulnerabilities is now available.

Category: security (low)
Bug References: 854683,876847
CVE References: CVE-2014-3421,CVE-2014-3422,CVE-2014-3423,CVE-2014-3424
Sources used:
SUSE Linux Enterprise Software Development Kit 11 SP3 (src):    emacs-22.3-4.42.1
SUSE Linux Enterprise Server 11 SP3 for VMware (src):    emacs-22.3-4.42.1
SUSE Linux Enterprise Server 11 SP3 (src):    emacs-22.3-4.42.1
SUSE Linux Enterprise Desktop 11 SP3 (src):    emacs-22.3-4.42.1

CVE-2014-3421: does  not affect SLES 10 or older, NOT affected

CVE-2014-3422: suspicious code is in SLES 10 , affected.

CVE-2014-3423: code is in there, affects SLES 10

CVE-2014-3424: code is not present in SLES 10 , NOT affected.

An update workflow for this issue was started.
This issue was rated as moderate.
Please submit fixed packages until 2015-11-18.
When done, reassign the bug to security-team@suse.de.
https://swamp.suse.de/webswamp/wf/62325

a/lisp/emacs-lisp/find-gc.el is only used at buildtime?

i see it gets installed in:
./usr/share/emacs/21.3/lisp/emacs-lisp/find-gc.el
but its hard for me to say where and what its used for.




As for Mosaic, can you just make the lisp construct error out or return empty?
(defun browse-url-mosaic (url &optional new-window) ... false ) or something.

In its current state it will still send SIGUSR1 from the emacs user to a PID if the macro is used, if the attacker touches /tmp/Mosaic.<PID>  or so, even without Mosaic present.

(In reply to Marcus Meissner from comment #37)

find Lisp functions from C source files which triggers a garbage collection.
No the fixed find-gc.el does also change the x11term.c and x11fns.c into xterm.c and xfns.c.  With this fix the emacs binary image which has to be dumped by temcas becomes larger.  The question rises if on IBS we have enough memory to do so.  I had tried ulimit -a ... but I see

  max memory size         (kbytes, -m) unlimited
  virtual memory          (kbytes, -v) 354822108

nevertheless if crashes.  Whereas a local build in a chroot autobuild environment with less memory does never crash.

How can I debug this?

For Mosaic you can not change the code as then Mosaic would not work.  But this does no matter or is there a usable ELF-binary of the Mosaic browser for current Linux available?

 https://en.wikipedia.org/wiki/Mosaic_(web_browser)
 ftp://ftp.ncsa.uiuc.edu/Web/Mosaic/
 ftp://ftp.ncsa.uiuc.edu/Web/Mosaic/Unix/binaries/2.7b/
 
I guess this is history.

Had used the gdb in build requires and tried to do a backtrace in batch mode:

[  106s] Wrote /usr/src/packages/BUILD/emacs-21.3/lib-src/fns-21.3.1.el
[  106s] Dumping under names emacs and emacs-21.3.1
[  106s] make[1]: *** [emacs] Segmentation fault (core dumped)
[  106s] make[1]: *** Deleting file `emacs'
[  106s] make[1]: Leaving directory `/usr/src/packages/BUILD/emacs-21.3/src'
[  106s] make: *** [src] Error 2
[  106s] ++ find -name core
[  106s] + core=./src/core
[  106s] + test -n ./src/core
[  106s] + gdb -batch -x bt ./src/temacs ./src/core
[  106s] Using host libthread_db library "/lib64/libthread_db.so.1".
[  106s] 
[  106s] warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffdd8f73000
[  106s] Core was generated by `./temacs -batch -l loadup dump'.
[  106s] Program terminated with signal 11, Segmentation fault.
[  106s] #0  0x00007f9a538f7787 in memcpy () from /lib64/libc.so.6
[  106s] + exit 1
[  106s] error: Bad exit status from /var/tmp/rpm-tmp.87720 (%build)
[  106s] 
[  106s]

Btw: sometimes it builds but in most case it does not

 Update/SLE-10-SP2> osc results 
 SUSE_SLE-10-SP2_Update_Test ia64       succeeded*
 SUSE_SLE-10-SP2_Update_Test ppc64      failed
 SUSE_SLE-10-SP2_Update_Test ppc        failed
 SUSE_SLE-10-SP2_Update_Test s390       succeeded*
 SUSE_SLE-10-SP2_Update_Test s390x      failed
 SUSE_SLE-10-SP2_Update_Test x86_64     failed
 SUSE_SLE-10-SP2_Update_Test i586       failed*
 SLE_10_SP2_Update    ia64       succeeded*
 SLE_10_SP2_Update    ppc64      succeeded*
 SLE_10_SP2_Update    ppc        failed
 SLE_10_SP2_Update    s390       failed
 SLE_10_SP2_Update    s390x      failed
 SLE_10_SP2_Update    x86_64     failed
 SLE_10_SP2_Update    i586       failed*

...

There is a patten ... crashes only on kernel > 3.0 and with systemd running, also core file siz is zero but as I had used ulimit -c unlimited for debugging I guess that this does not matter

foreach? foreach arch (ia64 ppc64 ppc s390 s390x x86_64 i586)
foreach? echo $platform $arch :
foreach? osc bl $platform $arch | grep -E ' (PID|Linux|core file size)'
foreach? end
foreach? end
SUSE_SLE-10-SP2_Update_Test ia64 :
[    8s] PID 1 is /sbin/init
[   96s] Linux thallium 3.0.101-63-default #1 SMP Tue Jun 23 16:02:31 UTC 2015 (4b89d0c) ia64 ia64 ia64 GNU/Linux
[  122s] core file size          (blocks, -c) 1
SUSE_SLE-10-SP2_Update_Test ppc64 :
[    3s] PID 1 is /sbin/init
[   33s] Linux foxberry-1 3.14.0-11.1-default #1 SMP Tue Apr 1 15:20:06 UTC 2014 (6623a43) ppc64 ppc64 ppc64 GNU/Linux
[   44s] core file size          (blocks, -c) unlimited
SUSE_SLE-10-SP2_Update_Test ppc :
[    8s] PID 1 is /sbin/init
[   74s] Linux mulberry-1 3.14.0-11.1-default #1 SMP Tue Apr 1 15:20:06 UTC 2014 (6623a43) ppc ppc ppc GNU/Linux
[   94s] core file size          (blocks, -c) unlimited
SUSE_SLE-10-SP2_Update_Test s390 :
[    5s] PID 1 is /sbin/init
[   35s] Linux s390lp6 3.0.101-0.47.55-default #1 SMP Thu May 28 08:25:11 UTC 2015 (dc083ee) s390 s390 s390 GNU/Linux
[   43s] core file size          (blocks, -c) 1
SUSE_SLE-10-SP2_Update_Test s390x :
[    3s] PID 1 is /usr/lib/systemd/systemd
[  258s] Linux s390p1 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0) s390x s390x s390x GNU/Linux
[  272s] core file size          (blocks, -c) 0
SUSE_SLE-10-SP2_Update_Test x86_64 :
[    6s] PID 1 is /usr/lib/systemd/systemd
[   87s] Linux mcbrain 3.12.25-2-default #1 SMP Mon Jul 28 12:18:48 UTC 2014 (1b84426) x86_64 x86_64 x86_64 GNU/Linux
[  115s] core file size          (blocks, -c) 0
SUSE_SLE-10-SP2_Update_Test i586 :
[    3s] PID 1 is /usr/lib/systemd/systemd
[   50s] Linux kemter 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0) i686 i686 i386 GNU/Linux
[   66s] core file size          (blocks, -c) 0
SLE_10_SP2_Update ia64 :
[   10s] PID 1 is /sbin/init
[   89s] Linux lutetium 3.0.101-63-default #1 SMP Tue Jun 23 16:02:31 UTC 2015 (4b89d0c) ia64 ia64 ia64 GNU/Linux
[  115s] core file size          (blocks, -c) 0
SLE_10_SP2_Update ppc64 :
[   10s] PID 1 is /sbin/init
[   47s] Linux sugarberry-2 3.0.76-0.7-ppc64 #1 SMP Fri May 10 12:13:21 UTC 2013 (11479d8) ppc64 ppc64 ppc64 GNU/Linux
[   59s] core file size          (blocks, -c) 1
SLE_10_SP2_Update ppc :
[    8s] PID 1 is /sbin/init
[   74s] Linux mulberry-1 3.14.0-11.1-default #1 SMP Tue Apr 1 15:20:06 UTC 2014 (6623a43) ppc ppc ppc GNU/Linux
[   92s] core file size          (blocks, -c) unlimited
SLE_10_SP2_Update s390 :
[    2s] PID 1 is /usr/lib/systemd/systemd
[   35s] Linux s390p3 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0) s390 s390 s390 GNU/Linux
[   42s] core file size          (blocks, -c) 0
SLE_10_SP2_Update s390x :
[    3s] PID 1 is /usr/lib/systemd/systemd
[   38s] Linux s390p3 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0) s390x s390x s390x GNU/Linux
[   45s] core file size          (blocks, -c) 0
SLE_10_SP2_Update x86_64 :
[    4s] PID 1 is /usr/lib/systemd/systemd
[   58s] Linux harrison 3.12.48-52.27-default #1 SMP Mon Oct 5 10:08:10 UTC 2015 (314f0e3) x86_64 x86_64 x86_64 GNU/Linux
[   76s] core file size          (blocks, -c) 0
SLE_10_SP2_Update i586 :
[    5s] PID 1 is /usr/lib/systemd/systemd
[   82s] Linux pawlow 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) i686 i686 i386 GNU/Linux
[  100s] core file size          (blocks, -c) 0

It becomes even more worse, now even if I disable the patch the emacs does not build with kernel version > 3.0

It seems that it crashes in unexec() used by temacs to do what the name says.
I've tried the unexelf.c from emacs-24.5, same result with the same pattern.

I have no idea what kernel(s) on OBS are used as with kernel version > 3.0 I would guess that it also may crash

Question:  Is there a know security feature of kernel > 3.0 which can cause. e.g. crashes if temacs tries to do an ``unexec'' aka to dumps its loaded binary image to a file?  AFAIK -pie and -fPIE/-fpie does not with emacs.

https://lists.gnu.org/archive/html/bug-gnu-emacs/2008-09/msg00439.html

OK ... now solved

but next problem is: on SLES10 we have an other page size default (4k) as on SLES11 nad up (64k)

How can we make sure that the correct kernel is used?



[   68s] + getconf PAGESIZE
[   68s] 65536

SR #81933 for SUSE:SLE-10-SP3:Update:Test

was released