This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [bug-gettext] intl: Proof against invalid offset/length
- From: Daiki Ueno <ueno at gnu dot org>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Bruno Haible <bruno at clisp dot org>, bug-gettext at gnu dot org, Jakub Wilk <jwilk at debian dot org>, libc-alpha at sourceware dot org
- Date: Fri, 20 Mar 2015 10:06:22 +0900
- Subject: Re: [bug-gettext] intl: Proof against invalid offset/length
- Authentication-results: sourceware.org; auth=none
- References: <m3oao06pj3 dot fsf-ueno at gnu dot org> <54FFE323 dot 4000704 at redhat dot com> <5962708 dot Sqr89sjBty at linuix dot haible dot de> <5502F437 dot 5060405 at redhat dot com> <5502F4C9 dot 8050304 at redhat dot com>
"Carlos O'Donell" <carlos@redhat.com> writes:
> On 03/13/2015 10:29 AM, Florian Weimer wrote:
>> On 03/12/2015 02:04 AM, Bruno Haible wrote:
>>
>>> 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.
>>
>> Yes, this is bug 17142.
>
> In my opinion we need to restrict LANGUAGE just like we restricted all
> other the other variables in CVE-2014-0475.
I agree. Now that intl/ is almost[1] synchronized with gettext, what's
blocking this? I'm happy to include the patch in the upcoming gettext
release so non-glibc consumers also benefit from it.
Footnotes:
[1] except a minor adjustment for non-glibc systems:
https://lists.gnu.org/archive/html/bug-gettext/2015-01/msg00029.html
and absolute pathname handling, which I guess could be reverted because
of not much use:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=279b57fc
Regards,
--
Daiki Ueno