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

  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.

Remove the ENABLE_SECURE gate from the IS_PATH_WITH_DIR check so it
applies to all binaries, not just SUID/SGID ones, and extend it to
also reject the bare ".." entry which contains no directory separator
but still names the parent directory.

Add tst-gettext-path-traversal to verify that locale names containing
path separators or equal to ".." are rejected by the LANGUAGE processing loop.

This fixes bug 17142 and CVE-2026-84243.

Suggested-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
---
Changes from v5:
- Removed the bare '.' rejection, LANGUAGE=. entry simply
  resolves to the bound directory itself and poses no traversal
  risk, so filtering it is unnecessary.
- Reworded NEWS entry.

Even I was not sure about the ".", thank you for clarifying.

 NEWS                              |  4 +-
 intl/Makefile                     |  4 ++
 intl/dcigettext.c                 |  8 +--
 intl/tst-gettext-path-traversal.c | 83 +++++++++++++++++++++++++++++++
 4 files changed, 94 insertions(+), 5 deletions(-)
 create mode 100644 intl/tst-gettext-path-traversal.c
  

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.

I therefore object to applying this patch *now*.

Instead, what I would propose is:
  1. to implement the NLSPATH search in GNU gettext's libintl and in
     glibc/intl/ (likely first in GNU gettext, since bugs in the first
     implementation would have less impact than in glibc).
  2. Then only, apply your patch that restricts the value of LANGUAGE.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/gettext.html
  

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 therefore object to applying this patch *now*.
> 
> Instead, what I would propose is:
>   1. to implement the NLSPATH search in GNU gettext's libintl and in
>      glibc/intl/ (likely first in GNU gettext, since bugs in the first
>      implementation would have less impact than in glibc).
>   2. Then only, apply your patch that restricts the value of LANGUAGE.
> 
> Bruno
> 
> [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/gettext.html
  

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.
  

Adhemerval Zanella Netto wrote:
> 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

Avinal, can you please share why you think this is a *security* issue, and
what is the attack scenario?

  * I claim that any attacker who can set environment variables on a user can
    do any malicious actions on that user:
      - Set PATH, and some programs get executed that the user did not intend.
      - Set LD_LIBRARY_PATH, and some libraries get executed that the user
        did not intend.
      - Set NLSPATH or LANGUAGE, and non-SUID programs will get .cat or .mo
        files that the user did not intend.
    But you certainly don't want to disable PATH or LD_LIBRARY_PATH lookups
    in glibc, nor the NLSPATH lookup that glibc already does for catgets.

  * In your mail from 2006-09-01
    https://inbox.sourceware.org/libc-alpha/20260901133902.184341-1-avinal.xlvii@gmail.com/
    the described attack is "set LANGUAGE (e.g. via SSH AcceptEnv)".
    But
      - The documentation of SSH AcceptEnv is clear that is it dangerous:
        https://man7.org/linux/man-pages/man5/sshd_config.5.html
          "Be warned that some environment variables could be used to
           bypass restricted user environments.  For this reason,
           care should be taken in the use of this directive."
      - On GitHub one finds some people who add LANGUAGE to AcceptEnv :
        https://github.com/search?q=%2FAcceptEnv+.*LANGUAGE%2F&type=code
        But on GitHub you also find some people who add LD_LIBRARY_PATH
        to AcceptEnv:
        https://github.com/search?q=%2FAcceptEnv+.*LD_%2F&type=code
        By the same reasoning, you would need to forbid use of
        LD_LIBRARY_PATH in glibc.

  * CVE-2014-0475 = https://sourceware.org/bugzilla/show_bug.cgi?id=17137
    was fixed in 2015. Then in
    https://sourceware.org/bugzilla/show_bug.cgi?id=17142
    Florian Weimer wrote "the vectors known at the time did not apply to
    gettext".

  * In your mail from 2006-04-16 you did not give an attack scenario, just
    "it passes through and can make the catalog lookup traverse outside the
     intended locale directory."

  * Just because something is assigned a CVE, does not mean it is a security
    issue. Anyone can register CVEs.

> Also, this make backporting way more complex.

Well, before deciding about backporting, I guess we should first agree on
whether it a security issue at all?

Bruno
  

Adhemerval Zanella Netto wrote:
> 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).

Let me clarify on this topic, since it is apparently not well documented.

  Q: Can malicious .mo files crash a program?
  A: Yes. This can happen in two ways:

       - If an offset in the .mo file is out-of-range, _nl_find_msg in
         glibc/intl/dcigettext.c will do an out-of-range memory access.

       - Consider an msgid that is a format string that has N argument-
         consuming format directives. Usually the *printf invocation
         in the program passes exactly N arguments. If the translation
         is a format string that consumes more than N arguments, the
         *printf invocation encounters undefined behaviour and is likely
         to crash.
         (Note that this is a property of *printf, as available in C/C++/ObjC.
         In many other programming languages, the string formatting
         facility fails in a controlled way if passed too few arguments.)

  Q: Can glibc harden the .mo file handling, so that malicious .mo files
     can no longer crash a program?
  A: No. While glibc can protect against dereferencing out-of-range offsets,
     it can not do anything regarding the *printf invocation (because
     gettext() does not receive the information about the expected number
     of argument-consuming format directives).

  Q: Can .mo files shipped in a distribution crash the programs, and if not,
     why not?
  A: No, they cannot, because the .mo files are
       - created through "msgmerge" followed by "msgfmt -c", which avoids
         both of the dangers mentioned above,
       - installed in a read-only location (under /usr/share/locale/).

  Q: Are .mo files generally trusted to not crash the program?
  A: Yes, if they were created through "msgmerge" followed by "msgfmt -c".
     'msgfmt -c' rejects translations that are marked as c-format but don't
     have matching format string directives. 'msgmerge' makes sure that
     a malicious translator cannot circumvent this by removing the 'c-format'
     flag on a translation.

  Q: Are PO files from the translators trusted to not crash the program?
  A: No. Translators may translate format strings incorrectly, or may
     remove 'c-format' flags. It is the job of "msgmerge" and "msgfmt -c"
     to eliminate these possibilities.

  Q: Can PO files from the translators be malicious in other ways?
  A: Yes. There have been cases of translators submitting PO files full
     of swear words. Protections against such scenarios are not in place
     so far.

Bruno
  

On 14/09/26 12:02, Bruno Haible wrote:
> Adhemerval Zanella Netto wrote:
>> 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).
> 
> Let me clarify on this topic, since it is apparently not well documented.
> 
>   Q: Can malicious .mo files crash a program?
>   A: Yes. This can happen in two ways:
> 
>        - If an offset in the .mo file is out-of-range, _nl_find_msg in
>          glibc/intl/dcigettext.c will do an out-of-range memory access.

That was exactly what was brought in glibc-cna mail list, and we decided to
*not* handle corrupt .mo as security issue with the additional point:

  And I think it should be considered a missed robust check, since msgfmt 
  can not generate corrupt .mo files with the expected tooling.

The question is whether if it really worth to add extra hardening for this
case. From the test of this message, I would guess not.

> 
>        - Consider an msgid that is a format string that has N argument-
>          consuming format directives. Usually the *printf invocation
>          in the program passes exactly N arguments. If the translation
>          is a format string that consumes more than N arguments, the
>          *printf invocation encounters undefined behaviour and is likely
>          to crash.
>          (Note that this is a property of *printf, as available in C/C++/ObjC.
>          In many other programming languages, the string formatting
>          facility fails in a controlled way if passed too few arguments.)
> 
>   Q: Can glibc harden the .mo file handling, so that malicious .mo files
>      can no longer crash a program?
>   A: No. While glibc can protect against dereferencing out-of-range offsets,
>      it can not do anything regarding the *printf invocation (because
>      gettext() does not receive the information about the expected number
>      of argument-consuming format directives).
> 
>   Q: Can .mo files shipped in a distribution crash the programs, and if not,
>      why not?
>   A: No, they cannot, because the .mo files are
>        - created through "msgmerge" followed by "msgfmt -c", which avoids
>          both of the dangers mentioned above,
>        - installed in a read-only location (under /usr/share/locale/).
> 
>   Q: Are .mo files generally trusted to not crash the program?
>   A: Yes, if they were created through "msgmerge" followed by "msgfmt -c".
>      'msgfmt -c' rejects translations that are marked as c-format but don't
>      have matching format string directives. 'msgmerge' makes sure that
>      a malicious translator cannot circumvent this by removing the 'c-format'
>      flag on a translation.
> 
>   Q: Are PO files from the translators trusted to not crash the program?
>   A: No. Translators may translate format strings incorrectly, or may
>      remove 'c-format' flags. It is the job of "msgmerge" and "msgfmt -c"
>      to eliminate these possibilities.
> 
>   Q: Can PO files from the translators be malicious in other ways?
>   A: Yes. There have been cases of translators submitting PO files full
>      of swear words. Protections against such scenarios are not in place
>      so far.
> 
> Bruno
  

On Mon, Sep 14, 2026 at 7:54 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Adhemerval Zanella Netto wrote:
> > 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
>
Hello all, I was away for few weeks. Thank you Bruno for the detailed review.

> Avinal, can you please share why you think this is a *security* issue, and
> what is the attack scenario?
>
I will try to summarize the long discussions that led to the CVE assignment.

On local and ssh where an attack has full access, this would be
irrelevant. However on ssh sessions where ForceCommand is enforced
and/or LANGUAGE is added as AcceptEnv, this becomes relevant.

AcceptEnv is irrelevant to this attack. The attacker does not need the
server to accept LANGUAGE through SSH's environment mechanism. On a
default sshd with no AcceptEnv and no ForceCommand:

     $ ssh test@server LANGUAGE=../../../home/test/evil /bin/echo --help
       Aufruf: /bin/echo [KURZOPTION]... [ZEICHENKETTE]...
         oder: /bin/echo LANGOPTION
       Die HACKED auf die Standardausgabe

