/bin/sh: the biggest Unix security loophole (1984) [pdf]
15 comments
·January 8, 2025panki27
dehrmann
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
supriyo-biswas
Loopholes of this kind exist these days as well.
When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
netsharc
In the Middle Ages, when Internet access wasn't in your pocket all the time, I was in a hostel which had Internet kiosks, you'd put a coin in a machine, and the PC would start 2 browser windows: 1 with just a countdown, and one for you to browse. You'd have to put more coins or when the time ends the browser would be killed.
Of course there was nothing else in the UI except this window and the browser, but on ancient Firefox, in the print window you had the option to specify the command line to print. I tried "xterm", hit "Print", and voila, a prompt!
Using ps, I managed to figure out the difference between the unpaid browser and the paid one, and next time around I could launch a browsing session without payment...
mingus88
As someone who used to sysadmin and was well aware of this trick, sometimes a developer or dba will bully their way through leadership to make sure they never need to ask for permission to edit their configs
We all knew it was a bad idea but when your boss and their boss say do it, it’s done.
I’m pretty sure the dba (autocorrect magically suggested “diva” here) knew as well and just wanted a backdoor to have root for whatever they wanted.
I later busted the same team applying patches out of band with tripwire. Hey, wonder how you pulled that off…
denysvitali
There's a collection of these binary escapes: https://gtfobins.github.io/
tiberious726
My favorite is pressing '!' while inside a sudoed or setuid less.
raffraffraff
Not too mention that you can edit anything you want, like the sudoers file.
akimbostrawman
I would assume sudoedit could have preventing that
more_corn
I once encountered a good anti sudo control. Execute sudo and you get a warning “log in as root instead!” Firstly, no Secondly did you just “prevent” sudo by aliasing it?
teddyh
> They did not invent UNIX but they try harder
I fear that this reference to an old Avis advertising slogan may be lost to a modern audience.
pengaru
Wow, they even used the accurate term "crackers", I feel so old.
gonzo
If enough time passes and we don’t die, we get old.
1984 was 40 years ago.
zahlman
Interesting piece of history. The actual exploit techniques have a real flavour of SQL injection about them.
chrisding
Interesting piece of history.
I had the "joy" of watching some guys from Perforce setup a new p4 instance.
They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening".
It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allows you to give e.g. the Python interpreter CAP_SETUID, making a privilege escalation to root trivial again.