Loader path security

[mrdomino]

There is currently a security issue in the way the loader passes paths to the binary.

For argument's sake, consider:

• user installs a setuid root sudo.com that reads its configuration out of /zip/etc/sudoers
• user does ln -sf /usr/local/bin dir
• user runs dir/../bin/sudo.com bad.sh
• user wins a race with the loader, changing dir to point to bad from which ../bin/sudo.com is a zip archive with a user controlled sudoers file in it, between when the loader finds the binary and when the binary opens itself

There are a few mitigations that can be done:

1. If the loader detects that the binary it has been asked to run is setuid, it can refuse to run it from a non-canonical path (i.e. a path containing ...)
2. The loader can always do (the moral equivalent of) realpath on the path it resolves before passing it to the binary.
3. More speculatively, binaries can embed their own hash at a known label. Whenever they open themselves, they can compare the hash of the binary they open against their own embedded value.

1 is a no-brainer. 2 may be a good idea but I'm not sure it buys much beyond 1. 3 is a very neat sounding idea to me; thoughts?

EDIT: actually 1 doesn't help that much. Consider: ln -sf /usr/local dir; ~/dir/bin/sudo.com. There is probably some adjacent mitigation that is similar in spirit though.

[jart]

Cosmo binaries should be assimilated if they're going to be used as setuid binaries. What you're describing is only an issue for Apple Silicon, since it's not possible to assimilate binaries there. We came up with a pretty clever hack for letting cosmo binaries serve as login shells, despite that limitation. But the idea of someone using it for setuid programs is pretty far out there. What's the use case? If we solved it, then would you truly start using ape setuid binaries yourself on your own apple silicon systems?

[jart]

As for the possibility of how the recent changes to GetProgramExecutableName() might impact assimilated binaries, we could change that function so that if issetugid() is true, then only the exotic methods (e.g. /proc/self/exe) will be used.

[mrdomino]

What's the use case? If we solved it, then would you truly start using ape setuid binaries yourself on your own apple silicon systems?

Honestly? OpenBSD's doas is nice enough that I might be inclined to try. It would be really cool to have one single binary with one single SHA256 that is "the trusted way to gain privileges, everywhere."

[mrdomino]

As for the possibility of how the recent changes to GetProgramExecutableName() might impact assimilated binaries, we could change that function so that if issetugid() is true, then only the exotic methods (e.g. /proc/self/exe) will be used.

Not sure I understand this yet. Assimilation means that the loader code is never run, right? (e.g. I could also imagine it meaning that the loader is made the entry point of the resultant binary.)

How does assimilation interact with /zip? Is the binary able to just get the zip archive out of its own address space directly? Whereas it isn't able to do that already, because its address space has been overwritten?

[mrdomino]

Aside from the setuid case, there is still an argument here for something like strictness or consistency or principle-of-least-surprise. It is ambiguous whether it is a security argument; on the one hand, you could say that once someone can do this sort of thing to your filesystem layout, they've already pwned you. But on the other hand, there can be different levels of being pwned; e.g. removing accessible ROP gadgets from libraries is always good, even though you could say "once an attacker controls a jump destination you're screwed."

As far as mitigations go, I thought about it more and I may have the beginnings of a design for what could be a fairly seamless and universal solution. Happy to go into it some time, but it's not super urgent given current usage.

[jart]

Honestly? OpenBSD's doas is nice enough that I might be inclined to try. It would be really cool to have one single binary with one single SHA256 that is "the trusted way to gain privileges, everywhere."

APE has traditionally shied away from doing anything that needs root, because (a) root commands usually require OS-specific stuff, and (b) it helps engender trust to not require end-users run an installer that wants root. That's where unwanted software like browser toolbars comes from. doas is probably an exception to rule (a) and it truly is one of my favorite commands.

Not sure I understand this yet. Assimilation means that the loader code is never run, right? (e.g. I could also imagine it meaning that the loader is made the entry point of the resultant binary.)

Assimilation means, on Linux / BSD at least, that your APE binary turns into an ELF binary whose et_entry is _start. No loader code is run. The OS kernel loads it. The same is true of Mach-O on MacOS x86. On Apple Silicon, assimilate currently raises an error since Apple disallowed static binaries. It's the only platform we can't go native on. If you want to change that, do this:

