[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in gettext
From: |
Bruno Haible |
Subject: |
Re: Bug in gettext |
Date: |
Fri, 18 May 2007 01:03:27 +0200 |
User-agent: |
KMail/1.5.4 |
Hello,
Victor Stinner wrote:
> I wrote a fuzzer and I use it on all Linux applications :-) Today I try it on
> gettext and I found a segfault (with invalid MO file). It occurs in
> intl/dcigettext.c in this test:
>
> /* Compare msgid with the original string at index nstr.
> We compare the lengths with >=, not ==, because plural entries
> are represented by strings with an embedded NUL. */
> if (nstr < nstrings
> ? W (domain->must_swap, domain->orig_tab[nstr].length) >= len
> && (strcmp (msgid,
> domain->data + W (domain->must_swap,
> domain->orig_tab[nstr].offset))
> == 0)
> : domain->orig_sysdep_tab[nstr - nstrings].length > len
> && (strcmp (msgid,
> domain->orig_sysdep_tab[nstr - nstrings].pointer)
> == 0))
> {
> act = nstr;
> goto found;
> }
>
> (WOW! Huge and ugly test :-D)
>
> I'm not sure about variable values but I guess:
> nstrings = 2
> len = 15
> nstr = 134545640 <= should be the source of the crash :-)
>
> So the problem is that the second option (domain->orig_sysdep_tab...) doesn't
> check higher limit :-/ (Is there an higher limit?)
>
> I attached my test program. Interresing files:
> gettext/hello.mo: original (valid) MO file
> gettext/locale/fr/LC_MESSAGES/hello.mo: fuzzed file
This is known: The gettext routines in GNU libc and GNU libintl don't
verify the integrity of .mo files. Just like neither libc nor the kernel
verify the integrity of executables or shared libraries.
Such a verification would not serve the purpose of a maximally efficient
lookup of translations.
It is the duty of the distribution or system manager to ensure that the
directories containing .mo files used by all users (/usr/share/locale
and its subdirectories) are not world- nor group- writable.
Bruno
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Bug in gettext,
Bruno Haible <=