Hacker News Reader

Comment by josephcsible | Hacker News Reader

Anything the kernel does to try to mitigate this would break userspace. It's one thing to do that when necessary to fix a kernel vulnerability, but I don't like the idea of breaking userspace just to try to work around some buggy userspace programs.

View on HN

Yeah, I’m surprised that this patch is getting traction at all. If it’s a bug in the application, it should be fixed in the application. The kernel shouldn’t be changing the kernel-userspace interface to work around userspace bugs.

There are plenty of bespoke binaries out there with no/lost source code that won’t get the benefit of scrutiny from the kernel dev team. I certainly wouldn’t assume that none of them invoke execve with a NULL or 0-item arg parameter, and merging this patch would break them without recourse.

Given that this behavior is already disallowed (and faulting) on BSD and at least some commercial Unix flavors there shouldn't be too much software out there that relies on it.

I would lean towards making it an API error BSD style and taking breakage on a case by case basis. I'm not the person who would be called up however, so it's easy for me to say.

Worst case you can create a sysctl variable to enable/disable the check for those corner cases where it can't be fixed and other precautions can be taken against the security vulnerability.

> Given that this behavior is already disallowed (and faulting) on BSD and at least some commercial Unix flavors there shouldn't be too much software out there that relies on it.

How much commercial software targets UNIX these days?

Enough to keep sales of AIX, Solaris, mainframes and several POSIX based RTOS going.

And that little one named macOS as well.

If anything this breaks is already broken on macOS the argument probably becomes rather simpler, indeed.

macOS allows argc == 0, it has a separate mechanism for providing the exec path of the executable to the process, namely the KERN_PROCARGS2 sysctl which includes the saved exec path along with argc, argv, envp, and the apple pointer.

Amusingly enough, Apple has had a bug in their `ps` since 10.3 that assumes argc > 0, which actually results in a similar (but not likely harmful, despite ps being setuid) bug.

Platform APIs should be designed in such a way that it is easy to use them securely. That's why we don't use strcpy() and friends anymore. (Yes, I know, not quite the same, as you can mitigate this with a new function and implore people not to use the old one.)

Sure, the pkexec bug is now fixed, but I expect we'll see another similar one eventually. I know I personally have written a lot of C programs that assume argc>0 and argv!=NULL, and I'm sure there are thousands of such programs.

I think returning EINVAL on exec in this case may be too much. I think the right move is probably for the kernel to just fix things up when exec is called in this way, so argv will always have at least one element, and that element 0 won't be NULL. I think any program that would break with that change is something I'd be able to live with.

It's very easy to use argc/argv securely as they currently are. POSIX clearly states that argc can be zero, but polkit didn't know that for some reason. When you're writing privileged software, you can't make assumptions about user input (and the specs) like this.

I get that the vulnerability could have been prevented if Linux deviated from the spec like some of the BSDs might have, but we shouldn't make it the responsibility of kernel developers to make logic errors in user applications less likely.

I agree that we shouldn't -make- it their responsibility but it's still worth asking in a case like this whether -this time- it's a better trade-off to do so anyway.

> That's why we don't use strcpy() and friends anymore.

We definitely do when safe to do so…

I am awful at C so this comment should be considered merely an anecdote but I was -so- sad when I (having started learning on BDSi and NetBSD) needed to port a program to other systems and discovered strlcpy wasn't there. (damnit, Jim, I'm already a segfault generator when I try to perpetrate C, I need all the help I can get!)

Unlike other bugs, this change shouldn't break any application that is being called. argc >= 1 is the normal use case.

So this would break anything that calls execve() with argc==0. Is such call providing any functionality?

In addition to returning EINVAL being produced by not well written callers, another option would be to force argc==0 and fill up argv[0] with process name. That fix would make everything continue to work.

The ldd program that lists the shared libraries used by an executable at least used to exec with an empty argv, which the dynamic linker detected and listed libraries instead of linking and running. I learned that when I screwed up an inetd configuration and saw a list of libraries instead of the desired results.

