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

Potential warning: 10.3.9 disables SUID/SGID flag System
This probably won't affect many people. I don't think it affects me. But it's one of those subtle things that may bite somebody in an uncomfortable place: the 10.3.9 update disables the SUID/SGID bit.

Files with the SUID bit set are run with the permissions of the owner of the file, not the person running it; ones with the SGID bit run with the file's group. The bits are mostly used for things like the traditional Unix passwd command which lets a user change her password. It solves the dilemma of how to let just anybody modify the master password list, but only in a very carefully controlled manner. Apple says they don't ship any files in the BSD subsystem with either bit set, so, as a security precaution, they've completely disabled this functionality. I can confirm this; I did a quick test before and after applying the update.

As I said, you probably won't be affected by this. You only would be if you've installed some software -- probably through DarwinPorts or Fink -- that depends on this feature. How can you know for certain? Simple. In the Terminal, try this:
sudo find / -perm +6000 -exec ls -lf {} \;
On my system, I do find a few files, including some from Apple, some from Fink, and the usual raft of Unix stuff (ps, dump, ping, route, etc.). But nothing seems obviously broken, so I don't plan to worry. You probably shouldn't, either. But maybe somebody out there should...

Note: As indicated in the comments below, this change only affected scripts. SUID/SGID binaries continue to work as they did before.
    •    
  • Currently 3.60 / 5
  You rated: 4 / 5 (5 votes cast)
 
[14,362 views]  

Potential warning: 10.3.9 disables SUID/SGID flag | 30 comments | Create New Account
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: chrome on Apr 18, '05 10:55:11AM

Hmm, this seems to be a sneaky thing on the part of Apple, if you think about it.

The only times you would use setuid binaries are when you need a way of running a binary as another user, like the article states.

Now, for example, say you are running a mailserver on your 10.3.9 box ... it can no longer deliver mail as the user? Ouch.

It seems to me that 10.3.9 basically destroys the ability to use the OS as a server?

Ugh.

This can't be right ... must be my paranoid delusions.

So, anyway, how do we re-enable setuid functionality?