• Write a program that turns an APE or ELF binary into a .s assembly file. It should be sufficient to basically hex dump each PT_LOAD into a linkable symbol, and then hexdump the zip files, central dir, and eocd. Write a new loader.c file that xcode can compile. Your loader can memmove() those assembly symbols to the correct static addresses and mprotect(PROT_EXEC) them. This could be implemented in the assimilate program. Finally, we cross our fingers and hope and pray that the Apple linker places the PKZIP EOCD in the last 64kb of the file. You'll then have a native fully functional APE-like binary that's dynamically linked and doesn't need risque hacks to accomplish security sensitive stuff.

As for the rest, a lot of people like to lick the cookie when it comes to that stuff, but it's of little consequence so long as we responsibly document the software and make it clear what practices are recommended and what security blankets are provided. Cosmopolitan provides things like production friendly ASAN support. We ported OpenBSD's pledge() and unveil() functions to Linux in order to make byzantine tools like SECCOMP BPF accessible to the masses. We're part of the solution and I'm always looking for opportunities for ways we can do better. I'd encourage focusing our improving our existing strategies.

[jart]

Now that I think about it, zip files might not be possible if we use the Apple linker since it probably doesn't let us control the file offsets. Shucks.

[mrdomino]

Summarizing our talk about this on Discord plus my own thoughts:

• We should change the loader to pass the program executable name in a register rather than an environment variable. I am a noob at this, any suggestions on where to start? Currently I'm thinking in terms of: what is a good register to use, and can you assume that a register is going to be 0 outside of the loader case?
• When issetugid is true, binaries should only use the exotic methods for locating themselves.
• (IMO) the loader should dereference symlinks a la realpath in constructing the path it presents to the binary. We shouldn't make it that easy for users to control what a root-owned /usr/local/bin/zsh.com sees as /zip/etc; they should have to at least copy it to a filesystem they have exec permissions on.

Having slept on it and considered your feedback, I've by now more or less concluded that the whole hash verification scheme is unnecessary overkill.

[jart]

Yes. You should be able to assume registers will be zero. The only exceptions I know of are:

1. NetBSD will only zero the call-clobbered registers.
2. Rosetta clobbers stuff too in a weird kind of way.

All you have to do is pick a volatile register (e.g. x2) and modify the end of Spawn() in the ape/ape-m1.c to hand if off. Leave a comment in libc/crt/crt.S mentioning x2, which is passed along as the third argument to cosmo() in libc/runtime/cosmo2.c. You can then stuff that value into a global variable.

As for realpath() I wouldn't want to second guess the user unless absolutely necessary. I normally don't like it when software does that to me. I don't see any harm in the user being able to control what zsh does when zsh is running as the user. I don't think it matters who owns the file, so long as setuid isn't in play. If it is, then feel free to realpath() if you think it'll help.

As for hash verification, I sort of try to do something similar to that in FindDebugBinary() so that backtraces won't print mysteriously wrong symbols. It's a little tricky from a build perspective to make something like that work.

[mrdomino]

I don't see any harm in the user being able to control what zsh does when zsh is running as the user.

It breaks some sandboxing approaches. Consider the case where an OS has a restricted user like git or something, who needs to be able to write files, but must not run arbitrary binaries. You can accomplish this by ensuring that the only filesystems they can write to are mounted noexec. But if the loader does not follow symlinks, they can circumvent this for cosmopolitan binaries.

I do think it's necessary when setuid is in play. And I kind of feel like it's more confusing to have two code paths than one; why shouldn't the path resolution behavior be the same always?

[jart]

OK if you want to realpath() it then that's fine. Since argv[0] will ideally hold what the user wants, and GetProgramExecutableName() should be an implementation detail mostly.

[mrdomino]

#1012 implements the M1-specific side of things. That leaves the non-M1 loader, and raw InitProgramExecutableName.

In the non-M1 loader case, I guess we want to add a new argument to Launch. There is probably a way to do it such that x2 conveniently winds up as the program executable name; what is the equivalent register in x86_64?

[mrdomino]

I guess rdx should eventually be set to the program executable name. But maybe we have to shuffle some arguments around to get there.

EDIT: okay never mind I am too stupid to understand cosmo.S. What register me use? What initbss mean?

[ghaerr]

what is the equivalent register in x86_64?

For C functions, the first six (non-float) arguments are passed in RDI, RSI, RDX, RCX, R8, R9.

For Linux and OSX system calls, the arguments are passed in RDI, RSI, RDX, R10, R8, R9 (and syscall number in RAX).

[mrdomino]

Thank you; got this sorted with @jart on Discord. We will use x2 on Arm, %rdx on x64.

Everything described in this issue is currently sitting in #1012 and mrdomino#1, so once those go through this can be closed.