[PATCH v6] intl: Restrict path traversal when using LANGUAGE env var [BZ #17142, CVE-2026-84243]

[Adhemerval Zanella Netto]

On 14/09/26 09:41, Adhemerval Zanella Netto wrote:
> 
> 
> On 10/09/26 12:45, Bruno Haible wrote:
>> Avinal Kumar wrote:
>>> The fix for CVE-2014-0475 (Bug 17137) added valid_locale_name() in
>>> locale/findlocale.c to reject locale names containing ".." path
>>> components.  However, the LANGUAGE environment variable processing in
>>> intl/dcigettext.c was not covered by that fix.  An attacker who can
>>> set LANGUAGE (e.g. via SSH AcceptEnv) can force any gettext-using
>>> program to load a crafted .mo file from an arbitrary filesystem
>>> location via directory traversal.
>>
>> This is intended, and it is a feature. Namely, it allows unprivileged users
>> to use their own message translation catalogs, for programs installed by the
>> distribution.
>>
>> Two use-cases for this exist:
>>
>>   a) Users who are not satisfied with the existing translation and want
>>      to add their own / modify an existing one, for their own use.
>>      This is the *freedom to localize*. GNU as an operating system that
>>      takes the user's freedom seriously should not take away this freedom.
>>
>>   b) Translators who want to try out their translation before submitting
>>      them upstream. For instance, the meaning of some messages depends
>>      upon which dialog they are located in — which is not visible from
>>      the PO files.
>>
>> The workaround for a user would be to use 'sudo' to add/overwrite a message
>> catalog under /usr/share/locale/, if they have the permissions. But AFAIU,
>> even this is not possible in "immutable" distros.
>>
>> POSIX [1] has specified another mechanism for this feature: The NLSPATH
>> environment variable. This other mechanism is currently not implemented
>> in GNU gettext's libintl, nor in glibc/intl/. Therefore, if your patch
>> was to be applied, users would lose a useful feature.
> 
> Right, but this requirement adds a quite large and complex new feature to
> a *security* issue. Avinal can give you more information, since he did the
> research for this bug, but this is very similar to CVE-2015-0475.
> 
> Also, this make backporting way more complex.  Even though glibc have supported
> <libintl.h> for long time, it would mean backport POSIX 2024 features.
I think another possibility would to harden .mo file handling, since we decided
not handle corrupt/invalid files as as a security issue (translation files are
considered to always come from a trusted source).

But I also see this as an orthogonal feature.