Linux Kernel Bugs 307
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!
Where's the Gartner Group? (Score:1, Troll)
Re:Where's the Gartner Group? (Score:2, Funny)
open source (Score:2, Interesting)
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.
Re:open source (Score:2)
So enough people is defined as the minimum amount of people required to eliminate bugs between two kernel releases, aka, a few weeks?
Mathematically speaking, the less time you allow for bug discovery, the more, a lot more, people looking at the code you need. As you limit to 0 time for every bug discovery, you limit to infinity of people required, its asymptotic
Ofcourse there'll be undiscovered bugs, until all code is mathmetically proven correct.
Ofcourse undiscovered bugs will remain dangerous, for as long as we use dangerous languages (C, C++, etc.)
Re:open source (Score:2)
What other languages would you suggest for kernel development?
And Java is not immune to these issues. Consider for a moment what languages Java's VM is implemented in. How many bugs are lurking in the Java VM (or the Lisp interpreters, or Perl interpreters, or PHP/Pythn/Tcl/Tk)?
Blaming the language is a cop-out. It's akin to blaming the failure of legislation on the English language.
Re:open source (Score:2)
Common LISP (Vapour [sourceforge.net]), Java (JavaOS), etc.
And Java is not immune to these issues. Consider for a moment what languages Java's VM is implemented in. How many bugs are lurking in the Java VM (or the Lisp interpreters, or Perl interpreters, or PHP/Pythn/Tcl/Tk)?
A lot less. The number of bugs in a N systems written in C, is at least a function of N.
The number of bugs of N systems written on top of a LISP, Java, or other interpreter is a function of 1 (Constant). This means that eliminating dangerous bugs is constrainted, and is a finite process.
Blaming the language is a cop-out. It's akin to blaming the failure of legislation on the English language
Blaming the language for allowing expressability of illegal things is not a cop-out, its legitimate criticism. The best/cleanest/most-powerful way, is often to not allow the mere expression of illegal/unauthorized things. As safe languages don't even let you express illegal (crashing) code, and pure capability systems don't let you even express unauthorized requests.
Re:open source (Score:2)
But most modern C++ code does not do bounds checking, and still uses a lot of char*'s.
In theory, a C++ library that does bounds checking and a lot of other safety-measures can be written, but it can never garbage collect (in a real way, not conservative), and manage memory automatically, meaning that dangling/illegal pointers will always exist in C++.
C++ is still unsafe, deal with it.
Re:open source (Score:2, Informative)
For me personally, I sleep well at night knowing that I run Opensource OS'es at home and at work. What about you? I for one do not trust that the money a commercial OS costs give me peace at mind with respect to security.
This is so typical (Score:3, Funny)
Hope the irony isn't lost on you...
Re:This is so typical (Score:2)
I completely agree with this post, and think that no doubt in the next few days Linus will make a posting like MS have and tell everyone how they shouldn't be looking for security weaknesses in Linux and how publishing them is completely naive in the same way that MS so wisely have.
If only the Open source community could learn from MS - and their wonderful server MS IIS ( Internet Infection Server ), codename Swiss Cheese the world would be a better place.
2.2.x where x=19 also vulnerable (Score:3, Informative)
Karma? what's that again?
So, do we get a 2.2.20 from this? (Score:4, Interesting)
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?
Re:So, do we get a 2.2.20 from this? (Score:2, Informative)
I am sure Alan Cox will deliver a 2.2.20 soon, as he is still in charge of maintaining the 2.2.* kernel series. I saw a while ago an 2.2.19-ac*, but Alan has not been in a hurry to reach 2.2.20. But now, he definitely will be.
Curious... (Score:3, Interesting)
...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.
Re:Curious... (Score:3, Informative)
Okay, okay.... (Score:2, Insightful)
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.
Re:Okay, okay.... (Score:3, Insightful)
It will hopefully make Linux users a little less complacent (and smug) than before.
In your dreams. As a Linux user, I'm smugger than ever. How can that be? Well, let's see: a huge bug is found in Linux kernel. Did anyone write an exploit that pur millions of Linux computers in jeopardy? No. Did a malicious worm get released and wreaked havoc on the Internet? Um, no. Did this bug cause ANY inconvenience AT ALL thus far? Um, no. And it never will. Why? Because 1) a patch was made instantly available, and 2) generally, Linux people have enough common sense to stay up to date with kernel patches. Sho why the hell shouldn't I be smug?
Re:Okay, okay.... (Score:2, Insightful)
Anything like this, on NT or Linux or whatever OS you use is a pain, and a definite inconvenience.
Certainly, as it's a local exploit, the danger level is lower, but what if there's a Linux admin who hears about this a day after their users do? Think of the average student faced with the opportunity to become root. I'd have taken that chance!
The reason you shouldn't be smug is because people who care found this first, and this isn't a remote exploit.
Tom.
What the hell is this invalid formkeys crap??
Firewalls are good for you (Score:2)
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.
Most security exploits are local exploits! (Score:2)
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.
Re:Okay, okay.... (Score:2)
That's as Far As You Know. Anybody could have acquired this information and used it w/out your knowledge. What was that story a couple of days ago where the german government was considering moving to linux partially because they feared backdoors in MS code?
(/steps off conspiracy theorist soapbox)
Hooray! (Score:2, Offtopic)
This means there is at least a year's moritorium on stupid "Microsoft-is-insecure" jokes. :)
Hardly..... (Score:2)
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.
Re:Hardly..... (Score:5, Informative)
Now, don't get me wrong, some of these holes should be an embarassment to the respective development teams. Hopefully with XP and in the future Microsoft will step up on security issues from a software design level. However, from a response level, they are doing an incredible job.
Re:Hardly..... (Score:2)
"Hopefully with XP and in the future Microsoft will step up on security issues from a software design level"
You know, replace "XP" in that statement with "[latest MS OS]" and you get something people have been saying for close to ten years now (right up there alongside "hopefully the next version of Windows will be stable". Ten years. I remember people saying it when Win95 came out. And when Win98 came out. And when WinMe came out. How patient should consumers be??!? Is it OK to wait ten years for "the basics" like stability and security? There comes a time when people need to stop saying "hopefully the next version...", realise the pattern, and just give up on the company. Microsoft has had a LONG time now to "prove themselves", and they still haven't. The fact that people have been saying that for so long and not given up on the product is evidence of a distinct lack of alternatives.
Re:Hardly..... (Score:2)
Yup. And now that most boxes will probably go unpatched - there will be thousands of systems for which the exploits work exactly as they should as well!
Oh yeah, SURE, --YOU-- might have already applied the patch, but anybody reading Slashdot is part of a vastly outnumbered minority.
Luckily this isn't remotely exploitable... (...but then again...)
Still. I have these little rules...
Any bug in software is there forever.
Patches only fix systems that get patched.
Assume your software is dangerous; I keeps you aware and it's probably true.
2.4.12-ac3 (Score:4, Informative)
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 [kernel.org]
Next, patch it up to 2.4.12-ac3:
2.4.12-ac3 [kernel.org]
Finally, apply these two patches to 2.4.12-ac3 to yield 2.4.12-ac3+hogstop+eatcache
Hogstop+Eatcache [lwn.net]
This is currently the ultimate in Linux VM performance.
Re:2.4.12-ac3 (Score:2, Interesting)
2.4.12-aa1, or even better 2.4.12-pre3aa1 (Score:5, Interesting)
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.
Re:2.4.12-aa1, or even better 2.4.12-pre3aa1 (Score:2)
As an aside, I think that competition and in-fighting is very healthy for Linux. I think OSS is like Winston Churchill. In war it stands out as a very adaptive and competant leader. In peace it meanders about from one faux-pax to another.
Re:2.4.12-aa1, or even better 2.4.12-pre3aa1 (Score:2, Informative)
In the meantime, here's one post..
Success report.. [iu.edu]
aah.. here's the one I was thinking of:
VM benchmarks.. [iu.edu]
Re:2.4.12-aa1, or even better 2.4.12-pre3aa1 (Score:2)
I do note that the aa patches weren't included except as Linus's iterations, but I am glad to hear the news.
Re:2.4.12-aa1, or even better 2.4.12-pre3aa1 (Score:2)
http://kt.zork.net/kernel-traffic/latest.html
These are well-written summaries of the kenel traffic, posts to the linux kernel developers mailing list. archived, searchable, and fully linked. Quite the handy shortcut to useful content on getting those kernels up to date....
"Only" a local root exploit (Score:5, Insightful)
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.
Re:"Only" a local root exploit (Score:2)
Guess what, I'm not real worried about this bug. I suppose it's time to upgrade the kernel anyway, though - it's been a few months. Wake me up if someone finds a *remotely* executable bug with any of my customized Linuxen. 'Till then, Windows' are *still* less secure than Linux.
NT Terminal server (Score:2)
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.
it still isn't possible (Score:2)
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?
Not quite (Score:4, Informative)
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.
Re:"Only" a local root exploit (Score:4, Informative)
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.
Incorrect on both counts.
Since at least windows NT server 4.0 you have had something called Terminal Server which gave remote users the ability to log on to your server and run applications (and with recent incarnations it is in a manner much faster than xwindows too). Windows NT 4.0 (regular) also had the ability to run programs as different users (through a bit of a trick), and this trick was turned into a real feature in Windows 2000 with the "run program as a different user" option. Windows XP was just the first one to allow a logged in user to keep all of his programs running while he is "logged out". I had a utility that I used to run on Windows NT 4.0 called "su" (and you can guess what that does) which allowed me to run any program as a different user.
And besides, being able to have multiple simultaneous logged in users has no relevance to the ability to have root exploits. As long as you have user privilege levels you can have root exploits.
Terminal server is something different (Score:2)
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.
Re:Terminal server is something different (Score:2)
You obviously have no idea what you're talking about. Terminal server is no such thing. The entire kernel of the O/S is loaded once, and once only. For example on Windows XP The only program that is loaded per user is explorer.exe (I just checked). On terminal server the only things that are loaded per user is rundll32.exe, display.dll and explorer.exe. Where did you get the idea that it's reloading the entire OS?
(which explains the huge amount of resources required per user).
It's best to use things before giving wild accusations. Having another logged in user on Windows XP here just took a whopping 6MB of more resources...
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.
Have you ever used any Windows NT system? What do you think Administrator rights are for? Have you ever run policy manager? group policy manager? There are more than a hundreds rights that you can configure in the system. That's far more than I can recall every seeing in any *nix based system, but I don't make wild accusations about things that I don't know about...
Re:Terminal server is something different (Score:2)
(etc)
When I talk about rights I should rephrase, I'm talking about security settings.
There are many, many things.
Check out gpedit.msc (just type it in like that to run it), secpol.msc (overlaps with gpedit.msc), rsop.msc (has/creates a redundant backup of the master policies). You can check out secedit (just run "secedit") that'll explain about security policies and how to give an easy way to tighten down your system. There are also under the registry just about everywhere, and also every single object in the system has an ACL (access control list) attached to it (including every registry key). So you could, for example, say that you are the only user allowed to use the second IDE channel or the first USB port, or even the CMOS timer. IT's pretty cool. Go to sysinternals [sysinternals.com] and checkout the winobj program that shows you all objects in the system and you can change policies on them and do more stuff (be careful, you can royally fsck up your system!)
These are in all Windows NT/2K/XP systems and some are even in the 95/98/ME series as well (but not many).
Re:Terminal server is something different (Score:2)
You are correct, I just did another check. However the act of just logging in a second time causes a commit increase (this measures everything) of just 4.5MB, running your shell causes an increase of about 8MB in top of that. Point is that the majority of the system is not recreated for every login, and it is nowhere near a gross hack.
And perhaps those 100+ rights in Windows NT are the cause of all the insecurities
(soap box mode on)
I don't doubt that the fact that NT is far more complicated then linux (and perhaps more complicated than it needs to be) is part of the reason for the bugs, but as was just proven Windows is not the only OS that has bugs. They all do, to varying levels of severity. Without being able to see exactly what the cause of everything is I cannot comment furthur, however having a more complicated system is not much of an excuse for bugs, IMHO, you should just have more complicated testing measures.
And the majority of those rights/security settings are set secure from the start and have absolutely no need to be looked at, much less modified.
Don't forget that Windows was designed from a pleasing-the-user point of view. Things were setup lax because if they were setup more tightly users would have compained that they couldn't do things without changing settings. You're never going to please everyone. People said that they wanted to be able to install, run this, click 3 buttons and host a website, so that is what was created. I'm not absolving them of responsibility, I'm just saying that a lot of it is unwarranted. You don't get to be the biggest software company, one of the biggest companies, and the richest person in the world by unfair business practices alone. And lest you all forget, everyone's friend and linux's last-best-hope for survival 30 years ago was in almost exactly the same position that MS is in now. And why do you think they are doing it? Do you think they are doing it because they love linux or hate Microsoft? No. They're doing it because it makes buisiness sense. They believe that they can make money off it it, that they can sell more expensive hardware, and that it will strategically help their position. And you better believe that if they don't, their support will be gone like that (snap).
We are in a capitalist society ladies and gentlemen. Everything is in name of the almighty buck. Thinking that you can/do become a great company by just good business practices and being nice to everyone alone is naive and will get you belly up very shortly. Giving away software and selling support will also get you belly up, sooner or later.
what's an MSCE to do?
(the MSCE is to) Get a clue. Any MSCE worth the training they went through should easily be able to maintain a server properly. It's not brain science. You cannot blame Microsoft (entirely) for people who, with 2 months notice, were unable to take 5 minutes to run a patch on their system. If *nix users took that long they would have a huge problem as well. My W2K server has been online now, as of this moment, for just over 200 days straight. No reboots, no service pack 2, and no patches. And guess what? Because I had the scruples to tighten down the security from day 1. Code red and Nidma and everything had no impact.
I have a serious question for Microsoft dislikers out there. Put aside your hostility for a second and please give me some constructive ideas on exactly what you would like Microsoft to do? (other than things like drop dead, stop making crappy software, etc, etc)
Windows NT has always been multi-user (Score:2)
- 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.
local exploit is enough (Score:2)
- 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).Re:"Only" a local root exploit (Score:2)
So, your response is "What's the big deal? Surely you trust the people you allow onto your box!" The correct answer is the same as above.
Never underestimate the creativity of the bad guys. Someone will take this exploit and combine it with others and gain remote root. We will all look back and smack our heads for missing his obvious combination.
Re:Tell that to university sys admins (Score:2, Informative)
Re:Tell that to university sys admins (Score:2, Informative)
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
Just another reason (Score:2, Offtopic)
Linux 2.4.12 conspiracy (Score:2, Offtopic)
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".
Why this is(n't) funny (Score:3, Flamebait)
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....
Re:Why this is(n't) funny (Score:2)
Re:Why this is(n't) funny (Score:2)
Code Red was based on an exploit discovered almost six months before it came out... that was the point I was trying to make...
According to the rating I guess that I wasn't quite clear on this....
More info on the matter. (Score:3, Informative)
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$
#
Re:More info on the matter. (Score:2, Informative)
Maybe I'm kinda stupid but running the exploit did nothing, even changing the sample code to be more 'expresive'....
What am I missing? (Score:2, Interesting)
$ 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?
Mac OS has never been exploited over a network (Score:2, Offtopic)
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.
Re:Mac OS has never been exploited over a network (Score:2)
Re:Mac OS has never been exploited over a network (Score:2)
The MacOS according to bugtraq has never had a single exploit over a network.
MacOS 9.2 came into the picture after this statement. It was a blanket statement that was wrong.
Admittedly the bug was found quite recently, but I would expect that if a person adds "according to bugtraq" that they would at least do a little research on bugtraq.
Read before you post. Preferrably comprehend too...
Re:Mac OS has never been exploited over a network (Score:2)
Yes it has, according to some different posts here. In any case, a server with 0 market share will probably not attract many exploit-writers.
Running Webstar on MAc OS 9.2 or older, any versions, is the safest most secure platform.
It may be safe and secure exploit-wise, if there really are no exploits, but is the false sense of security worth moving to a distant OS with few advantages and a large amount of disadvantages? I say false sense of security, because different less-used code is just as exploitable, the only difference is the motive.
Instead of a backdoor every month or two like competing OS's, it has never had a discoverred exploit, or been hacked.
Actually, OpenBSD doesn't have a backdoor every month or two.
It is because the mac has no command line, no paths, no concept of root (all code is root, except micro kernel)
That's quite a contradiction.
all code is root is probably the worst security set up one could conceive, and as far from the principle of least privelege as possible.
no way to exec code from data files based on file name or file suffix
As if this is the problem with Windows security
no way to corrupt stack easily (call chain different than intel)
That's a system platform issue, not an OS issue. Linux can run on the same stack.
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.
That doesn't resolve the problem at all. In fact, probably most buffer-overruns do NOT result from null-terminated string usage.
There are many more secure things dealing with CGI, alias paths, etc.
You're confusing different with secure. Different software will have different types of exploits, unless it is truly secure. Last time I checked, Macs were not an orthogonal persistent pure capability system, so they're not really secure.
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.
Just like a lot of people use Slackware with their own compilations and compilation flags, so their software is different. Its not security, its a difference. It means exploting it takes some specific work, rather than exploits for the masses, that's all.
Thank goodness.. (Score:2, Funny)
"Only a local root" (Score:3, Insightful)
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
Re:"Only a local root" (Score:2)
In *nix (and Windows, ofcourse), there are millions of requests one can request, and a bug in any of each will open security holes.
In pure capability systems, the only requests you can express, are the ones you are authorized to perform.
This means that security is a lot more fail-closed, because bugs do not escalate your authorization, except for specific capability-handing logic bugs.
This narrows down the amount of code that can damage security by orders of magnitude, and simplifies the system a lot. No longer will race conditions, ACL test failures, buffer overflows, or other cryptic bugs grant authorization escalation. Now it would have to be high-level capability-granting logic bugs. In a much smaller, well-debugged system, of a fixed-code-size (rather than the ever-larging *nix trusted codebase).
It's been an off week for open source. (Score:3, Interesting)
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.
Re:It's been an off week for open source. (Score:2)
It is explained well in "The Confused Deputy" article.
Mac/Win/*nix security systems are truly a failure.
Interim Fix? (Score:2)
Re:Interim Fix? (Score:2, Informative)
It's actually a kernel bug, and I'm told that any suid binary can be a vector. The temporary fix is to chmod -s all suid binaries on the system until it can be properly fixed.
Re:Interim Fix? (Score:2, Informative)
cd /
find . -perm -4001 -uid 0
(this isn't quite complete - if you had a file which was suid root, owned by a non-root group and group-executable, that would also be vulnerable)
Work-around without rebooting (2.2 kernels) (Score:4, Informative)
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).
Linux to hackers: Don't publish code (Score:2, Funny)
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."
Disturbing Disparity in tone of News Posts (Score:2, Interesting)
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.
Re:Disturbing Disparity in tone of News Posts (Score:2)
Ahem (Score:2)
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
Oh shit... (Score:2)
What a piece of shit! (Score:2, Funny)
(sarcasm, you fool)
Not the only local exploit (Score:2, Informative)
Re:Huh? (Score:3, Insightful)
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.
Re:Huh? (Score:3, Insightful)
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.
I may be wrong but... (Score:4, Insightful)
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.
Re:Huh? (Score:2)
Re:Huh? (Score:2)
(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)
Not a good reason. (Score:2, Interesting)
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.
Re:Not a good reason. (Score:2)
Viola.
Re:Corps moving back to NT, then? (Score:2)
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.
Re:Corps moving back to NT, then? (Score:2)
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. :)
Re:sucks to be a guy named Torvalds right now... (Score:3, Informative)
And I think you're seriously underestimating Mr. Torvalds.
Re:sucks to be a guy named Torvalds right now... (Score:4, Informative)
Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.
We released updated kernels yesterday:
Re:sucks to be a guy named Torvalds right now... (Score:2)
- make sure to add details on your hardware, as it's not a generic Tulip problem (I've just tested mine - no problems).
Re:Difference between this and the IIS holes (Score:3, Informative)
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.
Re:What is a Good Mailing List for this Info? (Score:5, Insightful)
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 [redhat.com], and sign up for redhat-watch-list.
Re:local DoS is no big deal, is it? (Score:3, Funny)
Szo
Re:local DoS is no big deal, is it? (Score:3, Funny)
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.
Re:well... Duh... (Score:2)
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..)
Re:well... Duh... (Score:5, Insightful)
'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?
Re:well... Duh... (Score:2, Insightful)
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...
Re:well... Duh... (Score:2)
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.
Re:well... Duh... (Score:3, Informative)
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
Re:Why not try the following! (Score:2)
(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)
Re:What, no bias? (Score:2)
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.
Re:will a preemptible kernel solve the dos problem (Score:2)
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?