Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Potential warning: 10.3.9 disables SUID/SGID flag' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: veloso on Apr 18, '05 05:57:34PM

This is probably one of the most bizarre changes I've ever seen in an OS.

Why disable SUID/GUID on scripts?

Is this Unix or not?

Is there a way to turn this behavior off?

This is so unbelievably retarded that words fail me. What possible rationale can there be for something like this? It's mind-bogglingly stupid.

Heck, why not turn SUID and GUID off for all items? Why not get rid of that shell too, while you're at it. It's a security problem waiting to happen.



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: mattbing on Apr 18, '05 06:18:44PM
SUID shell scripts are essentially SUID shells. Hardly retarded, just getting OS X up to speed with the rest of the world.

vi /mydir/ls
PATH=/mydir some_suid_script_that_uses_ls.sh


[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 06:35:28PM

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.

Set-user-id security is all about using suid commands only when necessary, and protecting access to them. It's not about egregiously disallowing setuid for an entire class of commands.

Greg Shenaut



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: a1291762 on Apr 18, '05 07:36:40PM

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.

eg. change the first line of the script to
#!/mypath/mybadprogram

or find that the script with #!/usr/local/bin/tclsh points to a file you can write to, replace it with your own binary.

In both of these cases your binary is going to be running with the SUID/SGID permissions. Sure, Apple can ship a base system that doesn't contain a flaw but how can they protect against third parties or stupid users? Other Unix OSes have already disabled this feature, Apple is actually behind here.



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 08:01:38PM
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

[ Reply to This | # ]

Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: CoolerQ on Apr 18, '05 08:19:58PM

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.

--Quentin



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: kaih on Apr 18, '05 11:43:56PM

Right, you're obviously angry about this change.
In 25 words, or less, please explain just HOW THIS AFFECTS YOU?

IMHO, this is a great idea, Apple proactively tightening up security in OS X _before_ someone works out an exploit.

---
k:.



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: jeremyp on Apr 19, '05 12:18:43PM
Allowing setuid scripts is extremely dangerous. Look at the following session

jeremyp@titania:test$/bin/ls -l
total 24
-rw-r--r--  1 root     staff  11 19 Apr 16:40 foo.txt
-rwxr-xr-x  1 jeremyp  staff  23 19 Apr 16:29 ls
-rwsr-xr-x  1 root     staff  14 19 Apr 16:28 mysh
jeremyp@titania:test$more foo.txt
not hacked
jeremyp@titania:test$echo $PATH
.:/Developer/qt/bin:/Users/jeremyp/unix/bin:/bin:/sbin:/usr/bin:/usr/sbin
:/sbin:/usr/sbin:/usr/local/bin:/Library/MySQL/bin:/usr/X11R6/bin:/opt/local/bin
jeremyp@titania:test$more ls
echo "hacked" >foo.txt
jeremyp@titania:test$more mysh
#!/bin/sh

ls
jeremyp@titania:test$mysh
jeremyp@titania:test$more foo.txt
hacked

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

[ Reply to This | # ]