Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

/bin/sh: the biggest Unix security loophole (1984) [pdf]

tuhs.org

Post reply on HN
Print view View original

31–40 of 57 posts

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#31

Post by randomname93857 »

noinsight wrote: post #25
jeroenhd wrote: post #22

Earlier quoted context omitted.

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 dir…

> 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…

>> 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.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#32

Post by 0xbadcafebee »

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.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#33

Post by 0xbadcafebee »

gonzo wrote: post #12
pengaru wrote: post #6

Wow, they even used the accurate term "crackers", I feel so old.

If enough time passes and we don’t die, we get old. 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.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#34

Post by somytomy »

mixdup wrote: post #27

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 f…

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.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#35

Post by mixdup »

somytomy wrote: post #34
mixdup wrote: post #27

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 f…

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 as…

Yeah, this kind of memo and process probably still exists at places like NASA as well

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#36

Post by NewJazz »

mingus88 wrote: post #14
supriyo-biswas wrote: post #3

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.

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…

Why were they applying patches? And what were they patching? What were the consequences when you busted them?

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#37

Post by calvinmorrison »

adrian_b wrote: post #20
fph wrote: post #17

Earlier quoted context omitted.

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…

So, basically all my sandbox concerns go away if I run as root and every browser runs as its own user

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#38

Post by mingus88 »

NewJazz wrote: post #36
mingus88 wrote: post #14

Earlier quoted context omitted.

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…

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...

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#39

Post by saagarjha »

supriyo-biswas wrote: post #3

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.

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.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#40

Post by noinsight »

randomname93857 wrote: post #31
noinsight wrote: post #25

Earlier quoted context omitted.

> 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…

>> 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.
Post reply on HN