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.
The only thing that surprises me about that item is that SUID scripts were allowed until now. Most Unix systems don't allow SUID scripts, AFAIK.
Moments before this story appeared, I received the following email:
It is recommended by the Technical Support staff at Banta Publications that the Mac OS 10.3.9 upgrade NOT be applied at this time.
It seems to be causing general problems with a variety of software applications. Once the upgrade is complete, there is not an easy way to remove it.
If you have questions, please send an e-mail to xxxxxxx@xxxxxxxxxxx.com.
Ignorance is curable, stupid is forever.
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
Linux banned suid scripts long ago, and for good. ... instant root account.
suid scripts permit HUGE holes, because it's easy to find a buffer overflow in sh or any other script interpreter and then
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Perhaps you'd rather they just ignore the problem and let you fix it yourself?
Isn't ping still run with setuid to root on most Linux systems?
;)
Wouldn't this make everything unpingable
Yes, was a joke, users wouldn't be able to run ping.
How would something like ping be handled ( I don't use OS X )?
...unless you build your own shell from source.
seems like a "good thing" to me.
lets remove the gui from windows. that will make it far more secure.
and it would be funny to watch all the lusers staring at a dos prompt. (of course port clipy to dos)
You mean, like the developers in the LINUX COMMUNITY?!?!?!?!?!?!?!
And, since they did this, everything feels snappier!
NTFS allows you to store data both in foo.txt and foo.txt:evil, and only foo.txt will be visible in a directory listing. In fact, almost none of the tools that come with the system can see :evil. More info and examples from the nice folks at SysInternals. Spyware creators use this extensively. When you see a registry entries pointing to C:\WINNT\System32:xyzzy.dll, it's time to format and reinstall. I know there are other stupid, half-implimented features in NTFS but I can't think of what they are at the moment.
suid is not something that a normal user would know or care about , this is a wake up call for other developers and script writters to learn proper practice . .
SUID can cause major problems and is a rather large vector for attack
ofcourse i may have missundersrtood you , do you mean developers who shove suid down our throats ?
from an admins point of view , i no more want suid on any system i manage than i want ordinary users having root access
The only things certain in war are Propaganda and Death. You can never be sure which is which though
How about fixing the system call mechanism so that you can't use a non-null byte to make system calls from shell code? The problem (PDF) has been known for a couple of years now. While it won't eliminate buffer overflow shellcode, it will make it a lot harder to write shellcode for OS X.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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...
Which other features/capabilities (in any OS) would you like to have removed?
Macros.
"I assumed blithely that there were no elves out there in the darkness"
I'm sure that both of the Apple users who use this feature were pissed. The rest of us really don't care.
I've never really understood the need for the setuid feature. I always managed to get my programs and scripts to work just fine without it.
It's good to use your head, but not as a battering ram.
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.
One problem with removing SUID and GUID is it'll break management scripts.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that.
So much for that functionality. Instead, we'll get something worse: people writing binaries that SUID and execute any random shell script, like this:
runsuid --script=/usr/bin/my_script --user=root
Gee, thanks.
Why not get rid of the shell while you're at it? That command line is a security problem waiting to happen. And while you're at it, remove process invocation commands like exec. Those can be used to run executables, which could cause Bad Things to Happen.
What a freaking PITA. I mean, if there was a bug in SUID/GUID handling, fix it. Removing it is really drastic. What's next, removing "rm" because it could delete files?
I apoligise i was a bit obtuse , i did rather loosly enfer the fact that it was only for scripts , i apoligise . you are correct in the context of programs ofcourse ... I realy should learn to use preview
The only things certain in war are Propaganda and Death. You can never be sure which is which though
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.
I read through the shellcode example article again (thanks for the link by the way, I was going to look it up again for another project anyway), and I don't see how this is a problem that can really be solved, at least not by Apple.
There is always more than one way to get basically any value you might want loaded into the proper registers. Once the registers are loaded, there's a single instruction that's used to initiate a system call, the "sc" instruction.
The opcode for "sc" ALREADY includes two embedded NULs, so it looks like somebody was more-or-less on the ball there (or just lucky). Unfortunately, current PPC processors don't object if any of the "reserved, set to zero" bits in the instruction are actually set to one.
This is arguably a processor misfeature, and something that Freescale/IBM might want to look at changing in later processors. Actually, I should check this on the G5 - it's the kind of thing that easily could have changed without anybody remarking on it.
I can think of a couple of possible hacky things the OS could do to post-facto validate the code leading up to the sc instruction, but I suspect that'd be very bad for syscall performance. If I get the time, maybe I'll build myself a hacked Darwin kernel and play around with the idea a bit more.
Unfortunately, the first validation measure that came to my mind is easily worked around, so you're back in the usual technical arms race with the bad guys. The only bright spot there is that every additional step the shellcode needs to take makes it longer and more brittle. I wonder if you can make it adequately painful to write shellcode without totally tanking syscall performance?
In any case, as you noted, fixing the case of ASCII-only shellcode is only going to close down some of the available buffer-overflow exploits, not all of them.
-Mark
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?
Of course, we expect that when Microsoft removes a "feature" for "security reasons" it really has to do with the fact that the feature was not adding anything to the bottom line, or buggy.
-- www.WhereHaveIBeen.com
I heard that G5s do object to having those NULs filled in. I don't own one to test it personally, though.
If so,it'd be nice. Those bits are reserved, but that doesn't mean that they should be unchecked.
Slashdot. It's Not For Common Sense
Local Root Exploit
Read the first word. Local. That means in order to be a problem an attacker needs physical access to your machine. If they have physical access to your machine you have worse problems than worrying about root escalation.
Find a better barrow to push.
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.
It's not a vulnerability, it's a feature!
kybred
all of it.
not thrilled about dos either.
seriously, auto-insert for volumes? at least give us a control panel to turn it off. indexing service on by default, all those annoying "common tasks" panes in explorer especially the control panel, the fact that windows media player 9 or 10 always steals back file associations from mplayerc even if you tell it not to and remove the reg keys and delete the damn executables and files (oh they come back, like the damn poltergeist).
Before the stupid m$ rants come in, I use it for gaming, but really would it be that hard to make an "expert mode" for people who half half a f*ing clue what theyre doing? it's called windows xp professional, so you don't have to set it up by default for people without a clue.
Oh, and for home edition try making the default account non-superuser, just a thought.
christ.
The first rule of USENET is you do not talk about USENET.
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.
#include
#include
#include
#include
#define SCRIPT_PATH "/usr/local/bin/whatever"
int main (int argc, char *argv[]) {
execv(SCRIPT_PATH, argv);
fprintf(stderr, "%s: could not execute \"%s\" (\"%s\")\n", argv[0], SCRIPT_PATH, strerror(errno));
}
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.
You don't know what you're talking about, kid.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that. So much for that functionality.
If you had any idea what the hell you are talking about or had even read ANY of this thread, you would know that virtually no one on "other unices" even uses this feature.
Remember when Microsoft removed gopher support from IE instead of fixing a security vulnerability in it?
Phillip
Apple's security stance is stunning.
:) adopt a similar stance?
:-)
Interesting. I don't recall praising MS for stunning security stance when they decided to deliberately break some functionality for the sake of security with the release WinXP SP2. Funny thing, it was spun a bit differently, IIRC...
Can other commercial OS vendors (how many are there
Indeed they should. So we can bash or praise them for it, depending on wether they are MS or not.
The Script I have that loads/unloads the Insomnia Kernel Extension ran SUID. I'd been wondering what broke it, and now that I know, I'm going to have to dig through man sudoers to get it to be run via sudo w/o a password (I usually run it from the scripts menu.)
I guess you could say that I'm effected by this, but I'll get over it. Sudo should be able to adapt, or else I'll just run the script from the command line.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
When have you ever seen a shell script without an invocation line?
Never.
If it was such a problem, why not make the shell disallow execution of scripts without an explicit invocation line?
For those of us who aren't *nix gurus, can someone provide a description of what these scripts do?
"I'm a leaf on the wind. Watch how I soar."
-Hoban Washburn
When have you ever seen a shell script without an invocation line?
Never.
If it was such a problem, why not make the shell disallow execution of scripts without an explicit invocation line?
bash -i is a perfectly reasonable command line. Bash doesn't know that it's being called to run a shell script, it just thinks that it's being called to log a user in. The kernel doesn't know that bash interprets -i this way...
I hereby place the above post in the public domain.
Color me stunned. AFAICR I haven't seen an OS that had set(u|g)id scripting in like 12 years.. Even AIX 3.2.5 had it disabled, and I don't recall it being in any opensource shell interpreter in at least 5 years..
I'd be interested to know which OSes actually support this? It's highly dangerous..
Sigh...missed it grepping for suid and guid. Doh!
Weeee!
Not having "." in the path is to fix a much simpler expliot. As a cracker, make a program called "ls" and make it do whatever you want, assumming it has root privledges, and then leave it in /tmp or anywhere you can write. Then wait for the root user to happen to cd to that directory and type "ls". You are in.
Removing "." removes the one directory from a typical user's path that other users can write to.
It wouldn't have made it slightly harder, it would have made it much harder. Bummer.
Slashdot. It's Not For Common Sense
PINAS?
Full disclosure: I work for NetApp. In the marketing department, even... yuck!
.snapshot directory. Out of the box, to recover a file you have deleted, you do something like this:
.snapshot
.gone directory is needed because the .snapshot directory holds all changes since the snapshot was made; including modifications to files as well as deleted files. For simplicity, it even holds the things that have NOT changed, so looking at a snapshot directory is exactly like looking at a read-only version of the real directory, frozen at a certain moment in time.
But... one of the easiest explanations of how snapshots work is in a ten-year-old whitepaper, located here:
http://www.netapp.com/tech_library/3002.html#I34
Also... I'm not familiar with the $PWD/.gone feature described above; I'm pretty sure that must be a local hack, maybe a symlink pointing to one of the snapshots in the
$ cd
$ cd hourly.0
(or hourly.10, or weekly.4, etc. depending on which version of the file you want to recover)
$ cp myfile ~/projdir/myfile
No separate
Cut down on all of the useless services that Microsoft Windows XP boots up and automatically sets up upon installation of the operating system.
"Instant gratification takes too long." - Carrie Fisher
Apple's launchd should make things interesting.
1115120266