[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] intl: Proof against invalid offset/length

From: Bruno Haible
Subject: Re: [bug-gettext] intl: Proof against invalid offset/length
Date: Thu, 12 Mar 2015 02:04:25 +0100
User-agent: KMail/4.8.5 (Linux/3.2.0-64-generic; KDE/4.8.5; x86_64; ; )

Carlos O'Donell wrote:
> The MO files are writable only by root, so it's not a security issue
> because if you could write to them you'd be root, and you'd have
> full access to the system anyway.

Your argument is similar to Ulrich Drepper's argument: MO files are part
of the distribution of a package, like executables and shared libraries.
glibc does not check against invalid offsets in shared libraries either,
and the kernel does not check against illegal instructions that happen
to exist in executables and shared libraries.

But these arguments don't consider the LANGUAGE variable. The original
intent of LANGUAGE was that it contains colon-separated language or locale
identifiers. But in fact, you can specify relative files names that start
with "../", and thus you can make the _nl_load_domain function in glibc
access files anywhere in the file system. For example:

$ LANGUAGE=../../../../../../../../../../../../../../tmp/hack/crashing-mos 
strace cp . .
 O_RDONLY) = -1 ENOENT (No such file or directory)
 O_RDONLY) = -1 ENOENT (No such file or directory)
If I had put a hacked .mo file at 
I would have crashed the 'cp' program from coreutils. Likewise with
any program from any package.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]