4 ms·

In ClickHouse, we forbid LD_PRELOAD and every similar variable: https://github.com/ClickHouse/ClickHouse/blob/master/programs/main.cpp#L336 https://github.com/C

In ClickHouse, we forbid LD_PRELOAD and every similar variable: https://github.com/ClickHouse/ClickHouse/blob/master/programs/main.cpp#L336 https://github.com/ClickHouse/ClickHouse/blob/master/program... We also forbid dlopen - so even if some third-party library commits such an offense, it will be blocked: https://github.com/ClickHouse/ClickHouse/blob/master/programs/main.cpp#L410 https://github.com/ClickHouse/ClickHouse/blob/master/program...

Racing0461 3y ago
I get the first one but not the second one. Since you are just redirecting dlopen, aren't you just rewriting it for people that actually work on your codebase which then compiles? It doesn't actually block it from 3rd parties.
- zX41ZdbW 3y ago
  It is the case when a library already uses dlopen in unusual code paths, but we want to make sure that code paths won't work. The examples are some authentication plugins.
  - blibble 3y ago
    all they have to do to beat your dlopen blocker is link against libdl statically one extra argument to the linker when they compile their plugin
    - Racing0461 3y ago
      I think p is just trying to prevent people from being shot in the foot as opposed to preventing malicious users ie hackers.
      - josephcsible 3y ago
        You're not supposed to go to such lengths to stop people from shooting themselves in the foot, because when you do, you also stop people from doing clever things.
        Racing0461 3y ago
        I don't want my authentication library to do clever things.
        josephcsible 3y ago
        Then you don't have to make yours do so. But if other sysadmins disagree, they should be able to make theirs do so.
        Racing0461 3y ago
        im talking from the point of view as the user of the software.
        josephcsible 3y ago
        The same applies. If you don't want it to do clever stuff on your computer, then just configure it not to do so. Don't try to make the software less configurable so that I can't make it do clever stuff on my computer.
- nemetroid 3y ago
  If you link your executable to a library that references a symbol defined in your executable, that symbol will be added to the executable's dynamic symbol table.
lgg 3y ago
This is awesome. macOS actually enables the same env var protections by default if your process is opted into the hardened runtime. You can do that by passing —-options=runtime to your codesign invocation.
- josephcsible 3y ago
  What's the easiest way to use those variables anyway on a binary that's been compiled that way? Does it need SIP to be off?
  - LoganDark 3y ago
    You could try completely unsigning the binary: https://reverseengineering.stackexchange.com/a/13623 https://reverseengineering.stackexchange.com/a/13623 This won't work for everything, and it probably does need SIP to be off (also make a backup!) but it might be a way to get something to work.
  - saagarjha 3y ago
    Yes, and then patch dyld to enable library insertion again.
bdowling 3y ago
Why can't an attacker just link a new getenv() that pretends that LD_PRELOAD and other variables aren't set?
- a-dub 3y ago
  LOL
- vhcr 3y ago
  You could also modify the source code to remove the check, I'm guessing this is just for people that are accidentally setting LD_PRELOAD.
- zX41ZdbW 3y ago
  It is mostly to protect from unusual configurations rather than protecting from an attacker, e.g., https://github.com/ClickHouse/ClickHouse/issues/43933 https://github.com/ClickHouse/ClickHouse/issues/43933 and https://github.com/ClickHouse/ClickHouse/issues/10505 https://github.com/ClickHouse/ClickHouse/issues/10505
  - wyldfire 3y ago
    It almost seems like it gives credence to self-inflicted problems by implementing changes like that. The creativity of people to break things by misusing them is unbound. Fix your bugs, fix non-bugs that seem like "foreseeable misuse". Don't fix "my users are in outer space" non-bugs.
  - GuB-42 3y ago
    This is so wrong... Why the fuck do Azure and Google Collab mess with LD_PRELOAD. Why do Clickhouse crashes when it does? Does it rely on unspecified behavior or are the preload libraries problematic? Is the preloaded library buggy? It looks like an arms race where stome piece of software forces use of a particular version of library instead of using what's in the system (but not static linking), then someone else use LD_PRELOAD to force back the use of the system library, and then other software ban LD_PRELOAD to counter the counter. I understand that some ugly things are sometimes needed to make software work, but think of the collateral damage.
