public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/27471] New: GLIBC_TUNABLES aren't parsed properly in AT_SECURE binaries
@ 2021-02-26  1:08 maxkamper at outlook dot com
  2021-03-01  9:18 ` [Bug libc/27471] " siddhesh at sourceware dot org
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: maxkamper at outlook dot com @ 2021-02-26  1:08 UTC (permalink / raw)
  To: glibc-bugs

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

            Bug ID: 27471
           Summary: GLIBC_TUNABLES aren't parsed properly in AT_SECURE
                    binaries
           Product: glibc
           Version: 2.34
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: maxkamper at outlook dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

In AT_SECURE binaries, the parse_tunables() function in elf/dl-tunables.c will
not correctly read a tunable's name if it's preceded by one labelled
TUNABLE_SECLEVEL_SXID_ERASE.

In the worst case scenario an AT_SECURE binary may pass tunables labelled
TUNABLE_SECLEVEL_SXID_ERASE to child processes.


Here's an example:

$ GLIBC_TUNABLES=glibc.malloc.tcache_count=16 sudo -E env | grep TUNABLES       
GLIBC_TUNABLES=

$ GLIBC_TUNABLES=glibc.malloc.tcache_count=16:glibc.malloc.tcache_count=32 sudo
-E env | grep TUNABLES
GLIBC_TUNABLES=glibc.malloc.tcache_count=32

The 1st invocation of env via sudo attempts to use the
glibc.malloc.tcache_count tunable, which is labelled
TUNABLE_SECLEVEL_SXID_ERASE and therefore correctly ignored by sudo and erased
from its environment before invoking the env child process.

The 2nd invocation does the same thing, but includes another copy of the same
tunable. Although it is still correctly ignored by sudo, it is not erased from
the environment and subsequently passed to the env child process.

This example is benign but shows that TUNABLE_SECLEVEL_SXID_ERASE isn't
behaving correctly.


The following lines of parse_tunables() are always executed before its while
loop starts over:

if (p[len] == '\0')
    return;
else
    p += len + 1;

'p' is assumed to be a char*, currently pointing to the start of a tunable's
value string. 'len' is assumed to hold the length of said value string. In the
above examples, having processed the 1st tunable, p is expected to point to the
string "16" and len is assumed to be 2.

If the tunable wasn't labelled TUNABLE_SECLEVEL_SXID_ERASE then these
assumptions would be correct, the code above would adjust p to point at the
start of the next tunable's name and the while loop would start over, parsing
the next tunable.

However, tunables labelled TUNABLE_SECLEVEL_SXID_ERASE are erased by the
following code in the same function:

char *q = &p[len + 1];
p = name;
while (*q != '\0')
    *name++ = *q++;
name[0] = '\0';
len = 0;

Where "name" is a pointer to the start of the current tunable's name. When a
tunable is erased, the 'p' and 'len' variables differ from what they're
expected to be when the 1st code snippet is reached, resulting in p getting
incremented by the line:
p += len + 1;

In the 2nd example above, p ends up pointing to the 2nd character of the 2nd
tunable's name, losing the "g" in "glibc", so the tunable gets incorrectly read
as "libc.malloc.tcache_count=32". Non-existent tunables are ignored, so it
remains in the environment where it's subsequently passed to child processes,
despite the TUNABLE_SECLEVEL_SXID_ERASE label specifying that it shouldn't be.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-12-08  2:53 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26  1:08 [Bug libc/27471] New: GLIBC_TUNABLES aren't parsed properly in AT_SECURE binaries maxkamper at outlook dot com
2021-03-01  9:18 ` [Bug libc/27471] " siddhesh at sourceware dot org
2021-03-01 11:27 ` siddhesh at sourceware dot org
2021-03-01 14:21 ` siddhesh at sourceware dot org
2021-03-02  5:06 ` siddhesh at sourceware dot org
2021-03-02  5:16 ` maxkamper at outlook dot com
2021-12-08  2:53 ` siddhesh at sourceware dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).