[Bug libc/32094] New: _nl_find_msg bug in glibc

[Bug libc/32094] New: _nl_find_msg bug in glibc

[bsdhenrymartin at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32094

            Bug ID: 32094
           Summary: _nl_find_msg bug in glibc
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bsdhenrymartin at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Component

In glibc, the _nl_find_msg function in /intl/dcigettext.c

OS

    Linux henry 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul
30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

glibc version

    GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3.8) stable release version 2.35.
    Copyright (C) 2022 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.
    There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
    PARTICULAR PURPOSE.
    Compiled by GNU CC version 11.4.0.
    libc ABIs: UNIQUE IFUNC ABSOLUTE

description

_nl_find_msg improperly handle a corrupted gtk30.mo file. This bug can be
triggered by modifying some bytes in gtk30.mo so that some program report
Segmentation fault (core dumped)， such as evince when I test this bug.
Actually, I find this bug belong to null pointer dereference.

analysis

_nl_find_msg 

     nls_uint32 nstr =
            W (domain->must_swap_hash_tab, domain->hash_tab[idx]);

The content pointed to by domain->hash_tab[idx] comes from the gtk30.mo file
(/usr/share/locale-langpack/en/LC_MESSAGES/gtk30.mo). We can modify the
corresponding bytes to control nstr. In my environment, the corresponding
location is at 0x33C, where four bytes are assigned to nstr.

          if (nstr < nstrings
              ? W (domain->must_swap, domain->orig_tab[nstr].length) >= len
                && (strcmp (msgid,
                            domain->data + W (domain->must_swap,
                                              domain->orig_tab[nstr].offset))
                    == 0)
              : domain->orig_sysdep_tab[nstr - nstrings].length > len
                && (strcmp (msgid,
                            domain->orig_sysdep_tab[nstr - nstrings].pointer)
                    == 0))

By setting nstr > nstrings, the program will execute
domain->orig_sysdep_tab[nstr - nstrings].length > len && (strcmp(msgid,
domain->orig_sysdep_tab[nstr - nstrings].pointer) == 0). However, through
debugging, I discovered that domain->orig_sysdep_tab usually is a null pointer,
which leads to an illegal memory access.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32094] _nl_find_msg bug in glibc

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32094

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
We don't consider this a security bug. Application data files, like ELF files,
localization files, and translation; are assumed trusted, meaning that while we
should not crash on invalid input, this does not cross a trust boundary.

Marking this security-

We also don't consider it a bug that invalid files cause a crash. There might
be an opportunity to harden the code, but not at the expense of valid correctly
formed installations and programs.

If you want to improve the hardening of this code please file a new bug and we
can discuss the improvements.

-- 
You are receiving this mail because:
You are on the CC list for the bug.