[ Reply to This | # ]
only for scripts
Authored by: hayne on Apr 18, '05 11:01:18AM

The disabling of setuid capabilities is only for scripts - it is still supported for compiled executables. All SUID programs supplied with OS X are compiled executables and that is why they continue to work as before.

Historically, SUID shell scripts have been problematic due to the fact that their execution involves a runtime interpreter (the shell) and that there has been the possibility for a sufficiently skilled mal-doer to substitute some other instructions for the contents of the script before it starts execution. Even though all known ways for doing this have been prevented in OS X's underlying FreeBSD code, Apple has taken the more conservative and safer route of forbidding SUID scripts anyway. This is not a significant loss of functionality since anyone who is sufficiently competent to write a secure SUID script would likely also have the programming knowledge to implement the same thing in a compiled language.



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: nayr on Apr 18, '05 11:02:09AM

Actually, if you read the notice carefully, they disabled support for the suid/sgid bits on *scripts*, not binaries. So your ping, traceroute, etc., still operate as required. You just can have any shell scripts take advantage of suid/sgid functionality.



[ Reply to This | # ]
A little OT: ..and they still didn't fix the mRouter security bug..
Authored by: franzgranlund on Apr 18, '05 11:11:45AM

From one thing to another (mRouter is SETSUID);

Why haven't Apple fixed the mRouter security bug?

http://packetstorm.linuxsecurity.com/0501-exploits/fm-iSink.c

I've tried to mail them and I also joined their security mailinglist, but the moderator just rejected my message. ("Your message was deemed inappropriate by the moderator.").

It is really annoying when everyone who has an account on the computer can just copy'n'paste some code into a file, compile it, run it and then have "root" access...



[ Reply to This | # ]
A little OT: ..and they still didn't fix the mRouter security bug..
Authored by: jdb8167 on Apr 18, '05 05:07:03PM

It is easy to fix. Just remove mRouter. You can't remove the whole bundle or change the permissions though. If you remove the whole SymbianConduit.bundle, the next invocation of Software Update wants to replace the whole iSync system. If you change the permissions on mRouter, the repair permissions of HD Utility "fixes". But just removing the file, works fine.

A side note, the problem seems to be gone in Tiger since Apple seems to have changed the whole iSync architecture.



[ Reply to This | # ]
A little OT: ..and they still didn't fix the mRouter security bug..
Authored by: JohnnyMnemonic on Apr 19, '05 07:33:28PM

Fixed in Security Update 2005-004; or at least the description of the fix includes text concerning mRouter and iSync.

Apparently, posting the vuln on /. got someone's attention. Too bad it took that, though.


[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: LC on Apr 18, '05 01:27:14PM
Or ... sudo find / -type f -perm +ug+s -ls

[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 02:36:46PM
My opinion: this is really, really stupid. What's next, refusal to accept wildcards in rm(1) commands?

Here's the situation as I see it: you can still use chmod to set the suid bit on any file, including scripts. If you execute #! script, its suid bit is ignored. If you execute a shell script without a #!, then bash & csh ignore the suid bit, but ksh hangs or gives a bus error.

You can still easily write & compile a one-line shim along the lines of

main(){execl("/Users/mylogin/libexec/myscript", "msyscript", 0);}
and setuid on its binary to run "myscript", which can still be a #! script.

Since this is a (minor) hassle, it will lead to the temptation to write a more general script that will allow any program to be run suid; if anyone succumbs to that temptation (and I bet some will do so), the result will be a much worse security problem.

What is gained by this?

Greg Shenaut

[ Reply to This | # ]

Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: timkingman on Apr 18, '05 04:48:44PM

No, you can't use chmod to set the setuid bit on any file. You can only do it on files you own, and thus an unprivileged user cannot create a setuid binary with escalated privileges as you describe. You can create setuid binaries that run as your own user all day long, and I'd hardly consider this a "much worse security problem."



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 05:43:13PM
My point is that the change does not reduce security since it it trivial to get past it, and it may worsen security by creating the temptation to construct a general work-around which would, by its generality, open doors that are now closed.

Here's a ksh script I wrote called "shuid" that restores much of the previous functionality and does not, I think, reduce security:

#!/bin/ksh

LIBEXEC=$HOME/.libexec

err(){
    print -u2 "Err: $*"
    exit 1
}
if [[ "$1" = "" ]] ; then
    err "Usage: shuid script [user [group]]"
fi

if [[ ! -d $LIBEXEC ]] ; then
    set -e
    mkdir $LIBEXEC
    set +e
fi

mv $1 $LIBEXEC
chmod a+x $LIBEXEC/$1

cat >$1.c <<FIN
main(int c,char **v) {
    execv("$LIBEXEC/$1", v);
}
FIN

cc -o $1 $1.c
rm $1.c

U=0
G=0
if [[ "$3" != "" ]] ; then
    G=$3
fi
if [[ "$2" != "" ]] ; then
    U=$2
fi

sudo chown $U:$G $1
sudo chmod +s $1

exit 0
What this does is to hide the actual script away in the user's home directory and replace it with a binary compiled to do nothing but to call the script in its new home. It then sets executable and suid on the binary.

Greg Shenaut

[ Reply to This | # ]

Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: kamath on Apr 18, '05 09:37:22PM

Why not just 'sudo script'?

You can even avoid passwords with NOPASSWD in the sudoers file.

This is not stupid, this has been the case in most unices for several years now. It has to do with a race-condition in the interpreter fireup sequence.

As for making it trivial to circumvent security, why not just log in as root? Or no root password? How about 'chmod u+s /bin/sh'? I've seen them all (I'm not kidding).

Look, the point of this is NOT to make it more difficult for end-users to do something, but to make it possible for knowledgeable people to "do the right thing", like writing wrapper scripts (which, by the way, is *EXACTLY* what sudo is -- it was written because every unix shop on the planet had a 'suid', '.root' or other 'give me root' programs (because no one should log in as root if they can avoid it, as there's no way to track who was root that way) -- a general 'run any script or program as root' program), without allowing "unauthorized" people to do Bad Things(tm). Of course, on a Mac, since it's GENERALLY single user, it's a non-issue. But if you have one admin on a mac, and several unpriviledged users, then setuid shell scripts could allow one of those non-priviledged users to become root -- A Bad Thing(tm). Go google it (try "setuid shell script race condition").

Now, having said all that, it turns out there's a pretty "simple" fix to this, which is to have the kernel pass an already open filedescriptor to the interpreter, which some unices have implemented.

However, to be completely honest, one should avoid setuid scripts as much as possible. You only need them for non-terminal (in the sense of tty terminal, not "Terminal", the mac terminal program (shame on them for calling it Terminal)) applications (as in "ways to do things", not as Mac OS X Applications), such as startup script (which is moot, since they run as root).

Here's the one example I had: I have a web application (php) which controls itunes. For a while (before I found A Better Way), I used a wrapper script so that the applescript would be called as the user running itunes instead of 'www'. (The Better Way, i.e., EASIER, was to run apache as that user, instead of www, since I'm lazy. The One True Way would be to use suexec or the like).



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: MattHaffner on Apr 18, '05 02:44:31PM

Here's a slight modification to the original post to account for the script-only nature of the change:

sudo find / -perm +6000 -exec file {} \; | grep -i script

mh



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: MattHaffner on Apr 18, '05 03:19:58PM

Ooops! I didn't read the important red text about code fragments ;)

There's a backslash missing before the semi-colon in that line:

sudo find / -perm +6000 -exec file {} \; | grep -i script


[ Reply to This | # ]
10.3.9 disables SUID/SGID flag - effects NAV update?
Authored by: hal4sn on Apr 18, '05 05:40:37PM
I wonder if this is why Symantec Norton Antivirus 9.03 LiveUpdate 3.02 is failing with the error "Microdefs error LiveUpdate had an error updating the virus definitions". I ran the command the original posted presented and some of the Nav files were reported:

-rwsr-sr-x  1 root  wheel  15980  2 Nov 05:02 /Library/Application Support/Norton Solutions Support/LiveUpdate/confsetup
-rwsr-sr-x  1 root  wheel  18500  2 Nov 05:02 /Library/Application Support/Norton Solutions Support/LiveUpdate/IRHelper
-rwsr-sr-x  1 root  wheel  11676  2 Nov 05:02 /Library/Application Support/Norton Solutions Support/LiveUpdate/jlucaller
-rwsr-sr-x  1 root  wheel  43544 18 Apr 13:40 /Library/Application Support/Norton Solutions Support/LiveUpdate/LULogger
-rwsr-sr-x  1 root  wheel  56700 18 Apr 13:41 /Library/Application Support/Norton Solutions Support/LiveUpdate/LURegistryTool
-rwsr-sr-x  1 root  wheel  3572  2 Nov 05:02 /Library/Application Support/Norton Solutions Support/LiveUpdate/PatchAppWrapper
-rwsr-sr-x  1 root  wheel  894  2 Nov 05:02 /Library/Application Support/Norton Solutions Support/LiveUpdate/RollbackDefs
-rwsr-xr-x  1 root  wheel  93704 18 Apr 13:41 /Library/Application Support/Norton Solutions Support/
 Norton AntiVirus/DiskMountNotify.app/Contents/MacOS/DiskMountNotify
-rwsr-xr-x  1 root  wheel  72128 18 Apr 13:41 /Library/Application Support/Norton Solutions Support/Scheduler/schedLauncher
Editor: Added a line break...

[ Reply to This | # ]
Verification?
Authored by: sbnoble on Apr 18, '05 05:41:40PM

Has anyone verified that 10.3.9 does in fact break suid scripts?
(This is one of the reasons I wait a week before installing an update.)

For that matter, does anyone know WHY they did it? They cite
CAN-2005-0970, but the details on that appear to be embargoed.

I just find it hard to believe that they couldn't find a better solution
than completely disabling the functionality. Suid script issues, and
solutions, have been known for well over a decade. Is this really
something so radically new and bad, that it couldn't be fixed?



[ Reply to This | # ]
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 | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: pete.yandelll on Apr 18, '05 07:28:51PM

Argh! Why is everybody complaining about this? Every other UNIX under the sun blocks SUID/SGID scripts, and it's about time that Apple followed suit. It's not going to affect anything you do, as nobody produces software that contians SUID/SGID scripts anyway.

And for all those people asking "Why?", did you make any effort at all to find out? The first link if you google for "suid scripts" is this article from Tech FAQ that lists the problems.



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

I followed the link to "Tech FAQs", and it was rather interesting, but only one of the exploits was specific to scripts, the "-i" exploit, and I tried that one with (ba)sh, (t)csh, and ksh, and it didn't work, I never got an interactive shell--probably the shells themselves know about that & block it. Maybe the exploit would work, but you'd have to work a lot harder than I was willing to do.

The other exploits had to do with compiled programs only or with both compiled programs and scripts.

Greg Shenaut



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: vandil on Apr 18, '05 08:02:29PM

Keep in mind, folks:

As much as we may use the Terminal and open source software we are the minority.

The majority of Mac users are graphic artists and prepress paginators.

As long as Photoshop, Quark, and the iLife apps work, they could care less what a "SUID/SGID flag" is or what it was.



[ Reply to This | # ]
Apple is not so dumb after all
Authored by: gshenaut on Apr 18, '05 08:26:06PM
It turns out that you can issue the command
sudo sysctl -w kern.sugid_scripts=1
and get back the old behavior.

Greg Shenaut

[ Reply to This | # ]

This is WRONG and should not have been allowed onto the site.
Authored by: steeviant on Apr 18, '05 09:44:51PM

This hint is WRONG. Apple have not, and will not ever disable SUID/SGID on OS X, they have simply disabled SUID scripts, like almost every other Unix in existence.

What the hell is wrong with this site regurgitating rubbish like this? Does anyone even do a modicum of checking before putting the hints online?

This site is going downhill in a big way, first it gets plastered with ads and now it starts posting rubbish "hints" like this one which states that Apple have made a change which would make it broadly incompatible with other Unix systems, when in fact all they've done is to bring OS X into line with them on a security matter.



[ Reply to This | # ]
This is WRONG and should not have been allowed onto the site.
Authored by: gshenaut on Apr 18, '05 10:01:28PM

I don't agree. It is true that Linux doesn't allow suid on scripts, but many versions of *nix do allow it, for example Solaris & FreeBSD. The reason the hint is valid in my opinion is that Apple snuck in a rather surprising change to the kernel (the addition of kern.sugid_scripts with a default of 0) without announcing it (or if it was announced, no one here saw it). Now that I am aware of the issue, when various scripts I have in various places stop working, I'll know why & what to do about it.

Greg Shenaut



[ Reply to This | # ]
This is WRONG and should not have been allowed onto the site.
Authored by: robg on Apr 20, '05 01:15:35PM

Amazingly enough, I find it impossible to (a) know everything about everything, (b) have enough time to research 100% of those things that I don't know about, (c) keep everyone happy all of the time.

In the case of this hint, I read it, went to Apple's site to read about the changes, found reference to the SUID change, and so published the story. I didn't catch the difference between binaries and scripts -- but that's the beauty of this site. The community did notice, and now I've updated the story with the proper note.

So sorry you're disappointed with my efforts, but really, I'm doing the best I can. And as for 'plastered with ads,' please count carefully. Depending on the time of day, you'll either find two or three. Hardly plastered. Still, if it annoys you that much, blocking them really isn't all that hard ... and if you find the quality has gone too far downhill here, the answer is also easy -- find somewhere else to read about OS X hints. Regardless, I'll keep doing the best I can do, which is clearly never enough to satisfy everyone.

regards;
-rob.



[ Reply to This | # ]