Edit: just tried on windows 10 WSL, and it had a sad (blue screen).

WSL2 has made my life so much better that now I want to give it a hug.

(also, TIL, thank you)

I'll be very interested to see if Linus bites at all.

This is probably the most sympathetic I've been to the Kernel breaking userspace programs that rely on bad behaviour, but Linus has been pretty clear on the matter in the past.

> WE DO NOT BREAK USERSPACE!

https://lkml.org/lkml/2012/12/23/75

Eh, Linux has broken userspace in the past. Twice for me personally in the last ~10 years, one of which could've resulted in hardware damage if the stars had aligned slightly differently :D I wouldn't count it out.

Are you sure you don't mean it's broken out-of-tree drivers? What exactly did it break?

No out-of-tree drivers.

1. https://github.com/torvalds/linux/commit/6b99e3569ba17b9fd38... (2017) This changed the userspace hwmon API of the thinkpad-acpi driver from `/sys/devices/platform/thinkpad_hwmon/` to `/sys/class/hwmon/hwmon1/`, which broke the sensor-monitoring software that I wrote for my laptop. It was justified on the basis that libsensors was resilient to this change, but my software didn't use libsensors.

2. https://github.com/torvalds/linux/commit/b02c6857389da66b09e... (2020) This changed the userspace hwmon API of the k10temp hwmon driver, specifically by swapping which temperatures referred to Tctl vs Tdie. For example, my Threadripper reports one real temperature and one fake temperature that's 27degC higher than the real one. (AMD does this because it wants default fan curves to think the CPU is hotter than it really is, because it wants fans to run faster by default.) Since this change swapped the two sensors, it could've had one of two outcomes for fan curve software:

- a) Software that monitored the fake temperature was now reading the real temperature, and thus running the fan slower than it needed to.

- b) Software that monitored the real temperature was now reading the fake temperature, and thus running the fan faster than it needed to.

Luckily my case was (b), so I discovered the change not because of a throttled / smoking CPU but because of an unexpectedly loud CPU fan.

(There was another case in ~2012 when the thinkpad-acpi driver switched from procfs to sysfs, but that one was more "justified" because sysfs was the right place for hwmon anyway.)

Stuff in /sys/class changes all the time (maybe not so much on normal computers, but on semi-embedded ARM platforms they see to change a lot)

Only way to completely fix buggy user land is to error on any attempt to execute a program. Before this polkit had an authentication bypass last year, trusted user supplied ids around 2018^1, ... . The list goes on.

^1 which ironically enough was an attempt to avoid racy uid checks on setuid binaries.

https://gitlab.freedesktop.org/polkit/polkit/-/commits/maste...

They should take Windows 95 approach and try to detect programs that need special behavior, perhaps even include a list of binary names. This goes against the ethos of clean elegant solutions that the FOSS world likes, but at some point we have to realize that the kernel is enterprise code, and we need enterprise solutions sometimes (read: hacky).

In open source this isn't necessary since you can just go in and fix the broken programs and not carry deadweight workarounds forever. And some don't care too much about broken closed source programs.

You're exactly right. However, not all programs running on Linux are FOSS. And while you may not care about broken closed-source programs, you can't really say "we don't care" because you don't speak for the entire FOSS community, and I think if you look at it again, you'll find that the FOSS community DOES care (in actions not so much in words) about corporate sponsorship, especially for the Linux kernel.

I wonder if such hackery could be enabled via ebpf such that distro vendors could make an active choice to do that via default configuration rather than needing to get it into mainline.

(I am ... ambivalent, let us say ... about whether I -approve- of people doing so in any given case, but I definitely believe in them having the option)

I would bet IBM and Red-Hat care a lot.

Red Hat works with software partners to port and fix their software for Linux - in fact I was doing some of that exact activity earlier today, helping to port a program for a partner to GCC 12 (combined with hardening flags, it breaks a bunch of previously working C/C++ code).

Reply on news.ycombinator.com