3 ms·

> glibc by design lets random stuff on the system MiTM symbols like read Can you elaborate on this? I'm aware of things like LD_PRELOAD, but if an adversary co

> glibc by design lets random stuff on the system MiTM symbols like read Can you elaborate on this? I'm aware of things like LD_PRELOAD, but if an adversary controls the environment, he could just change PATH to point to a rooted version of chrome anyway. That also has to do with the capabilities of the system linker, not glibc. >the LGPL effectively forbids many projects from using static linking as an escape hatch The LGPL explicitly allows static linking, that's the main difference versus the GPL.

jart 7y ago
Are you in control of your network connection? Packets aren't that much different from calls between DSOs. It's just a big onion ring. If you make a conscious decision to trust Chrome with your data, then does Chrome have a moral obligation to ensure that choice, in reality, ends up being You<->Chrome, rather than You<->SysAdmin<->Comcast<->NSA<->Hacker<->Chrome? Or maybe they just want to protect IP holders. Or maybe they just don't want folks filing bugs about performance when the root cause turns out to be some poorly written system library. At the end of the day, it's all about minimizing unknowns. LGPL allows dynamic linking. Only way it'll allow static is if your releases are accompanied by tools for decompiling and recompiling your binaries with the LGPL bits interchanged. But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled.
- a1369209993 7y ago
  > But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled. Can you elaborate on this?
  - jart 7y ago
    Read the GCC Runtime Exception v3.
- cesarb 7y ago
  > Are you in control of your network connection? Packets aren't that much different from calls between DSOs. The difference is that calls between dynamic libraries are on the same side of the "airtight hatchway" (as explained by Raymond Chen at https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...), while there's a security boundary at the network connection.
  - jart 7y ago
    Imagine the modern PC as being just another substrate of this great battlefield where big corporations duke it out with each other and the individual owners are becoming less and less relevant to the security story. It's unpleasant. It seems to get raunchier each year. I've even seen household names retool things like graphics drivers to inject data harvesting code into command-line programs at runtime. Then the big companies who don't play dirty like that, usually react by demanding greater authoritarianism in tools, until the rest of us devs find ourselves smothered with -fpic aslr retpoline code-signed bubblewrapping, which isn't so much keeping us safe, but rather keeping big company A safe from big company B. Everything that the guy you linked said is correct. But locks aren't that relevant anymore, once the wolves have been invited in to live.
    - quotemstr 7y ago
      You've used a lot of rhetoric, but you haven't described a threat model. Both this comment and your previous one, the GP, use language of moral duty when talking about a specific software security measure. That's a category error. What specific threat is bypassing libc supposed to protect against? I don't think you have an argument here. As the poster to whom you're replying mentioned, anyone who can do symbol interposition already has full control over your program.
      - jart 7y ago
        Perhaps you could share specific details on the use cases that dynamic symbol interposition is intended to serve? Because the only one I think I've seen so far is setbuf(1) and I can imagine more than a few alternatives that could have been considered.

jart 7y ago

Are you in control of your network connection? Packets aren't that much different from calls between DSOs. It's just a big onion ring. If you make a conscious decision to trust Chrome with your data, then does Chrome have a moral obligation to ensure that choice, in reality, ends up being You<->Chrome, rather than You<->SysAdmin<->Comcast<->NSA<->Hacker<->Chrome? Or maybe they just want to protect IP holders. Or maybe they just don't want folks filing bugs about performance when the root cause turns out to be some poorly written system library. At the end of the day, it's all about minimizing unknowns. LGPL allows dynamic linking. Only way it'll allow static is if your releases are accompanied by tools for decompiling and recompiling your binaries with the LGPL bits interchanged. But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled.

a1369209993 7y ago
> But that actually might not be allowed either, since GCC 4.3+ headers and runtimes (e.g. libstdc++) kind of prohibit you from changing binaries on your own, after they've been compiled. Can you elaborate on this?
- jart 7y ago
  Read the GCC Runtime Exception v3.
cesarb 7y ago
> Are you in control of your network connection? Packets aren't that much different from calls between DSOs. The difference is that calls between dynamic libraries are on the same side of the "airtight hatchway" (as explained by Raymond Chen at https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...), while there's a security boundary at the network connection.
- jart 7y ago
  Imagine the modern PC as being just another substrate of this great battlefield where big corporations duke it out with each other and the individual owners are becoming less and less relevant to the security story. It's unpleasant. It seems to get raunchier each year. I've even seen household names retool things like graphics drivers to inject data harvesting code into command-line programs at runtime. Then the big companies who don't play dirty like that, usually react by demanding greater authoritarianism in tools, until the rest of us devs find ourselves smothered with -fpic aslr retpoline code-signed bubblewrapping, which isn't so much keeping us safe, but rather keeping big company A safe from big company B. Everything that the guy you linked said is correct. But locks aren't that relevant anymore, once the wolves have been invited in to live.
  - quotemstr 7y ago
    You've used a lot of rhetoric, but you haven't described a threat model. Both this comment and your previous one, the GP, use language of moral duty when talking about a specific software security measure. That's a category error. What specific threat is bypassing libc supposed to protect against? I don't think you have an argument here. As the poster to whom you're replying mentioned, anyone who can do symbol interposition already has full control over your program.
    - jart 7y ago
      Perhaps you could share specific details on the use cases that dynamic symbol interposition is intended to serve? Because the only one I think I've seen so far is setbuf(1) and I can imagine more than a few alternatives that could have been considered.