Bug#417789: fixed in elinks 0.11.1-1.4

[Arnaud Giersch]

Vendredi 04 mai 2007, vers 09:57:07 (+0200), Kalle Olavi Niemitalo a
écrit :

* Don't look for gettext message catalogs in ../po/ (closes: #417789).
  Thanks, Arnaud Giersch! Reference: CVE-2007-2027.

 A less paranoid fix has been checked in to elinks-0.11 and
 elinks-0.12 in Git.  If you want to review it, now is the time.

 http://pasky.or.cz/gitweb.cgi?p=elinks.git;a=commit;h=928f364ba2803f98d71775dc03b694d6403c0754
 http://pasky.or.cz/gitweb.cgi?p=elinks.git;a=commit;h=110c564af3c12f40743b7e1adcfd3a034d73b601

Hi,

I don't believe that this patch really solves the security issue.  An
user may still be vulnerable if he wants to run his freshly compiled
(but not installed now) elinks.  This user would typically run it as
/path/to/elinks/src/elinks.  If his cwd is not in the elinks sources,
a wrong gettext catalog may be opened.

I however agree that the risk is pretty low.  I was personally more
concerned by autofs failing to mount /home/po/ each time I ran elinks
from my home directory.

I understand that it is an important feature for translators.  IMHO, a
suitable solution can be :

* enabling this code with --enable-debug like you apparently thought
  about ;

* removing the hard-coded ../po/ path, and letting the user specify
  his preferred path, either with a command line option, or with some
  environment variable.

Regards,
Arnaud Giersch

Bug#417789: fixed in elinks 0.11.1-1.4

[Arnaud Giersch]

Samedi 05 mai 2007, vers 22:14:33 (+0200), Kalle Olavi Niemitalo a
écrit :

 Thank you for your concern.  The patched ELinks 0.12.GIT
 (d1fa336f7f390d9b51456498fac5dda8f54c18a4) appears to open the
 correct gettext catalog in this case, regardless of what the
 current working directory is.  Please see the GDB session below.

[...]

 (gdb) print *str
 $7 = {magic = 7, source = 0x81c3550 
 /home/Kalle/build/i686-pc-linux-gnu/elinks-0.12/src/../po/fi_FI.UTF-8.gmo,
   length = 73}

You are right.  I missed the fact that ../po/ was appended to the
path to the binary, and not relative to the current working directory.

The only way to abuse this functionality that I can see now is the
improbable situation where the binary is run from some directory that
is not in the source tree, but whose name ends with src.

Arnaud

Bug#417789: this doesn't seem like a security issue

[Arnaud Giersch]

On Wed, Apr 04, 2007 at 08:04:52PM +0300, Eddy Petri\u0219or wrote:

  I tagged this bug as grave+security because it can be used to make
  elinks load any corrupted file, and possibly execute arbitrary code.

 How? Those are only strings. Nothing is executed from po/mo/gmo files.

Beside the segfault that could potentially be exploited, as it was
already answered by Steve Langasek, I can see another attack vector.

Since the attacker has the full control of the gettext catalog, I
suspect that some sort of format string attack could be doable (I
haven't tried).

Arnaud


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417789: elinks: elinks uses untrusted gettext catalog

[Arnaud Giersch]

Package: elinks
Version: 0.11.1-1.2
Severity: grave
Tags: security, patch

Hi,

Elinks loads untrusted gettext catalog from the relative directory
../po/, and crashes (SIGSEGV) if the loaded file is corrupted.  You
can check by yourself with with the following commands:

$ mkdir -p /tmp/elinks/{run,po}
$ cp /usr/share/locale/fr/LC_MESSAGES/elinks.mo /tmp/elinks/po/fr.gmo
$ dd if=/dev/urandom of=/tmp/elinks/po/fr.gmo bs=1024 seek=1 count=200
$ cd /tmp/elinks/run

$ LANG=fr_FR strace -eopen -otrace elinks
[...]
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE) = 3
open(/usr/share/locale/locale.alias, O_RDONLY|O_LARGEFILE) = 3
open(../po/fr_FR.gmo, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or 
directory)
open(/usr/share/locale/fr_FR/LC_MESSAGES/messages.mo, O_RDONLY|O_LARGEFILE) = 
-1 ENOENT (No such file or directory)
open(../po/fr.gmo, O_RDONLY|O_LARGEFILE) = 3
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 29917 detached

A gdb backtrace is included at the end of the message.

I tagged this bug as grave+security because it can be used to make
elinks load any corrupted file, and possibly execute arbitrary code.

Imagine an evil user placing some specially crafted files in
/tmp/po/.  Then, another user (root for example) runs elinks from a
directory /tmp/foo/, and thus loads the bad file(s).

A quick grep for '\.\./po' in the elinks sources gives the culprit
function : add_filename_to_string() around line 216 of file
elinks-0.11.1/src/intl/gettext/loadmsgcat.c.

IMHO, changing this function to return NULL unconditionally should fix
the problem (I did not want to download all the build dependencies to
verify).

Regards,

Arnaud Giersch


$ gdb -q /usr/bin/elinks -c core
(no debugging symbols found)
Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libgnutls.so.13...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgnutls.so.13
Reading symbols from /usr/lib/liblua50.so.5.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/liblua50.so.5.0
Reading symbols from /usr/lib/liblualib50.so.5.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/liblualib50.so.5.0
Reading symbols from /lib/tls/i686/cmov/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /usr/lib/libperl.so.5.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libperl.so.5.8
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /usr/lib/libgpm.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgpm.so.1
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /usr/lib/libexpat.so.1...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libexpat.so.1
Reading symbols from /usr/lib/libgnutls-openssl.so.13...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgnutls-openssl.so.13
Reading symbols from /usr/lib/libtasn1.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libtasn1.so.3
Reading symbols from /usr/lib/libgcrypt.so.11...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgcrypt.so.11
Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgpg-error.so.0
Reading symbols from /lib/ld-linux.so.2...Reading symbols from 
/usr/lib/debug/lib/ld-2.3.6.so...(no debugging symbols found)...done.

(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
(no debugging symbols found)
Core was generated by `elinks'.
Program terminated with signal 11, Segmentation fault.
#0  0x0809da6c in _nl_find_msg ()
(gdb)  where
#0  0x0809da6c in _nl_find_msg ()
#1  0x0809f4fe in _nl_init_domain_conv ()
#2  0x0809fc28 in _nl_load_domain ()
#3  0x0809e896 in _nl_find_domain ()
#4  0x0809de99 in dcigettext__ ()
#5  0x0809d4c1 in dcgettext__ ()
#6  0x0809e8c2 in gettext__ ()
#7  0x080a356e in get_dyn_full_version ()
#8