Hacker News Reader

Comment by brianpgordon | Hacker News Reader

Hm, I thought there was some issue with glibc not wanting to provide wrappers for certain Linux syscalls. What if the Go runtime wanted to use one of those syscalls for some reason? It seems like then it'd be forced to go straight to the kernel.

View on HN

Yes, it'd have to bypass libc for those system calls, just like any C program would. How is that an excuse for bypassing libc for things like read(2)?

No, making system call interposition harder isn't a security feature. A user who can LD_PRELOAD you can already do arbitrary things to your program.

Sometimes when folks talk to the kernel, they want to know they're talking to the actual kernel. glibc by design lets random stuff on the system MiTM symbols like read (even security critical ones like getrandom) and the LGPL effectively forbids many projects from using static linking as an escape hatch. The Chrome guys had to write a whole system call library from scratch because of it. On Windows it tends to get much more intense, where dynamic symbol interposition is brought to its logical conclusion, and you've layers upon layers of antivirus hooks and spyware sitting between you and the system. There, pretty much the only thing you can do is just SSL the heck out of everything.

> 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.

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.

> 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?

Read the GCC Runtime Exception v3.

> 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=31...), while there's a security boundary at the network connection.

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.

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.

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.

Enumerating specific interposition user cases has nothing to do with the point I made, which is about threat modeling. You still have not articulated any specific threat model; you've instead tried to distract the conversation and move it in a different direction.

You're welcome to complain about how I talk, but this isn't about me. This is about serving the user and making sure tech behaves the way they expect it to. We need to raise awareness of infrastructural weaknesses that folks may need to consider, in order to stay safe.

I consider symbolic interposition to be one of those things. Linux users might not feel comfortable about the fact that glibc currently makes it so easy to intercept system calls to Linux Kernel's RNG, that your upstream dependencies might actually compromise your key generator unintentionally.

Don't you think that's worth discussing? We could also talk about the concerns surrounding Layered Service Providers, which is another great example of userspace libraries misrepresenting APIs that are generally believed to be talking to the operating system.

It's not "how [you] talk". It's that you're not making an actual point. There is no "safety" threat here, nor is there an "infrastructural weakness[]". Fretting about "safety" without identifying a threat model is vacuous. What is, specifically, your threat model? What security guarantees can a program make only through bypassing libc? Why aren't the vast majority of programs --- the ones that call libc --- vulnerable to this ineffable threat?

Users get to control how programs execute. They can interpose symbols. They can disassemble programs. They can run programs under a debugger. They can modify the kernel. They can run programs in a VM. A program can't detect this intermediation; nor does it have any right to do so. A program has no business breaking random OS visibility and control features. We generally call the ones that try malware.

Bypassing libc when making system calls doesn't give a program any insurance against environmental changes. It just inconveniences users while providing no "safety" guarantees. If you want full control over a program's execution environment, ship an appliance.

glibc has a fallback in the form of the syscall() function, which can be used to invoke any syscall without the need for a wrapper, e.g.

    syscall(SYS_getcpu, &cpu, &node, NULL);

How is that different from just calling it yourself?

It means you don't have to deal with the kernel's calling conventions, which are architecture-specific and require inline assembly.

Reply on news.ycombinator.com