Slashdot Mirror
Linux Kernel Bugs
Armin Herbert writes: "According to this mail from Rafal Wojtczuk and a german article on Heise Online, there's a new severe bug in all Linux Kernels, from 2.2.0 up to 2.4.10, which allows users to become root on your system.
Kernel 2.4.12 fixes this problem, and RedHat, Caldera and other distributors already supply patches for their Kernels. See Bugtraq for more information." Important notes for anyone running a multi-user system. Update: 10/19 16:12 GMT by J : If I'm reading Nergal's writeup correctly, 2.4.10 is still vulnerable to the local DoS, but not to the local root exploit. Separate issues. And as
pheared points out,
there is one unverified report of a custom 2.4.12 being vulnerable as well; please try the exploit on your system and let us know what you find. This is a big one, you can expect the kiddies have already added this to their rootkits. Update your systems now!
I always hear people saying how great open source software is, because they can look through the code and fix any bugs themselves.
But I've always wondered exactly who's looking through all this code? Apparently not enough people if a bug this big has lasted this long.
I used to bulls-eye womp-rats in my pants
This happens all the time? When will people realize that Linux is inferior and unsecure. Everyone knows that open-source peer-review is a lousy tool for security-audits. No, why doesn't everyone run Microsoft products? They're completly secure and doesn't have any problems at all. Because that's the power of closed source.
Hope the irony isn't lost on you...
Additionally the 2.2 'superstable' series are also vulnerable. Better get out those patches on multi-user systems and be snappy too. Don't want to look like an M$-admin now do we? :D
Karma? what's that again?
Karma? What's that again?
I'm aware that the exploit is within ptrace and not newgrp itself but...
...the SecurityFocus notice uses newgrp as an example of a program from where the hole can be exploited and it states that most Linux distributions default with newgrp suid root and world-executable. Call me odd, but I'm not sure I understand why a sysadmin would want newgrp to be world-executable.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Strangely, I think that this is a good thing. It will hopefully make Linux users a little less complacent (and smug) than before. Okay, the avaerage user isn't going to trawl through the kernal source (hell, I wouldn't!), but maybe they'll get more involved with the full develoment of Linux - that includes QA, bug-fixing, not just writing of crappy Tetris clones.
One thing I'm looking forward to is finding out how many lazy people there are out there who don't patch their systems..... much like with NT and the easily fixed holes that lead to Code Red.
Tom.
Oh arse
This means there is at least a year's moritorium on stupid "Microsoft-is-insecure" jokes. :)
Sometimes it's best to just let stupid people be stupid.
If you're going to run 2.4.12, I suggest adding the latest Alan Cox patch to it, as well as Rik van Riel's "hogstop" and "eatcache" patches.
First, start with the base 2.4.12 kernel: (Use a patch to save Kernel.org's bandwidth, if you have a recent 2.4 kernel lying around.)
2.4.12
Next, patch it up to 2.4.12-ac3:
2.4.12-ac3
Finally, apply these two patches to 2.4.12-ac3 to yield 2.4.12-ac3+hogstop+eatcache
Hogstop+Eatcache
This is currently the ultimate in Linux VM performance.
Well it's not exactly a remote hole. The user still needs to have execute privs on the system they want to root out.
The "laughing" at MS's security holes isn't necessarily about how easiy it is for a user to gain administrative priveledges, but how easy it is for anyone anywhere to gain remote admin privs.
Not that I'm saying your comments are completely without merit; a hole like this should have been spotted sooner IMO (though I don't know how obvious it was). I'm also not blind to the fact that remote exploits have been found on Linux systems/services.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Before screaming, please remember that this is only a local root exploit, that is you must already have logged in on the machine as non-root before using this exploit.
Most Unixes have had dozens of (sometimes known) local root exploits for years, and while most of them have been ironed out, some surely remain. They are much much harder to eradicate as exploits directed to network services (i.e. from the outside) are. Every once in a while one is discovered in most UNIXes (often obscure race conditions etc).
Till a few years ago the saying was that you should never give a local login to someone who you would not trust to be root, i.e. one could assume that sooner or later those that really try to become root shall succeed. Any mission critical servers should not have any user accounts for untrusted people; therefore, local root exploits have never been considered to be a big deal.
If you want to compare to Windows: up till Windows XP it wasn't even possible to be logged in as multiple users at the same time, so the equivalent of a local root exploit was not really possible. Still, Windows managed to have multitudes of the way more stupid and serious class of remote exploits. With the advent of Windows XP the concept Windows kind of becomes multi-user for the first time (though in a very crude way, since unlike UNIX/Linux each login session almost starts a new instance of larger parts of the operating system). While this new concept is 30 years old in UNIX, only now Windows (XP) starts having the possibility of local exploits. Surely many of them will exist and it will take decades to kind of iron them out.
not to use Microsoft software ... oh, but wait
signature not found
Read the thing. The ptrace hole is very similar to one in *BSD last year. Pretty much everyone screws up when it comes to this sort of volume of code.
Well, I only "Admin" of a very small network and when I started out with Linux (nearly 2 years ago) I thought: updating a kernel?!? Oh, no! I'm sure I'll never be able to do that! :-)
Ehm, well, some nice evening, when I had a lot of spare time, I downloaded the latest kernel and only read the README (or was it INSTALL???) and compiled/installed and was running my own custom compiled kernel.
No, an Admin worthy of the name should at least be able to read the (provided) docs and type at the command line. The Linux-kernel people really made it easy to compile your kernel IMNSHO. Honestly, even an NT-Admin must be able to read the docs otherwhise he woudn't know that, for example, after Windows asks it's original CD you have to re-apply your service-packs.
I admit, between Linux and Windows the environment changes, but the ability to read the instructions is needed everywhere as an Admin (and dare I say, as a normal user too!)
Besides, any sane admin has a production and testing environment....so compiling the kernel on prod machines should only be done after extensive testing.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Warning !
This is not true !
Don't upgrade to Linux 2.4.12.
Linux 2.4.12 is a satanic linux version which will control your mind and your computer.
You can easily see this on the version number,
for 2.4.12 means 2+4 . 2*6 = 6 6 6 - THE NUMBER OF THE BEAST.
DON'T UPGRADE.
If you scan the kernel sources you will see other satanic messages like "Inode" an anagram for DEOIN the 32. commander of baalzebubs forces, "semaphore" an anagram for SHAPOMER the 6. servant of azmoziel and "kernel threads" an anagram for "LAD SHENK RETER".
Or do I need to deploy these patches myself? What's the policy for ass-nasty bugs in superstable kernels which have already reached their official end-of-development?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
To all the people that feel really good about this because they are sick of microsoft being attacked about this: Good for you, you deserve it, enjoy because it won't happen again this year ;-)
;-)
Now to all the linux zealots here: To make sure that this doesn't become a problem we NEED to patch EVERY machine we can find and tell EVERYONE that has a linux box to patch it, why? because NOW it's funny, there isn't a worm out with a remote exploit of GPM that triggers an error Identd to give away your "Games" password so you can log on and become root
but we must make sure that this disappears ASAP or else this sure as hell won't be funny anymore. PLEASE make sure that we won't get staroffice macro virusses, sircam 4 linux etc... THAT we will be the laughing stock of the entire software world... I'll bet that microsoft competetion management (r) is already producing FUD on this....
Fighting for peace is like fucking for virginity
Well put. If a comparable NT exploit were available you can bet the Slashdot
editors and readers would have been quick to drag MS over the coals. But since
this is a Linux love-fest, we just get a pointer to the fix, and probably later
some rationalizations as to how this points to the Linux's superiority, or how
this is really minor anyways. Reminds me of arguments I used to foolishly
engage in with creationists; anything that supports their argument is treated
as scientific evidence, while anything contradictory is dismissed out of hand
or ignored completely.
In case many of you don't subscribe to bugtraq, there was a follow-up posted to the original advisory. I have replicated it here for your convenience. It raises an important issue, suggesting that kernels up to 2.4.12 may be affected as well. I don't claim to know, just forwarding the facts. Note that, he is using a patched kernel which could introduce any number of flaws, but I'm willing to give him the benefit of the doubt.
/* begin shell session */
./epcs_ptrace_attach_exploit
/* end shell session */
Original Message:
From: Demitrious Kelly
To: bugtraq@securityfocus.com
Subject: RE: Flaws in recent Linux kernels
The description of the second problem is accurate, but I don't think the
assessment of the kernels which can or cannot be affected by this exploit
is... I'm using a newly compiled kernel Linux 2.4.12-grsec-1.8.3.
( Linux 2.4.12 with the Grsecurity Patch
http://www.grsecurity.net/features.htm )
#
[12:52:11][apokalyptik@home:~]:
bug exploited successfully.
enjoy!
sh-2.05$
#
Huh. Lookit that. The "boys at Red Hat" put out an update before this story even appeared on Slashdot.
And I think you're seriously underestimating Mr. Torvalds.
The MacOS according to bugtraq has never had a single exploit over a network.
Running Webstar on MAc OS 9.2 or older, any versions, is the safest most secure platform.
Instead of a backdoor every month or two like competing OS's, it has never had a discoverred exploit, or been hacked.
It is because the mac has no command line, no paths, no concept of root (all code is root, except micro kernel), no way to exec code from data files based on file name or file suffix, no way to corrupt stack easily (call chain different than intel), no way to creat buffer overruns from strings because most ac people and the ROMS, and OS, use length delimited pascal style strings instead of null terminated.
There are many more secure things dealing with CGI, alias paths, etc.
But in summary, the US ARmy uses MAc web servers and most experts agree, that the most secure server, if price is not an issue, is a mac from a local store and Webstar.
Admin may not know how to upgrade a kernel? How the hell did a person who cannot download the updated .rpm or .dep file and type in a simple package management command get to be an admin of anything other than an Atari 2600 or a Vic-20?
Even a dolt like me knows how to do 'chmod 700 newgrp' as superuser-- which will make one of these exploits a lot harder to do since it requires a SUID binary to be world-exec. And as soon as patched kernels show up, I'll be able to type 'apt-get update' on all my Debian systems, and 'pftp ftp.domain.com; get new-kernel.rpm; rpm -uv new-kernel.rpm' on my RH/YDL systems.
I do not have a signature
Somewhere deep inside the comments on both sides that start comparing linux to microsoft are missing the fact that most linux users are on average more technically savvy, expecially if they are connected to the big old net. So obviously, when linux announces a security hole a majority of users who are attached to the web get concerned and go out immediately and update thier system.
But when companies and home users are running a COTS that they prolly didn't even install and don't even no what say IIS is, they don't get real concerned about updating thier systems.
For an example, look at Code Red Infections that occured after the security hole had been announced.
I need a TiVo for my car. Pause live traffic now.
Does this mean if you have a shell account on the server that this exploit can be used?
Yes.
If this exploit is run, can it be traced back to the user who ran it?
If process accounting is being used, yes. On the other hand, the user could just "fix" the logs after gaining root.
Does the ptrace command come installed as default on all distro's?
It's a system call, not a command, so yes - it's part of the kernel.
Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.
We released updated kernels yesterday:
And here i am trying to remember my password for root..
Any good University setup doesn't allow regular users login-level accounts on critical servers. Students should have accounts on lab machines, and servers used for remote access, email, etc. but not on the web server, database servers, etc. While you may think that your ability to logon to the the "server" is a great honor, realize that the only use for that server is so people can login remotely to a common machine, the real servers are (or should be) locked up real nice like.
Mad Software: Rantings on Developing So
Errr? Terminal server? Telnet? Stuff available since NT4. Which is already phased out. Bashing is fine, as long as it is done by the facts, not by made up poop.
Never underestimate the relief of true separation of Religion and State.
In the Log On to Windows dialog box, type your user name, password, and domain (if required), and then click OK. The Remote Desktop window will open and you will see the desktop settings, files, and programs that are on your office computer. Your office computer will remain locked. Nobody will be able to work at your office computer without a password, nor will anyone see the work you are doing on your office computer remotely.
What WinXP are you talking about?
How we know is more important than what we know.
I understand that you may have intended your post to be funny. I can't mod it up as so, but I still want to say my piece just in case you were actually serious.
The ratio of M$ insecurities to Linux insecurities is still quite high. I still stand by the fact that "Microsoft-is-insecure".
This insecurity appears to have been discovered before it was largely exploited. Unlike M$ insecurities which are exploited and systems compromised before M$ figures out that the exploit even existed.
Once again, the open source peer review system works as it should.
(remark aside: why do I get these 'key' errors?)
I got that on an earlier post, too. I figured it was a result of the flood of postings to a "something wrong with linux" message from the over-zealous linux fans and the over-excited linux-bashers. The new slashcode seems to have been buckling just a little under the tremendous loads that are placed on it... (not that I could quickly write anything better, mind you)
I am working on a project to port IIS over to this effected kernel
I'm seeing a lot of comments like "This is only a local root exploit", or michael's "Important for anyone running a multi-user system."
That's crap. This is a big deal. Don't try and downplay this. If you leave this unpatched, it turns every remote login hole into a remote root hole. There's plenty of code running remotely: mail, cgi, etc. Good security isn't foolproof. Good security is defense in depth. That means that you are patched against remote holes, and patched against local holes, so that escalation of privileges is difficult.
--sam
--sam
Any technology distinguishable from magic is insufficiently advanced.
Mac OSX also got a remote root exploit of its own.
I don't know whether it's ironic or not that the introduction of open source software led to the first Mac-based remote exploit that I can remember in a long, long time. I'm leaning against it as code's still made by humans and humans still make mistakes. You'd be well-advised to remember this and temper your flames against Any OS That Isn't Mine next time.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
Can someone recommend a good mailing list for linux issues? I am using mostly RedHat boxes, but they don't seem to have any free mailing list that I can find (perhaps they have one i don't know about).
Go to our mailing list server, and sign up for redhat-watch-list.
If you have stupid and malicious users, ulimit is your friend. And process accounting. And a baseball bat.
Szo
Red Leader Standing By!
As it happens, *I'm* a sysadmin for a university.
If you think students have login accounts on our
database servers, you are frickin' insane.
Students get accounts on the academic systems,
which are set up solely for them to play on.
They are not let into the administrative systems
that actually run the school; we keep tight
control over who gets to log into those.
Chris Mattern
NT boxes have different types of user. Sure, only one can be logged in at once, but an exploit which allowed a normal user to gain Administrator privilidges is _exactly_ the same as a local root exploit. And yes, these have existed in the past, and probably still do.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
I am currently running 2.2.18 out of necessity (VPN patch that's not available for 2.2.19). From the article it would seem that until patches are available for your kernel, you can remove the suid (chmod -s) from the newgrp binary. Granted, you won't be able to add any new groups, but I think it would temporarily remove the exploit. Am I correct here?
Praying for the end of your wide-awake nightmare.
Hmmm, according to the LWN that you linked to, aa patches have the best performance.
For those that don't know aa stands for Andrea Archelangi who one of the very importent kernel hackers. It was a large part of his effort that stabalized the 2.2 VM. Although it is debated on which VM is better, over 90% of the benchmarks I've seen have pointed to AA being the better choice.
AC even mentioned that the AA-VM was the right way to go, just too wild of a change for a stable kernel series. There is too much conspiracy theory going on that AC is hijacking the kernel for RedHat, or that the RedHat crew has a not-invented-here phobia for not including the better VM.
Now on to a more editorial comment.
There seems to be quite a war on this right now, but I think it will settle down in about 6 months or so like the ReiserFS wars have. I also think that we'll see a new order established in the stabalizing of kernels.
I have no political say, but I expect that Linus will run a kernel that will be considered the "experimental, quicker evolving" kernel where things change violently. AC and others job will may to pull out pieces to salvage a semblance of stability, essentialy forking the stable branches from Linus's more exotic cutting edge kernel.
This seems to be how things run in any case when there is a developmental kernel, and they run pretty well. The question that may be asked is "Does Linus need to slow down his effort to stabalize at all?" Its arguably true that the answer is "yes", but only to a degree that suits his own needs for order in his life-long persuit of the sexy kernel.
Linus himself mentioned that AC does a better job of it, maybe its time to give him the whole forking-a-stable-kernel job.
This is not a distribution bug, but a kernel one. From the article: "In order to exploit this kernel vulnerability, one needs a setuid root binary which execs an user-defined binary (or a shell). Newgrp is appropriate on most distributions." There are other programs that match this description. It doesn't make sense to make only newgrp non-suid and then think that you're safe.
By the way, does anyone know in what kernel version (-pre,-ac) *exactly* the bug is fixed? I can't find relevant "ptrace" fixes or Rafal Wojtczuk's name anywhere in the changelogs.. I guess I should run the exploit to find out whether I'm vulnerable.. (another good example that full disclosure is useful..)
There's a loadable kernel module that
replaces the ptrace() function call with
a wrapper that makes it impossible to exploit
this bug. It can be found from
http://c.home.cern.ch/c/cons/www/security/.
Works on 2.2.19, not tried to use it with 2.4.x yet (should be pretty easy).
In a recent article on CNet:
This week, Linus Torvalds, manager for Linux's security response center, published an essay on the company's site decrying the information and example code released by some companies and independent security consultants as "information anarchy."
"It's high time the security community stopped providing the blueprints for building these weapons," Linus wrote in the essay. "And it's high time that computer users insisted that the security community live up to its obligation to protect them."
"The state of affairs today allows even relative novices to build highly destructive (malicious software)," he wrote in the essay. "It's simply indefensible for the security community to continue arming cyber criminals. We can at least raise the bar."
"(We) don't purport to have the answer to the problem," he said in a Wednesday interview. "But we believe that these practices are harmful."
Things you think are in the Constitution, but are not.
'Cause no local user ever needs to run passwd.
Or df.
Or ping.
Or xterm.
Or rlogin.
Or su.
Or top.
Or traceroute.
A completely secure machine is a painful thing to work on. Yes, it may be necessary in some circumstances. Banning world executable setuid programs is a securing technique, but it's not the blessed saviour you're making it out to be.
Parallels a situation many governments are facing right now: How much security do you implement to protect your population while still maintaining some semblance of freedom?
If you find bugs, please put them in bugzilla.
- make sure to add details on your hardware, as it's not a generic Tulip problem (I've just tested mine - no problems).
- If you want to compare to Windows: up till Windows XP it wasn't even possible to be logged in as multiple users at the same time
This is incorrect.Windows NT, of which Windows 2000 and XP are but new iterations, has been multi-user from the start, even though it has lacked the shell counterparts to easily exploit it without resorting to C or C++. For example, the Windows NT Resource Kit comes with a "su" program.
The NT user API design is heavily based on ACLs, which means, for example, that you can create threads, pipes, files, synchronization objects, etc. and restrict access to users with certain permissions. I'm no Windows fan, but they got this part right.
- to turn a buffer overflow of a non-privileged nework daemon into a remote root exploit;
- to allow unprivileged users to sniff the LAN;
- to allow 'viruses' (.i.e. executables from an unknown source which a luser run without checking) to have full access to your machine
This is a serious bug (though not a new kind of bug: as you said, local exploit have been with us for years), because it undermines the basics of Linux security model (every user stays in its box).Ciao
----
FB
I find the tone of this post to be part of a disturbing, if subtle, trend.
I know this isn't new ground to tread in these forums, but the respective tones of posts about Microsoft bugs and Linux bugs are worthy of change.
When there's an MS bug, the posts generally read something like... "User writes, "Here's a big surprise. There's a bug in IIS that lets any six year old root the box. Excuse me while I gasp in surprise. Exploits are here and here. Cnet has the whole story." It's amazing that people still rely on IIS... I wonder when people will stop making their software choices entirely based on FUD."
When there's a bug that eluded many major kernel revisions, the post reads: 'Apparently there's been a bug in the kernel for months that yields unauthorized remote access to root. Huh. Users of multi-user systems might want to patch this when they get a chance.' -- and it's on to the next story.
Disparities such as these, subtle as they are, affect Linux communities' credibility. It makes us look immature because we appear to apply a double standard. It's a chink in our armor we should patch ASAP.
You should not have world exec programs set suid
/etc/passwd world writeable, let normal users construct their own IP packets and so on. Removing functionality in the name of security is not an acceptable option, especially when the functionality is this basic.
This is plainly not true. Programs like newgrp (and passwd, chsh, chfn, login, ping, su and others) require root privileges but are there to be run by users. The alternative is to either remove huge swathes of functionality or let arbitrary users switch their UID without any sort of authentication, have
The above is not informative. newgrp does not add new groups - it allows a user to switch their current group, asking for a password if necessary. It is explicitly designed for users to run, but also requires root privileges. In other words, of course it's SUID and executable by all, you idiots. That's the entire point. People will be calling for passwd to be non-SUID at this rate...
(Of course, this becomes less of a problem once capabilities are present at the filesystem level and we can explicitly launch applications with certain capabilities rather than launch them as root and then drop any they don't need)
That's odd... I've grown used to any Slashdot posting about privilege elevation exploits being condescending and insulting.
:)
Perhaps people complained about dozens of them a month being such, but their existence in ACL systems is recognized as inevitable.
Where are the accusations of carelessness on the part of the programmers?
Again, nobody would bash Microsoft programmers for an occasional bug. But that's simply not the case at Microsoft.
How about the shots at the intelligence of the administrators?
Now that's utter bull. Shots at the intelligence of admins? How is it relevant here?
People refer to the stupidity of Windows admins after a second worm using the same exploit successfully spreads itself, even though a patch has existed long before the first one.
When a successful worm uses this exploit successfully, then it would be relevant to call Linux admins idiots.
Oh, this is a Linux bug? How convenient....
How rare, too
I'd continue to rant, but I have a worm to write.
Yeah, and how will it spread, exactly?
Anyhow, if you could, it would be a nice test of Admin stupidity, and my guess is that Linux admins would pass the test - thus your worm would Fail.
My name is Scottissue Pulp and I'm the Manager of the Linux Security Response Center and I'd like to take this opportunity to decry this
"Provided by the management for your protection."
Oh shit! Now Gartner is going to recommend that I switch all my servers back over to NT.
How about accessing shadow password files? Since you don't want your /etc/passwd (or your shadow password file) writable by your average user, how does a non-suid passwd program work?
Please refer to documentation that explains the difference between real and effective user ids.
The message to which I was replying made no indication what OS he/she was speaking in reference to. I was examining my FreeBSD, HP-UX and Solaris machines. My point was not Linux-specific (if that is the OS to which you are referring).
Once again, I believe you're confusing real and effective user ids. Furthermore, this (AFAIK) depends on the restrictions the OS places on the access to system resources.
Once again, I think this point depends on the OS and the implementation of top, and the permissions on devices such as /dev/mem and /dev/kmem (depending on your OS).
Finally, something we can agree on.As I indicated in my first post, depending on your circumstances removing world executable setuid binaries may be an option. For example, on my firewall. This doesn't necessarily make for the most user-friendly system.
I look forward to your response...
$ uname -a ./ptrace-exp ./insert_shellcode 24982
Linux limbo 2.4.0 #8 sat jul 21 14:24:48 CEST 2001 i686 unknown
$ id
uid=1001(johan) gid=1001(johan) groups=1001(johan)
$ gcc insert_shellcode.c -o insert_shellcode
$ gcc ptrace-exp.c -o ptrace-exp
$
attached
exec
$ id
uid=1001(johan) gid=1001(johan) groups=1001(johan)
So what's up?
It would seem that preemptible kernels would allow kernel functions to be written to take arbitrarily long times, and only the calling process is hurt by this. This would avoid the DoS attack, but more importantly I would think it would make a lot of kernel stuff much easier to write and the code much easier to read and debug.
So do any experts in kernel design think this, or am I totally wrong?
And a baseball bat.
Shh! Not so loud! My boss still thinks that a LART is a sophisticated piece of network analysis hardware. I never told him that the bills we get for replacing broken LARTs come from the Louisville Slugger Company.
That's "Mr. Soulless Automaton" to you, Bub.
(sarcasm, you fool)
Terminal server can't be compared to a multi-user system like UNIX. It may look the same at first sight, but in fact it is more like VMWare, in the sense that a large part of the operating system is instantiated for every user that "logs in", that is each user has almost a private copy of the operating system (which explains the huge amount of resources required per user). This is a gross hack, and WinXP multi-user logon is based on the same technology. It can't be compared to a true multi-user operating system such as UNIX.
Indeed (as someone also remarked in another response) one could compare getting admin-right on a flie as equivalent to a local root exploit. Still, it is not the same. It only applies to file-access rights, not to executing processes with other permissions.
Maybe this is a little over simplifed, but still its a local exploit, either a login or a server running localy. whats the difference between telnet/ssh over a machine loop, a serial cable/modem dialup, a ethernet, or from the internet, it's still a executing the shell localy.
Apocalypse Cancelled, Sorry, No Ticket Refunds
There is absolutely NO REASON for you to have passwd suid-root.
/etc/passwd rw-rw-rw-? How do you propose passwd is able
/etc/passwd and /etc/shadow without running as
You have your
to change the contents of
root?
Ping??? Ummmm.... NO. It can send and recieve packets fine and dandy
as an unpriveleged user.
How do you propose a user without root privileges gets the kernel to
generate ICMP messages and send them to arbitrary hosts? Hint: you
don't. Root privileges are required.
XTERM???? Goodnight, that's most insecure thing I've ever heard!
XTerm used to be SUID to be able to add entries to wtmp and utmp
(perhaps you'd like those to be world writeable as well?) and change the
ownership of the device node associated with them. Nowadays it's more
traditional to make it SGID instead.
When an xterm starts, it opens up a shell for whatever user it's running as.
When a SUID xterm starts, it makes entries in utmp and wtmp and alters
the device node permissions. It then executes the shell as the user.
Feel free to test this.
By taking the MCSE exams.
Sad, but true. The concern is that the Gartner migrants may re-migrate back.
That said, the MCSEs of the world should be forced to get real jobs, you know, at Burger Thing or someplace they can put their talents to good use. :)
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
You have to figure out which machines have untrusted users. Fortunately, this particular case is a local-only exploit; so if you're a sysadmin of a large system, then it's time to take it down.
However, this is also where having a good firewall can save you much heartache. The firewall itself is by definition a system with untrusted users (unless you can guarantee you've never been broken into), so needs to be patched. If you have unprotected systems, all of them need to be patched.
Keep all your systems behind a well-designed firewall, and these decisions become much, much easier.
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore
This article appeared on stepwise.com, a site devoted to Mac OS X (so yes, Macs *are* vulnerable!") http://www.stepwise.com/Articles/Admin/2001-10-15. 01.html
[posted 18-Oct-01]
>>
Mac OS X 10.1 Local Security Exploit
A serious security exploit has been found in Mac OS X 10.1 (in fact, as it turns out, it has been present in 10.0.x versions as well). Using this exploit any user at the Desktop can gain root access to the machine.
The problem is caused by applications that are set-uid root (that is, regardless of the user that runs them, they have root permissions). Normally these programs have a limited scope of functionality so that damage is minimized. However, it appears that any items launched from the Apple->Recent Items menu inherit the root user privileges. Additionally, any other apps in the Apple menu (i.e. System Preferences) can be launched as root using this hole.
This can be demonstrated using the following technique:
[See URL above for more details]
So obviously, Linux isn't the only one that has these kinds of problems. And to that thread commenting about Mac OS not having problems like this -- yes, that might be true for Classic Mac OS, but its obviously not true for the current OS
Every OS that I've used in the past couple of decades has had some kind of "local security exploit". That's just the way it is.
Later,
--Gregory