5 ms·
So let me paraphrase to see if I understand the context correctly: - the only guaranteeS are argc>=0, argv[argc] == NULL, and envp comes right after argv - ar
by kortex 5y ago
So let me paraphrase to see if I understand the context correctly:
- the only guaranteeS are argc>=0, argv[argc] == NULL, and envp comes right after argv
- argc is _almost always_ >= 1
- a widely used sbin (polkit) just assumes argv is always at least 1 element and so iterates starting at argv[1] (without checking argc)
- said polkit also mutates argv, so if it is fed with argc actually zero, it actually mutates envp
- some devs want a patch to the kernel to prevent calling execve with argc==0, (which probably should have been in the original spec, but that ship has sailed) as a way of preventing other similar footguns.
- other devs are like "that's gonna potentially break userspace" which is a valid concerne
Is that more or less it?
- johnny22 5y agowasn't it pkexec specifically, not polkit generally that was the problem?
- deleted 5y ago[deleted]
- kortex 5y agoYeah that sounds more technically correct.
- AdamJacobMuller 5y agoaside from "that ship has sailed" yes. The debate seems to be if they can actually do it safely or not, and from the article it seems like they think they can actually do it safely.
- kortex 5y ago"That ship has sailed" i.e. POSIX forbidding argc==0 when standardizing. I agree it's worth considering it now. I think argc>0 is close enough to a convention that things ought to mostly work, but it kind of irks me that it's necessary. But it should reduce ambiguity.
- MrStonedOne 5y ago
- comex 5y agoOne more point: It's not just polkit. It's actually extremely common for programs to misbehave when invoked with argc == 0. Try it out yourself. Build this program [1] and run it on random programs in /bin and /usr/bin. Count how many segfault. For me, it's a significant fraction, on both Linux and macOS. (Most of the GNU coreutils print an error and abort; this can be accompanied by a core dump, but I still wouldn't count it as misbehaving. On the other hand, a few utilities act as if the environment variables were passed as arguments, which I'd count as misbehaving even if they don't crash.) Now, the vast majority of those are not setuid, so even if those crashes can lead to arbitrary code execution, that wouldn't be a vulnerability, just a bug.* Of the handful of setuid programs, I actually did get some to crash(!), but the ones I checked are just non-exploitable null pointer accesses (likely because they try to access argv[0] without checking if it exists). Thus, argc==0 is not necessarily a wellspring of vulnerabilities. Things have to line up just right for it to be exploitable. polkit is probably the only commonly-installed setuid binary with a vulnerability of this nature. But I'm sure there are some less-common ones that are vulnerable. And the fact that you can get crashes out of some of the most solid, boring programs that exist, even if they're not exploitable, demonstrates just how rare and poorly-understood argc==0 is. [1] https://gist.github.com/comex/fcd2c329be12f656929b80c4ab15b1dd https://gist.github.com/comex/fcd2c329be12f656929b80c4ab15b1... * On Linux, that is. On macOS, thanks to the entitlements system, there are many binaries where getting code execution could give you extra privileges, though only in rare cases are those privileges truly dangerous.