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

[Bruno Haible]

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