[HN Gopher] /bin/sh: the biggest Unix security loophole (1984) [...
___________________________________________________________________
/bin/sh: the biggest Unix security loophole (1984) [pdf]
Author : vitplister
Score : 67 points
Date : 2025-01-08 23:46 UTC (2 days ago)
(HTM) web link (www.tuhs.org)
(TXT) w3m dump (www.tuhs.org)
| zahlman wrote:
| Interesting piece of history. The actual exploit techniques have
| a real flavour of SQL injection about them.
| supriyo-biswas wrote:
| 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 wrote:
| 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...
| lostlogin wrote:
| This is excellent, and while I'm guessing that you could have
| paid, browsed and moved on with less effort, that wasn't the
| point.
| tiberious726 wrote:
| My favorite is pressing '!' while inside a sudoed or setuid
| less.
| denysvitali wrote:
| There's a collection of these binary escapes:
| https://gtfobins.github.io/
| more_corn wrote:
| 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?
| raffraffraff wrote:
| Not too mention that you can edit anything you want, like the
| sudoers file.
| akimbostrawman wrote:
| I would assume sudoedit could have preventing that
| mingus88 wrote:
| 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...
| FergusArgyll wrote:
| That's like a beginner level CTF! sheesh
| chrisding wrote:
| Interesting piece of history.
| pengaru wrote:
| Wow, they even used the accurate term "crackers", I feel so old.
| gonzo wrote:
| If enough time passes and we don't die, we get old.
|
| 1984 was 40 years ago.
| 0xbadcafebee wrote:
| 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.
| nayuki wrote:
| 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
| panki27 wrote:
| 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.
| dehrmann wrote:
| 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.
| fph wrote:
| 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.
| adrian_b wrote:
| 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.
| adrian_b wrote:
| 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.
| anthk wrote:
| Unix 2.0 (plan9/9front) has namespaces.
| jeroenhd wrote:
| 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.
| noinsight wrote:
| > 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?
| timewizard wrote:
| > 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.
| randomname93857 wrote:
| >> 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.
| Vogtinator wrote:
| 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.
| teddyh wrote:
| > _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.
| athrowaway3z wrote:
| >Ritchie is the inventor of the elegant setuid concept, for which
| a patent was awarded.
|
| Do organization still apply for these kind of patents?
| kevindamm wrote:
| I would tell you but that would involve looking at recent
| patents, and I persistently avoid doing that for fear of triple
| damages.
|
| Software patents have changed a lot in the last ten years,
| though, especially after the Supreme Court case "Alice Corp. v.
| CLS Bank" which made it harder to patent abstract ideas
| implemented on a computer.
|
| But until about ten years ago, there were worse than that
| getting awarded patents. Not all of it bad, but most of it
| yeah.
| mixdup wrote:
| 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
| somytomy wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-11 23:00 UTC)