/bin/sh: the biggest Unix security loophole (1984) [pdf]
1–10 of 57 posts
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#2Interesting piece of history. The actual exploit techniques have a real flavour of SQL injection about them.
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#3Loopholes 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.
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#4Loopholes 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.
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...
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#5Interesting piece of history.
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#6Wow, they even used the accurate term "crackers", I feel so old.
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#7Loopholes 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 favorite is pressing '!' while inside a sudoed or setuid less.
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#8Loopholes 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.
There's a collection of these binary escapes:
https://gtfobins.github.io/
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#9Loopholes 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.
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?
Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]
#10Loopholes 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.
Not too mention that you can edit anything you want, like the sudoers file.