|
|
Potential warning: 10.3.9 disables SUID/SGID flag
This is probably one of the most bizarre changes I've ever seen in an OS.
Potential warning: 10.3.9 disables SUID/SGID flag
SUID shell scripts are essentially SUID shells. Hardly retarded, just getting OS X up to speed with the rest of the world.
Potential warning: 10.3.9 disables SUID/SGID flag
I don't get what you are trying to say. In what sense is a suid shell script equivalent to a suid shell, any more than a suid binary that you have write permission on is a suid shell? If you can't write to the command, then you can't change it, so a suid shell script can be as secure as any other command. If you can write to a suid binary, then you can replace it, for example, by copying a shell on top of it, so a suid binary can be as insecure as any script.
Potential warning: 10.3.9 disables SUID/SGID flag
All it takes is one setuid script that can be modified by you or that points to a binary you can overwrite and you can be compromised.
Potential warning: 10.3.9 disables SUID/SGID flag
Y'all are missing the point. It's not that writable, setuid scripts are insecure, it's that writable, setuid commands, of any kind, are insecure. Take /sbin/mount_nfs, which is "setuid Mach-O executable ppc" on my system and I assume on everyone's : if you have write permission on that file, you can overwrite it with /bin/sh and you'll have a suid shell. If you don't have write permission on it, then you can't. The situation with a setuid script is exactly the same!!.
Greg Shenaut
Potential warning: 10.3.9 disables SUID/SGID flag
You all seem to be forgetting that this particular security hole was closed a long time ago. Whenever a setuid file is opened for writing, by anyone, the setuid bit is dropped. The owner must then chmod it to get the setuid back. This prevents someone from performing the attack you just described.
Potential warning: 10.3.9 disables SUID/SGID flag
Right, you're obviously angry about this change.
Potential warning: 10.3.9 disables SUID/SGID flag
Allowing setuid scripts is extremely dangerous. Look at the following session
What is happening here? I'm logged in as jeremyp and although I'm using 10.3.9 I have the flag set that disables the new behaviour. In the directory I have a file called foo.txt which is owned by root and not writeable by me (jeremyp). There is also a root setuid script which I am going to use to compromise foo.txt. Assume somebody else set both of these up. I cat the setuid script looking for a suitable command to attack and find it makes use of ls so I set my path to look in . first and create an alternative version of ls that performs my skulduggery. Then I run the setuid script and hey presto, the read only file is hacked. Obviously, in real life I could and should defensively program the setuid script so that it is not vulnerable, but there may be other less obvious holes. At University, for instance, we discovered that, in BSD 4.2 sh if you changed the IFS variable to contain a "p", the word "export" looked like "ex ort" which meant that virtually any script you could name, setuid or otherwise, started with an invocation of a text editor. In a root setuid script that meant you had the ability to write to any file you like on the system. Edit: Added line break... |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.13 seconds |
|