security of .mo files

[Adhemerval Zanella Netto]

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