Slashdot Mirror
It's not a Feature, It's a Vulnerability!
pmeunier writes "Apple's security stance is stunning. In the latest (10.3.9) update, Apple removed two capabilities because they pose security risks. One of them is the capability to run setuid and setguid scripts (the other was actually unused). Can other commercial OS vendors (how many are there :) adopt a similar stance? Will you be inconvenienced by the inability to run setuid scripts on MacOS X? Which other features/capabilities (in any OS) would you like to have removed?"
I guess I missed what was "stunning" about this.
Information wants to be anthropomorphized.
It's all about looking at the trade off of system security vs. robustness. I don't know about SetUserID but if it makes my Mac less secure and doesn't allow my applications to do anything I need them to then shut 'er off.
The OS is already built with abilities to SUDO applications so perhaps Apple will figure out a more secure way of implementing the SetUserID feature so as not to create a vulerability. If they have to have it, then it probably needs to a an Admin level tool anyway.
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
Personally, this doesn't affect me, but I see it as a reasonably smart move. Really, the only 100% effective way to seal a vulnerability is to take away whatever caused vulnerability in the first place. I'm sure there's a workaround so you still have the same functionality with some other, more secure, method.
Then again, I've never used this, I have no idea what I'm talking about, and I'm just exercising my Slashdot right to be opinionated!
Elmo knows where you live!
hmm.... while setuid is often used as a bad hack to avoid learning proper programming methodology ( like priv sep ) I'm not sure i like that they've taken it away completly. I prefer freebsd's approach ( but then... how often is that not true ? ) of making you mount the file system with a 'setuid' flag before you can run setuid scripts on it. since most apple users will never touch fstab ( or whatever their xml equiv is ) this would be a better approach.
Sitting Walrus Blog
Thank god for applications like Netapp, which keep a readily availble copy of most directories in '$PWD/.snapshot . This has saved my ass a dozen times...
94% of Repubs and 21% of Dems voted to renew the Patriot Act
Um, how about an explanation on what setuid and setguid actually does first, and then I'll tell you if I'm stunned.
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
It'd be nice.
Will you be inconvenienced by the inability to run setuid scripts on MacOS X?
Not at all. SUID scripts are a huge hole. See What security problems exist with SUID scripts and programs? for an example. SUID scripts are usually created by lazy people who can't be bothered to figure out permissions.
Which other features/capabilities (in any OS) would you like to have removed?
I'd like to see the instant-flamewar generator removed.
The functionality was a mistake to include in the first place. I don't remember precisely WHY this is, but I have read that it is simply impossible to make a secure SUID/SGID script in any current flavor of Unix.
Taking it out will undoubtedly inconvenience some folks, but it's sort of like being given a power tool without some critical piece of safety gear. Apple has, in essence, forced you to install that gear on your power tool, like it or not. If it inconveniences you, then you weren't using the tool safely to begin with.
From what I understand, it's usually better to use sudo for this anyway... you can set up sudo so that it will only allow you to execute a particular program or set of programs. The sudoers file is more than slightly cryptic, and it's a bit more typing (both "sudo" and possibly the user password), but this will give you much better safety.
If you just absolutely can't stand doing it that way, then write your script in perl or C and SUID that version. Note that it takes special care in both instances... SUID programs are dangerous, and if someone cracks a user account on your system, that's going to be one of the first things they'll look at to try to get root. Don't just toss something together, go look up how to do it safely. (short form: don't trust your environment, don't trust user input). Perl has some special functions just for this purpose, so be sure to read its documentation carefully.
Speaking of suid vulnerabilities, http://www.frsirt.com/exploits/20050123.fm-iSink.c .php is an exploit of the mrouter hole (an overflowable suid app in iSync) which allows local root access. Exploited in January, still unfixed in April.
Severity of course depends on how your system is used.
Most (all?) Linux distros don't all this, either. Not sure where this happens, if it's bash or something deeper.
/etc/shadow. You shouldn't have any troubles doing so.
If you want to play, try making a script owned by root, which modifies something a normal user can't. Set it SUID (chmod u+s filename). Run it as a normal user. Shouldn't work (except on older OS/X).
Now, try setting vi or a copy of it SUID. (Again, make sure root owns it, and "chmod u+s filename".) Now run it as a normal user, and, say, edit your
Now that you're done, get rid of those suid files so nobody else uses them.
-Uberhund
...unless you build your own shell from source.
seems like a "good thing" to me.
I've now installed the update on 3 of my macs. The only real issue so far has been that one machine needed it's printers reset. On a "more annyoing" note, the update added an insane number of unwanted bookmarks and bookmark folders to Safari (NY Times, Mac.com, Amazon, eBay, etc.). I can't remember this happening after the installation of previous Safari updates. I hope this isn't a new trend.
How would something like ping be handled ( I don't use OS X )?
Only applies to scripts, not to compiled executeables. So it wouldn't matter at all.
--
$tar -xvf
Ping is an application, not a script. Applications can still be SETUID but scripts cannot. Not being able to run applications SETUID would cause loads of hassles I suspect. But not being able to run scripts SETUID just keeps lazy scripters from doing stupid things that could compromise their systems.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
And, since they did this, everything feels snappier!
It didn't take long before it was obvious that setuid scripts were a REALLY bad idea, and they've been backed out of one UNIX version after another. this isn't a matter of redefining a feature as a bug, it's a matter of asking "what took you so long?"...
Whoever approved this story should be ashamed of themselves. There's more than enough REAL news that matters...
I take it you haven't actually used Safari in a looong time. "COMMAND-/" toggles the status bar on/off.
Now, here's what ticked me off. They changed the "View Source" command from "COM-OPT-V" to "COM-OPT-U" for no apparent reason. That one had me really stumped for about 3 seconds this morning. Damn you Apple!!!!!
Something to think about is that anyone with root (on a Unix-esque system) can make a system insecure. This doesn't just apply to Unix, however. Anyone with super-user access to a system can demolish the security of any operating system, however. There are just too many things that can be done to leave nearly any system wide open.
There are also more than a few reasons to intentionally make a system insecure. Perhaps the system is part of a trusted network, with limited physical access. In that case, system security does not really matter much. Security also didn't matter much when the Internet/DARPAnet was designed -- a time and place issue.
While eliminating SUID/SGID scripts is probably a pretty good idea, I definitely want to retain the ability to make my own assessment of security and make the requisite changes to my system. Maybe there's a really good reason to have a TFTP, RSH, or Telnet server on a system.
Like I said, removing SUID/SGID scripts is probably a good thing, but I definitely want developers to be as cautious as possible in how they remove features. Perhaps rather than completely removing certain features, they should be disabled by default. My fear is that if this catches on with other developers, we could end up with quite a few systems like MacOS pre 10, where there is a definite lack of configuration (and hacking) options.
Don't get me wrong, I'm not bitching. Rather, I'm simply pointing out how this can go awry if it's unchecked.
-Turkey
Internet Explorer.
I rarely criticize things I don't care about.
Apple has not disabled suid. They have disabled suid scripts, a technique inherently unsafe. It is not possible to write a suid script in a secure manner. It is _difficult_ to write a secure suid binary, but far from impossible.
they do, clearly. There are just too many examples of features dropped between releases of operating systems to pick only one.
Will you be inconvenienced by the inability to run setuid scripts on MacOS X?
no. It was a mistake that the feature was ever included. You should SUID/SGID binaries, not text files or anything else. Scripts are not binaries.
Which other features/capabilities (in any OS) would you like to have removed?
Can I vote for eliminating the ability of any OS to create annoying, non-standards-supporting web pages that use too much Flash and/or Javascript ? Can I prevent any OS from sending out spam email ? Can I remove the ability of a compiled application to crash the machine? No? Too bad. In any given system, there are a lot of features that aren't really needed and can be either a source of confusion or a source of problems. Most of these shouldn't be in the OS layer, and ( like the SUID issue ) should be tightened up if they are in that layer.
Fundamentally, though, the SUID/SGID thing referenced in the story is a non-issue. If I have console access, typing "sudo" and a password isn't even an inconvenience. It's already been pointed out that this feature has already been removed from almost every other major Un*x variant, including Linux.
The problem with suid scripts is the mechanism for implementing scripts. Essentially, a script is an executable beginning with (arg is often left blank). When you run it, is translated by the kernel to which is then executed. If the script is setuid, then logically the interpreter should be setuid.
Suppose then that you have a bash script
Linux fixes this (if you turn on setuid scripts) with the
I hereby place the above post in the public domain.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that.
Generally out of cron, which runs them as user oracle in a vanilla controlled environment, not whatever random or malicious environment some user running the scripts externally might set up.
. Instead, we'll get something worse: people writing binaries that SUID and execute any random shell script
Like sudo? For interactive work Mac OS X already has a mechanism to do this more safely, and for batch... well... if they're not already doing it for Linux systems that don't support setuid scripts, and didn't do it for UNIX before the brief life of setuid scripts, why would they start now?
1. It's not an important feature.
2. Even when it's used for what it's there for, it's being misused.
3. No competent sysadmin counts on it being there. Ever.
4. Most "real" flavors of *nix threw it away a long time ago.
If Apple is open to criticism, it's for not chucking it sooner.
Apple added a kernel switch for suid/sgid on scripts, and leave it off by default. If you want suid/sgid scripts on your system, enable them. If you don't think this comment has given you enough information to enable them, you shouldn't be running suid/sgid scripts.
echo 33676832766569823265328479713269.8639857989Pq | dc
Which other features/capabilities (in any OS) would you like to have removed?"
Windows, all flavors, TCP/IP.
Bzzt. If you depend on such things, you should have your badge revoked. Setuid on scripts is a horrible hack, because the execution mechanism of shell scripts allows users to tinker with the internals of the suid resource.
This should never, ever, ever be allowed.
One god, one market, one truth, one consumer.
I think that anything that makes a sysadmin's job more difficult should be reconsidered, as it requires a sysadmin to be more effective (which is uncalled for). Everyone who has ever worked in a job that is not as a sysadmin should know that making a sysadmin's life easier is way more important than the thousands of people they represent. Everyone knows that in any company that the IT department can be counted on being the top dollar earners. I have already made a list of excuses for my lack of efficacy, and this update that I had all of the computers automatically install has just taken precedence over some of the best excuses I have used to shirk off actual work.
No, it's a bug, according to Dave Hyatt, author of Safari.
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
AIX supports it, up through at least 5L (last release I used).
You might have been using a system that used the "suppress suid/guid" mount option.