blibble 3y ago
that's not going to block anyone who understands anything about how the dynamic loader works /lib64/ld-linux-x86-64.so.2 --preload myevil.so ./your_program there we go, bypassed
deleted 3y ago
[deleted]

Racing0461 3y ago

I get the first one but not the second one. Since you are just redirecting dlopen, aren't you just rewriting it for people that actually work on your codebase which then compiles? It doesn't actually block it from 3rd parties.

zX41ZdbW 3y ago
It is the case when a library already uses dlopen in unusual code paths, but we want to make sure that code paths won't work. The examples are some authentication plugins.
- blibble 3y ago
  all they have to do to beat your dlopen blocker is link against libdl statically one extra argument to the linker when they compile their plugin
  - Racing0461 3y ago
    I think p is just trying to prevent people from being shot in the foot as opposed to preventing malicious users ie hackers.
    - josephcsible 3y ago
      You're not supposed to go to such lengths to stop people from shooting themselves in the foot, because when you do, you also stop people from doing clever things.
      - Racing0461 3y ago
        I don't want my authentication library to do clever things.
        josephcsible 3y ago
        Then you don't have to make yours do so. But if other sysadmins disagree, they should be able to make theirs do so.
        Racing0461 3y ago
        im talking from the point of view as the user of the software.
        josephcsible 3y ago
        The same applies. If you don't want it to do clever stuff on your computer, then just configure it not to do so. Don't try to make the software less configurable so that I can't make it do clever stuff on my computer.
nemetroid 3y ago
If you link your executable to a library that references a symbol defined in your executable, that symbol will be added to the executable's dynamic symbol table.

lgg 3y ago

This is awesome. macOS actually enables the same env var protections by default if your process is opted into the hardened runtime. You can do that by passing —-options=runtime to your codesign invocation.

josephcsible 3y ago
What's the easiest way to use those variables anyway on a binary that's been compiled that way? Does it need SIP to be off?
- LoganDark 3y ago
  You could try completely unsigning the binary: https://reverseengineering.stackexchange.com/a/13623 https://reverseengineering.stackexchange.com/a/13623 This won't work for everything, and it probably does need SIP to be off (also make a backup!) but it might be a way to get something to work.
- saagarjha 3y ago
  Yes, and then patch dyld to enable library insertion again.

bdowling 3y ago

Why can't an attacker just link a new getenv() that pretends that LD_PRELOAD and other variables aren't set?

a-dub 3y ago
LOL
vhcr 3y ago
You could also modify the source code to remove the check, I'm guessing this is just for people that are accidentally setting LD_PRELOAD.
zX41ZdbW 3y ago
It is mostly to protect from unusual configurations rather than protecting from an attacker, e.g., https://github.com/ClickHouse/ClickHouse/issues/43933 https://github.com/ClickHouse/ClickHouse/issues/43933 and https://github.com/ClickHouse/ClickHouse/issues/10505 https://github.com/ClickHouse/ClickHouse/issues/10505
- wyldfire 3y ago
  It almost seems like it gives credence to self-inflicted problems by implementing changes like that. The creativity of people to break things by misusing them is unbound. Fix your bugs, fix non-bugs that seem like "foreseeable misuse". Don't fix "my users are in outer space" non-bugs.
- GuB-42 3y ago
  This is so wrong... Why the fuck do Azure and Google Collab mess with LD_PRELOAD. Why do Clickhouse crashes when it does? Does it rely on unspecified behavior or are the preload libraries problematic? Is the preloaded library buggy? It looks like an arms race where stome piece of software forces use of a particular version of library instead of using what's in the system (but not static linking), then someone else use LD_PRELOAD to force back the use of the system library, and then other software ban LD_PRELOAD to counter the counter. I understand that some ugly things are sometimes needed to make software work, but think of the collateral damage.

blibble 3y ago

that's not going to block anyone who understands anything about how the dynamic loader works /lib64/ld-linux-x86-64.so.2 --preload myevil.so ./your_program there we go, bypassed

deleted 3y ago

[deleted]