Slashdot Mirror
2.2.16 Kernel Released - Fixes Security Hole
gavinroy writes: "According to an e-mail I received from the kind folks at Sendmail, Inc., the Linux Kernel versions 2.2.15 and below have a SUID security flaw. "This problem will affect programs that drop setuid state and rely on losing saved setuid, even those that check that the setuid call succeeded." Sounds like a good reason to go 2.2.16 to me - grab it." The sendmail advisory is also online, as well.
Why does Slashdot link directly to the main kernel.org server, and circumvent the absolutely massive set of mirrors that they have setup around the world to save bandwidth and time for everyone?
...
...
Go to http://www.kernel.org/mirrors/ and get the new kernel from there
Hrm, a multiplexor like the CPAN one would be quite cool for kernel.org as well
.. by the predictable responses from people here.
Linux is not secure!
Linux can't be trusted!
Well stop shouting and think for a minute. Security is not a simple subject and there is no such thing as a totally secure system. All you have is more secure systems and less secure systems. IMO, these are the important questions:
Q: Are security flaws like this easier to find in open source operating systems such as linux?
A: yes!
Q: Does this make linux more secure than closed source systems?
A: No!
Q: How many potential flaws exist in closed systems?
A: Nobody knows.
Q: How many more flaws will be found in linux:
A: Nobody knows.
Q: Is linux more secure or less secure than other systems?
A: There is no clear answer. Weigh up the pros/cons of the security records of each OS you are considering, and the areas in which they have had security problems and decide for yourself.
Please people, every time a flaw is found in Linux, people shout "Linux is not secure!" and when its in NT, we hear "NT sux. Linux rules"
and similar for other OS's. Stop it.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
The advisory is unclear, just says versions before 2.2.16. Does this include 2.0.x? 1.2.x? even older versions?
-Yarn - Rio Karma: Excellent
This bug is a part of the new capabilities functions. ;-)
All that is happening is that under some circumstances, SUID programs that try to drop some of their priviliges don't end up droping them correctly, and remain SUID.
This does not open up any more remote exploitable holes, but rather makes it give you root rather then your "nobody" user when you break a program like sendmail that uses this sort of security.
Is this a bug? Yes. Is it remote exploitable? No.
Not to mention, that as far as I know, quite a few other os's don't provide capabilities like this, so they are all as vulnerable as Linux is.. (However, I've never researched this and could be dead wrong, they could all have implemented this ages ago..
Blessed are the pessimists, for they have made backups.
I'm sure you meant "Isn't it nice that Linus released a fix for his operating system right after getting back from vacation, and let me use it?"
It's not your operating system. It's Linus's operating system. He just lets you use it. If you purchased an operating system from a commercial vendor, then your gripe is with that vendor - they are responsible for all bugs and security holes they ship, not the authors. The authors just provide software out of generosity, without warranty, express or implied.
That people think anything else is the bad sign.
I verified the exploit and upgraded all my end-user shell boxes before 2am.
Sendmail did the right thing. Details of the vulnerability were already publicly available, but had been misreported as Sendmail bugs.
The impact is that any local user (local shell access is required) can become root using techniques simular to those effective against pre-v8 versions of Sendmail. I've found two other vulnerable applications, surely there are more. If you can't figure it out given the information provided, good. Just upgrade your kernel.
There is no remote exploit.
I'm getting tired of running patches on top of patches (like the ide/udma patches)
is there a public CVS server that has the kernel so i can do a cvs update (and thus also auto merge)?
Very true, but then again I don't deal with NT - so I don't know much about the security model in place (snort) during a bugfix. All I do know is that a few short months ago I logged into an NT system of mine and figured that it was not worth anything (logged in as guest) started up the ole' M$dog debug program and told the system to low level the harddrive. It did.
Now that is (as Cartman would say) securitah.
Well written comment. I only have a couple of objections to some of your statements.
> Q: Does this make linux more secure than closed source systems?
> A: No!
What it does do is give Linux the *potential* to be more secure (note the emphasis). Patches are released early and often, usually within hours of the security hole being found.
> Q: Is linux more secure or less secure than other systems?
> A: There is no clear answer. Weigh up the pros/cons of the security records of each OS you are considering, and the areas in
> which they have had security problems and decide for yourself.
A system's security can only be judged by comparing it with other systems. No system can be absolutely secure.
So, let's compare it with Microsoft's security model (I know, easy target...). The hole with VBScript in Outlook has been well known for over a year (Melissa was the first widespread exploit). Yet it took until *last month* for MS to *announce* that they intended to release a patch for Outlook. They still have not actually released that patch.
This does lead me to believe that Linux has a far greater potential than NT for having greater security.
In post-9/11 America, the CIA interrogates YOU!
I wrote two little programs to test this; one to test whether giving up privileges works, the other to start a shell with the CAP_SETUID capability removed. To check the bug on your system do:
$ wget ftp://quatramaran.ens.fr/pub/orabidoo/tmp/blep.c. c
$ wget ftp://quatramaran.ens.fr/pub/orabidoo/tmp/suidcap
$ gcc -o blep blep.c ./blep ./suidcap ./blep
$ gcc -o suidcap suidcap.c
$ su
Password:
# chown root.root blep
# chmod 4755 blep
# exit
$
BEFORE: [your-uid] 0
GAVE UP: [your-uid] [your-uid]
GOT BACK: [your-uid] [your-uid]
(this is the expected result)
$
launching shell...
sh-2.03$
BEFORE: [your-uid] 0
GAVE UP: [your-uid] [your-uid]
GOT BACK: [your-uid] 0
PROBLEM!!
If you don't see the 'PROBLEM!!' part, then you don't have a problem.
First of all I would like to point out that the underlying cause of this is that Linux is moving towards having two security models. One is the traditional, "Root is GOD but can setuid" model and the other is "POSIX capabilities". This is a situation where an operation that should have worked under the old but which due to an oversight was insecure on the new. This may not be the last thinko of this sort. OTOH POSIX capabilities are an improvement on the old model so this is good in the long run.
Now why am I saying POSIX capabilities? Well here is a FAQ that goes into what is in the kernel. The traditional definition of capabilities are used by, for instance, EROS. This is incredibly secure. So when the POSIX standard was being developed for improving security by borrowing VMS' "privileges" they deliberately called them "capabilities" to introduce confusion and make people think they were better than they are. (Not that they are not an improvement on the old...)
Now the good sendmail folks have at this point every reason to believe that this particular thinko is likely not limited to Linux. Hence their check which they would hope will catch other current examples, and future ones if other people mess up. If they didn't do something like this then their (already pretty bad) reputation for security would get worse as they are an obvious target for taking advantage of setuid bugs.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht