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

[Avinal Kumar]

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