The remote shell interprets LANGUAGE=... as a variable assignment for
the command.  The only prerequisite is a .mo file placed somewhere
writable and basic SSH access. The mechanism by which a crafted file
is placed is beyond the scope of this weakness.

An crafted file can also be used to leak stack/heap addresses,
although in this particular case it cannot be used to bypass ASLR or
execute any real attack, but it is worth mentioning:
Example:

ssh -o SendEnv=LANGUAGE test@pisdr.neon-universe.ts.net
LANGUAGE=../../../home/test/evil /bin/ls /nonexistent
test@pisdr.neon-universe.ts.net's password:
ls: '/nonexistent' 0x74 0x1 (nil) (nil) 0x7fdbc5b320 0x556dead2b0
0x5598307b28 0x556dee1000 0x1 0x5598307b10: No such file or directory

>   * I claim that any attacker who can set environment variables on a user can
>     do any malicious actions on that user:
>       - Set PATH, and some programs get executed that the user did not intend.
>       - Set LD_LIBRARY_PATH, and some libraries get executed that the user
>         did not intend.
>       - Set NLSPATH or LANGUAGE, and non-SUID programs will get .cat or .mo
>         files that the user did not intend.
>     But you certainly don't want to disable PATH or LD_LIBRARY_PATH lookups
>     in glibc, nor the NLSPATH lookup that glibc already does for catgets.
>

glibc already considers this dangerous.  The code being patched contains:

       if (ENABLE_SECURE && IS_PATH_WITH_DIR (single_locale))
           continue;

So traversal in LANGUAGE is already blocked for SUID/SGID binaries.
The patch removes the ENABLE_SECURE gate and adds bare "..", it
extends an existing restriction, it does not introduce a new one.

Similarly, both LOCPATH and NLSPATH are in UNSECURE_ENVVARS
(sysdeps/generic/unsecvars.h). glibc position is already that
environment variables controlling file-loading paths are
security-relevant.

As per docs and for intended usecases LANGUAGE is described as
colan-separated identifiers, not a path mechanism, I would consider
current behavior as a gap that happens to be useful for some tasks.

>   * In your mail from 2006-09-01
>     https://inbox.sourceware.org/libc-alpha/20260901133902.184341-1-avinal.xlvii@gmail.com/
>     the described attack is "set LANGUAGE (e.g. via SSH AcceptEnv)".
>     But
>       - The documentation of SSH AcceptEnv is clear that is it dangerous:
>         https://man7.org/linux/man-pages/man5/sshd_config.5.html
>           "Be warned that some environment variables could be used to
>            bypass restricted user environments.  For this reason,
>            care should be taken in the use of this directive."
>       - On GitHub one finds some people who add LANGUAGE to AcceptEnv :
>         https://github.com/search?q=%2FAcceptEnv+.*LANGUAGE%2F&type=code
>         But on GitHub you also find some people who add LD_LIBRARY_PATH
>         to AcceptEnv:
>         https://github.com/search?q=%2FAcceptEnv+.*LD_%2F&type=code
>         By the same reasoning, you would need to forbid use of
>         LD_LIBRARY_PATH in glibc.

As I established earlier, AcceptEnv is irrelevant to this weakness.
Also this patch wouldn't restrict normal LANGUAGE usage.Uses can still
place their own catalog in the required directory and set LANGUAGE var
to point to it.

For the immutable distros, I believe the LANGUAGE traversal is a
fragile mechanism for custom catalogs, it requires knowing directory
depth, and most people who develop using immutable distros use toolbx
or something similar anyway for getting a mutable env.
>
>   * CVE-2014-0475 = https://sourceware.org/bugzilla/show_bug.cgi?id=17137
>     was fixed in 2015. Then in
>     https://sourceware.org/bugzilla/show_bug.cgi?id=17142
>     Florian Weimer wrote "the vectors known at the time did not apply to
>     gettext".
>

At the time the bug was opened, the known vectors indeed did not
apply. Since then, vectors have been demonstrated.

I agree (and Adhemerval stated too) that NLSPATH would be the proper
solution, and I am happy to work on it as a followup. For now I would
not like it to block a security fix.

>   * In your mail from 2006-04-16 you did not give an attack scenario, just
>     "it passes through and can make the catalog lookup traverse outside the
>      intended locale directory."
>
>   * Just because something is assigned a CVE, does not mean it is a security
>     issue. Anyone can register CVEs.
>
> > Also, this make backporting way more complex.
>
> Well, before deciding about backporting, I guess we should first agree on
> whether it a security issue at all?
>
> Bruno
>

The CVE was only assigned after a long discussion with the glibc
security team, when proper mechanisms and vectors were produced. I
accept that the details in my patch might be lacking some information.
I will update it to include more info.

Thank you
- Avinal