security of .mo files

Bruno Haible bruno@clisp.org
Mon Sep 14 15:02:24 GMT 2026


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





More information about the Libc-alpha mailing list