Bug#417789: fixed in elinks 0.11.1-1.4

2007-05-05 Thread 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

2007-05-05 Thread Kalle Olavi Niemitalo
Arnaud Giersch [EMAIL PROTECTED] writes:

 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.

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 --args ~/build/i686-pc-linux-gnu/elinks-0.12/src/elinks -no-connect
GNU gdb 6.5-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i486-linux-gnu...Using host libthread_db library 
/lib/tls/libthread_db.so.1.

(gdb) list /home/Kalle/src/elinks-0.12/src/intl/gettext/loadmsgcat.c:207,229
207 /* This is hacked for ELinks - we want to look up for the translations 
at the
208  * correct place even if we are being ran from the source/build tree. */
209 static struct string *
210 add_filename_to_string(struct string *str, struct loaded_l10nfile 
*domain_file)
211 {
212 unsigned char *slash = strrchr(program.path, '/');
213 size_t dirnamelen = (slash ? slash - program.path + 1 : 0);
214
215 /* Check if elinks is being run from the source tree. */
216 if (dirnamelen  4
217 || strncmp(program.path + dirnamelen - 4, src, 3))
218 return NULL;
219
220 if ((dirnamelen  !add_bytes_to_string(str, program.path, 
dirnamelen))
221 || !add_to_string(str, ../po/)
222 || !add_bytes_to_string(str,
223 (unsigned char *) 
domain_file-langdirname,
224 domain_file-langdirnamelen)
225 || !add_to_string(str, .gmo))
226 return NULL;
227
228 return str;
229 }
(gdb) break add_filename_to_string
Breakpoint 1 at 0x80c5453: file 
/home/Kalle/src/elinks-0.12/src/intl/gettext/loadmsgcat.c, line 212.
(gdb) run
Starting program: /home/Kalle/build/i686-pc-linux-gnu/elinks-0.12/src/elinks 
-no-connect
[Thread debugging using libthread_db enabled]
[New Thread -1216120064 (LWP 8749)]
[Switching to Thread -1216120064 (LWP 8749)]

Breakpoint 1, add_filename_to_string (str=0xbfbc844c, domain_file=0x819b820)
at /home/Kalle/src/elinks-0.12/src/intl/gettext/loadmsgcat.c:212
212 unsigned char *slash = strrchr(program.path, '/');
(gdb) print program.path
$1 = (unsigned char *) 0xbfbc942e 
/home/Kalle/build/i686-pc-linux-gnu/elinks-0.12/src/elinks
(gdb) next
213 size_t dirnamelen = (slash ? slash - program.path + 1 : 0);
(gdb) print slash
$2 = (unsigned char *) 0xbfbc9461 /elinks
(gdb) next
216 if (dirnamelen  4
(gdb) print dirnamelen
$3 = 52
(gdb) print program.path + dirnamelen - 4
$4 = (unsigned char *) 0xbfbc945e src/elinks
(gdb) next
220 if ((dirnamelen  !add_bytes_to_string(str, program.path, 
dirnamelen))
(gdb) print *str
$5 = {magic = 7, source = 0x81c3550 , length = 0}
(gdb) print domain_file-[EMAIL PROTECTED]langdirnamelen
$6 = fi_FI.UTF-8
(gdb) next
228 return str;
(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}
(gdb)


pgpDXgH1hGtaG.pgp
Description: PGP signature


Bug#417789: fixed in elinks 0.11.1-1.4

2007-05-05 Thread 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: fixed in elinks 0.11.1-1.4

2007-05-04 Thread Kalle Olavi Niemitalo
Julien Cristau [EMAIL PROTECTED] writes:

  elinks (0.11.1-1.4) unstable; urgency=high
  .
* Non-maintainer security upload.
* 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


pgpbYyZXLB179.pgp
Description: PGP signature