[Bug libc/18913] New: catopen: integer overflows and out of bounds access

["tobias at stoeckmann dot org" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 18913
           Summary: catopen: integer overflows and out of bounds access
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: tobias at stoeckmann dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 8573
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8573&action=edit
unified diff

There are multiple integer overflow and out of bounds access issues
in __open_catalog. I highly doubt that they could be used to attack
a system properly, because NLSPATH is removed for setuid binaries.
Still, these problems should be fixed.

Please see my attached diff and this explanation. For experimentation,
please also look at the attached proof of concept message file, which
leads to a segmentation fault due to these issues:


First block:

Verify that file is not larger than size_t limitations, because the code
expects to load the whole file at once -- either through mmap or malloc.
4 GB should be way enough for all systems, anyway...

Second block:

Fixed a typo, "a reasonable" instead of "an reasonable"

Third block:

If the file is invalid, later code parts jump to invalid_file, but just
as the previous comment stated (see second block), errno is not properly
set. Without setting it to EINVAL, it could happen that -1 is returned,
but errno states "Success".

Fourth block:

The values for plane_size and plane_depth are read without validation
from file. They basically specify the size of the pointer table inside
the file (see tab_size calculation). At this stage, make sure that
"3 * plane_size * plane_depth * 2 * sizeof(u_int32_t)" won't result in
an integer overflow. Explanation: We have 2 pointer tables, each
table holds 3 u_int32_t values for plane_size * plane_depth entries.

Also, make sure that plane_size is not 0. It is used in a modulo (%)
expression in catgets().

Fifth block:

Actually check if the file is large enough to hold these values. The
previous check only verified that the result can be kept in size_t.

Sixth block:

The current check is incomplete, because it does not properly take
sizeof(u_int32_t) into account. "2 * tab_size" is supposed to specify
the size of the two pointer tables, but in fact it only specifies the
amount of indices. While at it, make sure that addition of max_offset
won't result in an integer overflow.

Seventh block:

The calculation of max_offset is wrong. It does not take sizeof(u_int32_t)
into account (see sixth block), but even adds tab size and max offset,
instead of subtracting them from st.st_size. Therefore, the check for the
last '\0' termination of the contained strings can easily result in
a read overflow.


PS: Is there a good way to check for overflows in arithmetic expressions
inside glibc infrastructure? I doubt that gcc-specific macros are
acceptable.

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