/bin/sh: the biggest Unix security loophole (1984) [pdf](tuhs.org)
tuhs.org
/bin/sh: the biggest Unix security loophole (1984) [pdf]
https://www.tuhs.org/Archive/Documentation/TechReports/Bell_Labs/ReedsShellHoles.pdf
56 comments
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.
For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
Oh yeah? How can I install Clang using Apt without root?
This is largely a package manager problem. There is a way to run Homebrew (the package manager widely used on macOS) on Linux in a rootless mode, and it will install packages into your home directory no problem.
It’s a good trick to have in your back pocket if you’re given an unprivileged user on a compute node and want to make use of modern tools.
It’s a good trick to have in your back pocket if you’re given an unprivileged user on a compute node and want to make use of modern tools.
You don't need to install it with apt
Indeed but the claim was:
> You can in fact run most package managers without root
It is very clear from the context that dehrmann was talking about Linux distro package managers (Apt, Yum, Dnf, Apk, etc.) and as far as I know they all require root, or at least I have never once seen someone use them without root.
> You can in fact run most package managers without root
It is very clear from the context that dehrmann was talking about Linux distro package managers (Apt, Yum, Dnf, Apk, etc.) and as far as I know they all require root, or at least I have never once seen someone use them without root.
I figured most package managers (brew, pip, nix, npm, etc.) are not actually one of the few Linux distro package managers. You listed them almost exhaustively after all (excepting pacman).
Right but as I said from the context it was clear he was talking about distro package managers, not language package managers.
Nix requires root (at least by default). Brew I'll give you - I didn't know you can use it on Linux. Do people actually do that enough that it works reliably?
Nix requires root (at least by default). Brew I'll give you - I didn't know you can use it on Linux. Do people actually do that enough that it works reliably?
I don't think that was clear. If they really meant that, which I honestly doubt because it would be so obviously false, then I agree with you.
> 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.
Clearly talking about OS level package managers.
Clearly talking about OS level package managers.
Unix was very much made for multi user environments. The problem with staying compatible with Unix today is that back when Unix came to be, everyone on the system was more or less trusted. The biggest security concern was making sure that everyone who was logged in was billed correctly.
On succifiently offline systems, you can still run software like that. It's quite freeing to have a server with 777 on your home directory when the biggest problem it'll cause is someone pranking you by altering your terminal color scheme to something hideous.
On succifiently offline systems, you can still run software like that. It's quite freeing to have a server with 777 on your home directory when the biggest problem it'll cause is someone pranking you by altering your terminal color scheme to something hideous.
> Unix was very much made for multi user environments. ... The biggest security concern was making sure that everyone who was logged in was billed correctly.
I don't know about that... It doesn't even support multiple administrators. And you can't even distinguish between actions performed by the system itself and the administrative user.
Yes I know about sudo.
What do you need to do and what do the (even audit) logs say about who performed an activity whenever administrative activity happens?
I don't know about that... It doesn't even support multiple administrators. And you can't even distinguish between actions performed by the system itself and the administrative user.
Yes I know about sudo.
What do you need to do and what do the (even audit) logs say about who performed an activity whenever administrative activity happens?
> It doesn't even support multiple administrators.
You can easily create multiple accounts that have the uid 0. Groups are a fundamental part of discretionary access system and several administrative groups exist by default. Your modern desktop oriented distribution may not take advantage of these facts.
> logs say about who performed an activity whenever administrative activity happens?
Simply enable process accounting and setup a program to capture that information. The early BSD distributions had this and had many command line tools to query the information it stored.
You can easily create multiple accounts that have the uid 0. Groups are a fundamental part of discretionary access system and several administrative groups exist by default. Your modern desktop oriented distribution may not take advantage of these facts.
> logs say about who performed an activity whenever administrative activity happens?
Simply enable process accounting and setup a program to capture that information. The early BSD distributions had this and had many command line tools to query the information it stored.
>> What do you need to do and what do the (even audit) logs say about who performed an activity whenever administrative activity happens?
By activity you mean who run some process? doesn't enabling audit on all execve, execveat and looking at AUID besides EUID and UID fields tell you that? Or am I missing something? you may want to configure ENHANCED format in auditd for convenience.
No, you are right. On Linux you can look at AUID. To be fair, I have no idea about others than Linux.
Multics had much more complex security, with access-control lists.
The authors of Unix have taken most of the concepts of an hierarchical file system from Multics, the main exception being the security features, which have been replaced with the simpler owner-group-all permission bits, together with features like setuid/setgid, which may be OK for simple use cases but which is inadequate for a system with many users, where not all of them can be trusted.
The authors of Unix have taken most of the concepts of an hierarchical file system from Multics, the main exception being the security features, which have been replaced with the simpler owner-group-all permission bits, together with features like setuid/setgid, which may be OK for simple use cases but which is inadequate for a system with many users, where not all of them can be trusted.
Is multi-user use "modern"? Back in the days everyone shared the same mainframe, now I'd say most computer systems have a single user.
While most computers are personal computers, which have a single real human user, you still have to run a lot of untrusted programs, like the Internet browsers or whatever programs you might download from dubious sources.
While perhaps the term "user" is no longer the best, there is a need even more than before to run programs with limited rights, corresponding to the rights of some pseudo-users, which should not be able to access or modify anything belonging to the real human user, unless a special permission is granted.
While perhaps the term "user" is no longer the best, there is a need even more than before to run programs with limited rights, corresponding to the rights of some pseudo-users, which should not be able to access or modify anything belonging to the real human user, unless a special permission is granted.
Android works like this. It's linux based and runs every app as its own user. On top of that it adds SELinux and many other isolation strategies.
https://source.android.com/docs/security/app-sandbox
https://source.android.com/docs/security/app-sandbox
So, basically all my sandbox concerns go away if I run as root and every browser runs as its own user
[deleted]
Shared Web Hosting still uses multiple users.
Unix 2.0 (plan9/9front) has namespaces.
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.
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.
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...
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...
There's a collection of these binary escapes:
https://gtfobins.github.io/
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…
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…
Nobody should ever need permission to edit their own configs. E.g., if a box is used solely as a database server, then the DBAs should have full root to it.
they only needed a backdoor root because you're a gatekeeping dick and they wanted to get their job done without having to "deal" with your shit.
OMG. they applied unapproved patches! to the product they were responsible for making work.
OMG. they applied unapproved patches! to the product they were responsible for making work.
lol, restricting administrative access to the administrators is pretty much a security best practice in every company everywhere.
Ever heard of the principle of least privilege?
They didn’t give me admin in the database and I don’t want it. They aren’t trained in the system and if you’ve ever seen what kind of mess a bunch of amateurs can make of a shared system you wouldn’t sound like such an idiot right now
Ill be sure to tell the auditors that they are gatekeeping dicks for requiring change management on the financial databases
Ever heard of the principle of least privilege?
They didn’t give me admin in the database and I don’t want it. They aren’t trained in the system and if you’ve ever seen what kind of mess a bunch of amateurs can make of a shared system you wouldn’t sound like such an idiot right now
Ill be sure to tell the auditors that they are gatekeeping dicks for requiring change management on the financial databases
that is all true. but admins need to be aware of the reasons other groups desire to go around them. obviously they needed some patches on their database product.
OK, what's the easiest way to get it? option 1: call the IT admin and say "hey bud, can we get these patches and see if it fixes my thing?" or option #2 play some political long game to get sudo vi access via intense political pressure and then hack into the system to install said patches.
if you have to do option #2, then it's the FAULT of the IT system: people follow the path of least resistance. if there was so much hassle having a support organization actually help you such that it was actually easier to do it yourself and fighting (and winning) some political fight with the other dept. to get there, you tell me what's wrong with that support org?
this is why DevOps is an improvement.
you're trying to point at the auditors as being the dicks? nope. any engineer in the company can be equally responsible for configuration management. wanna bet that the IT dept. has no process to allow other engineers to update configuration? or that they won't do it on your behalf in a timely fashion? simply delegate the patch configuration management of the DB to the DBAs and send the auditors to see the experts. there's a good chance they'd take the responsibility seriously and do a better job of it than you.
OK, what's the easiest way to get it? option 1: call the IT admin and say "hey bud, can we get these patches and see if it fixes my thing?" or option #2 play some political long game to get sudo vi access via intense political pressure and then hack into the system to install said patches.
if you have to do option #2, then it's the FAULT of the IT system: people follow the path of least resistance. if there was so much hassle having a support organization actually help you such that it was actually easier to do it yourself and fighting (and winning) some political fight with the other dept. to get there, you tell me what's wrong with that support org?
this is why DevOps is an improvement.
you're trying to point at the auditors as being the dicks? nope. any engineer in the company can be equally responsible for configuration management. wanna bet that the IT dept. has no process to allow other engineers to update configuration? or that they won't do it on your behalf in a timely fashion? simply delegate the patch configuration management of the DB to the DBAs and send the auditors to see the experts. there's a good chance they'd take the responsibility seriously and do a better job of it than you.
Why were they applying patches? And what were they patching? What were the consequences when you busted them?
These were solaris 8 or 9 patches for some Oracle DB. Patch management back then was wild and conflicting patches could cause problems.
Of course there were no consequences for someone bypassing the approval process and doing unscheduled changes as root. Now, if my team had made those changes without running it past the DBAs...
Of course there were no consequences for someone bypassing the approval process and doing unscheduled changes as root. Now, if my team had made those changes without running it past the DBAs...
My high school computer lab had an incredibly incompetent admin whose idea of security was to look through the bash history of problem students and go from there. Anyway, at one point they decided that someone had used cp to copy things to places they should’ve have been (did I mention they didn’t really understand UNIX permissions?) they decided to just remove cp altogether. So of course I made a fake cp (in Java, because that was all I knew at the time) to replace it.
My favorite is pressing '!' while inside a sudoed or setuid less.
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?
Not too mention that you can edit anything you want, like the sudoers file.
That's like a beginner level CTF! sheesh
I would assume sudoedit could have preventing that
Setting aside all of the technical aspects of this, the history of this in the world of UNIX, I just love the process and bureaucracy that generated this specific paper document. The very formal cover sheet (and the fact that it had an accompanying, separate, numbered instruction document), the pre-determined layout and format of a Technical Memorandum, and the fact that this was published as such a memorandum with filing and control numbers that will be researched and looked up in a library instead of just a blog or post on Medium
We used to be a real society
We used to be a real society
Depends where you work. Judging from reading HN, 95% of all devs here are writing webshitapps for companies that don't give a flying eff about development, just profits. I develop embedded hardware for tier 1 automotive manufacturers, and we have to adhere to several ISO standards, and a number of tools for managing documentation and code hygiene. Traceability of requirements, security, functional safety, and risk assessments are associated with every single decision and every single code commit. It is a lot of documentation, but I'm a pedant and I love it. It is a design process for adults, by adults.
Yeah, this kind of memo and process probably still exists at places like NASA as well
> 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.
I fear that this reference to an old Avis advertising slogan may be lost to a modern audience.
It's the same today, only it's webapps instead of unix utilities. Simplest bugs in the world, still devs don't pay attention to them. Simple like not sanitizing inputs, injecting stuff straight into sql queries or exec commands, dumping customer data / passwords / all environment variables into logs and error messages, etc.
Wow, they even used the accurate term "crackers", I feel so old.
Indeed. I learned from reading the jargon file in ~2005: http://catb.org/jargon/html/C/cracker.html , http://catb.org/jargon/html/H/hacker.html
If enough time passes and we don’t die, we get old.
1984 was 40 years ago.
1984 was 40 years ago.
It's nice to know that when I was born, there was a guy just like me, writing snarky annoyed memos about the stupid security holes in our systems.
>Ritchie is the inventor of the elegant setuid concept, for which a patent was awarded.
Do organization still apply for these kind of patents?
Do organization still apply for these kind of patents?
yes. most very large corps. that like to keep patent portfolios will encourage engineers to patent (assigned to the co. of course) anything slightly creative or unusual. or sometimes anything at all that sounds slightly technical.
the engineer gets his name on the patent and maybe a bit of prestige. the org gets another (sometimes bad) patent in the portfolio.
skimming the patent https://patents.google.com/patent/US4135240A/en it seems actually pretty well drafted and pretty good (patentable).
the engineer gets his name on the patent and maybe a bit of prestige. the org gets another (sometimes bad) patent in the portfolio.
skimming the patent https://patents.google.com/patent/US4135240A/en it seems actually pretty well drafted and pretty good (patentable).
[deleted]
Interesting piece of history. The actual exploit techniques have a real flavour of SQL injection about them.
Interesting piece of history.
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.