06:04 <abliss> this sudo vuln is nsty. https://www.sudo.ws/alerts/unescape_overflow.html

06:04 <abliss> *nasty

06:05 <abliss> worth listing as a security non-event for sandstorm? anyone who is just running a bunch of lightly-trusted servers as different linux users, trusting linux to keep them separate, could be owned

06:07 <kentonv> eh, relying on regular Linux user separation to defend against malicious actors has been unwise for a long time

06:08 <kentonv> frankly on all the systems I own and administer, this is a security non-event because there's only one user anyway and anything that needs sandboxing is in a much tighter sandbox. :P

06:09 <kentonv> heh though I guess android uses uid separation to sandbox apps, but they also disabled sudo in general a while ago I think?

06:11 <abliss> i don't think user builds of android have ever shipped with sudo.

06:14 <abliss> i think a lot of debian /ubuntu services use uid separation by default. e.g. www-data for apache, transmission-daemon for transmission, etc

06:15 <kentonv> (they never shipped with sudo, but you could install a sudo binary to "root" your phone... but I think more recently they disabled setuid binaries in general)

06:16 <kentonv> separating services by uid is reasonable when the services themselves are mostly-trusted code, and the goal is to prevent accidental or buggy interference. It's not really a good deference against a service that is actively malicious.

06:17 <kentonv> s/deference/defense/

06:18 <kentonv> I mean, maybe that's your point... here's an example of why it's not a good defense

06:20 <kentonv> yeah, ok, I guess if the linux kernel bugs are Sandstorm security non-events, this is too

06:21 <kentonv> of course, that list hasn't really been updated in 4 years, might look weird to add something now. :/

06:23 <abliss> i could be wrong but i think this is one of the most broadly exploitable-by-default local privilege exploits we've seen in quite a while. possibly in four years.

06:24 <kentonv> I'd be surprised if there haven't been any Linux kernel privesc bugs in that time. They were happening about once a month during the time that I was paying attention.

06:25 <abliss> (i don't think pushing sudo was ever a way to root an android phone, because you'd need root privs in the first place to make it setuid root... but yes they have been locking down setuid ability, by mounting everything but /system nosetuid, and making /system mounted readonly, and more recently not really mounted at all )

06:26 <abliss> yeah there have a bunch, and i haven't been watching super closely, but i try to keep half an eye on it and most of them in the past 4 years have come with asterisks attached, which made them for one reason or another unexploitable AFAICT on any systems relevant to me.

06:27 <abliss> and it doesn't involve running a new kernel. the bug is in a userspace binary installed almost everywhere in the last 10 years.

06:28 <kentonv> (right, adding sudo wasn't how you get root privs in the first place, but rather was the unofficial convention for making root available to apps, IIRC)

06:30 <abliss> (as far as i've seen that would usually be `su`, e.g. as managed by Magisk or SuperSU or similar apps, not `sudo` itself, which has a bunch of dependencies and might be ungainly to compile for bionic)

06:31 <kentonv> (oh right, sorry -- same idea, not the same command)

06:49 <abliss> and yeah, i think people know not to run actively malicious code with nothing but a uid barrier. but they mostly trust apache to run their php code, and they kinda trust wordpress to host their blog, and maybe they don't trust their wordpress plugins very much but they don't expect them to be able to wipe the disk or install a rootkit (most of the time)...

14:27 <xet7> Huh, I don't dare to run real WordPress with PHP backend. Most likely it would be hacked like Drupal website I had to rescue and convert to static website. I prefer Sandstorm WordPress.

15:13 <abliss> yeah i think everyone here prefers to sandbox things! but out in the world i suspect a lot of people just 'sudo apt-get install wordpress' and mostly keep the default configuration.

15:23 <JacobWeisz[m]> I'd guess most WordPress users copied the zip file to their cPanel account, realistically.

15:30 <abliss> good point. i wonder how many cpanel shell accounts can use sudo.

15:37 <JacobWeisz[m]> Very few.

15:38 <JacobWeisz[m]> Most shared hosting providers don't even enable shell access unless you ask for it, and it's very restricted if you do.

15:38 <JacobWeisz[m]> Mostly because such providers aren't actually virtualizing their clients into separate machines.

15:39 <abliss> right, but i'm not sure that means that the wordpress process couldn't exec /usr/bin/sudo if it got hacked.

16:23 <xet7> Some shared hosting providers have automatic detection of hacked wordpress accounts, using some detection scripts