6 ms·

Looking at the details here I have to say it sure looks like the glibc people were asking for trouble. GLIBC_TUNABLES is apparently an environment variable tha

Looking at the details here I have to say it sure looks like the glibc people were asking for trouble. GLIBC_TUNABLES is apparently an environment variable that lets you turn various performance knobs affecting glibc internals: https://www.gnu.org/software/libc/manual/html_node/Tunables.html https://www.gnu.org/software/libc/manual/html_node/Tunables.... OK, so obviously someone calling a SUID program shouldn't be able to set these options at all, right? So I guess the bug must be that they forgot to clear this env var when starting a suid program? Given that there have been so many vulnerabilities like this you'd think they would have really audited environment variable usage to avoid this but maybe it slipped through? ... NO WAIT! It's worse! They apparently intentionally allow some tunables to be tuned across a SUID boundary. Looking at the commit that is blamed for introducing this problem, it is explicitly dealing with the filter logic for tunables in SUID mode! https://patchwork.ozlabs.org/project/glibc/patch/20210316070755.330084-5-siddhesh@sourceware.org/ https://patchwork.ozlabs.org/project/glibc/patch/20210316070... But whyyyyyyy? Why not just ignore it altogether? Is the use case for tuning ultra-advanced performance settings across SUID so strong that it outweighs the obvious security risks? I mean, I'll admit, I've never seen this env var before, I have no idea how it's used and whether there's actually a good reason why you'd want to use it over SUID. But boy this seems like a hugely risky feature and sure enough... it broke.

akira2501 3y ago
> Why not just ignore it altogether? hah.. even worse, if you follow down the thread in your last link, apparently there is an SXID_IGNORE which they decided was better implemented as an SXID_ERASE for some variables.
akyuu 3y ago
From what I’ve read from some security researchers, glibc is not really focused on security. For example, it contains CPU-specific manually crafted assembly for optimization purposes, and its memory allocator implements exploitation-friendly features such as thread caches. I’m not surprised by this vulnerability, and I suspect there are many similar ones that haven’t been discovered yet. musl (used by default on Alpine and Chimera Linux) and the BSD libc’s on the other hand are much more minimal and conservative.
- dralley 3y ago
  >musl (used by default on Alpine and Chimera Linux) and the BSD libc’s on the other hand are much more minimal and conservative. Read: slower and with less comprehensive standards compliance (even if some of those standards are a bit nutty).
  - yjftsjthsd-h 3y ago
    I was under the impression that musl does care about standards compliance, hitting problems mostly when people expect non-standardized behavior.
    - saagarjha 3y ago
      Musl is somewhat the embodiment of malicious compliance to the standard.
  - blueflow 3y ago
    musl has a better track record of standards compliance than glibc. Common method for porting to musl is putting non-standard compliant code into an ifdef glibc.
    - kazinator 3y ago
      Counterexample: musl's crypt() does silly things, like treat all unrecognized inputs as DES, even if the salt characters are invalid.
      - q66 3y ago
        at least it actually supports blowfish
    - kelnos 3y ago
      This is, of course, the same musl that refused to implement TCP DNS requests until very recently. And they only did so because the DNS standards people got fed up with people not implementing it, and made it a requirement.
aleden 3y ago
The GLIBC_TUNABLES can be used to "choose" between different versions of e.g. memcpy at runtime. This can be really useful for debugging, if you want to allow/disallow AVX extensions, for example (even if your CPU supports them). This is what I use on x86_64 to make life easier for my "static" version of qemu usermode: GLIBC_TUNABLES=glibc.cpu.hwcaps= -AVX -AVX2 -AVX_Usable -AVX2_Usable -AVX512F_Usable -SSE4_1 -SSE4_2 -SSSE3 -Fast_Unaligned_Load -ERMS -AVX_Fast_Unaligned_Load
- remexre 3y ago
  Does removing ERMS actually make life easier? I thought it was the "do the simple thing" option, and an emulator could just turn it into a memcpy on the emulator's side.
  - saagarjha 3y ago
    rep movsb has stronger requirements than memcpy, in particular with regards to behavior when the source and destination overlap.
- remram 3y ago
  Sounds like a DoS vector at least, even if the filter worked correctly. Why should you be able to disable AVX extensions for another user's process? Why would you debug across SUID boundaries?

akira2501 3y ago

> Why not just ignore it altogether? hah.. even worse, if you follow down the thread in your last link, apparently there is an SXID_IGNORE which they decided was better implemented as an SXID_ERASE for some variables.

akyuu 3y ago

From what I’ve read from some security researchers, glibc is not really focused on security. For example, it contains CPU-specific manually crafted assembly for optimization purposes, and its memory allocator implements exploitation-friendly features such as thread caches. I’m not surprised by this vulnerability, and I suspect there are many similar ones that haven’t been discovered yet. musl (used by default on Alpine and Chimera Linux) and the BSD libc’s on the other hand are much more minimal and conservative.

dralley 3y ago
>musl (used by default on Alpine and Chimera Linux) and the BSD libc’s on the other hand are much more minimal and conservative. Read: slower and with less comprehensive standards compliance (even if some of those standards are a bit nutty).
- yjftsjthsd-h 3y ago
  I was under the impression that musl does care about standards compliance, hitting problems mostly when people expect non-standardized behavior.
  - saagarjha 3y ago
    Musl is somewhat the embodiment of malicious compliance to the standard.
- blueflow 3y ago
  musl has a better track record of standards compliance than glibc. Common method for porting to musl is putting non-standard compliant code into an ifdef glibc.
  - kazinator 3y ago
    Counterexample: musl's crypt() does silly things, like treat all unrecognized inputs as DES, even if the salt characters are invalid.
    - q66 3y ago
      at least it actually supports blowfish
  - kelnos 3y ago
    This is, of course, the same musl that refused to implement TCP DNS requests until very recently. And they only did so because the DNS standards people got fed up with people not implementing it, and made it a requirement.

aleden 3y ago

The GLIBC_TUNABLES can be used to "choose" between different versions of e.g. memcpy at runtime. This can be really useful for debugging, if you want to allow/disallow AVX extensions, for example (even if your CPU supports them). This is what I use on x86_64 to make life easier for my "static" version of qemu usermode: GLIBC_TUNABLES=glibc.cpu.hwcaps= -AVX -AVX2 -AVX_Usable -AVX2_Usable -AVX512F_Usable -SSE4_1 -SSE4_2 -SSSE3 -Fast_Unaligned_Load -ERMS -AVX_Fast_Unaligned_Load

remexre 3y ago
Does removing ERMS actually make life easier? I thought it was the "do the simple thing" option, and an emulator could just turn it into a memcpy on the emulator's side.
- saagarjha 3y ago
  rep movsb has stronger requirements than memcpy, in particular with regards to behavior when the source and destination overlap.
remram 3y ago
Sounds like a DoS vector at least, even if the filter worked correctly. Why should you be able to disable AVX extensions for another user's process? Why would you debug across SUID boundaries?