Slashdot Mirror
Linux 2.2 DoS Attack
A small bug in the Linux networking code has been found, and just as quickly patched. The
bug affects all Linux 2.2 kernels, and can be fixed by removing "kfree_skb(skb);" from around line 455 of
linux/net/ipv4/ip_options.c. Big thanks to Alan Cox on this one.
It allows a remote user to panic a affected machine with a bogus packet.
This just came to me from BUGTRAQ.
../linux.vanilla/net/ipv4/ip_options.c Wed May 12 16:49:38 1999
Can someone tell me what that output means?
--------------cut here---------------------
Ok problem confirmed. Its not icmp however - in fact the program given
has some bugs that cause it. If it had been a correctly written icmp tester
it wouldnt have worked. A blessing in disguise.
Anyway the fix seems to be this. Sorry it took so long to sort out.
---
+++ net/ipv4/ip_options.c Tue Jun 1 22:11:46 1999
@@ -452,7 +452,6 @@
error:
if (skb) {
icmp_send(skb, ICMP_PARAMETERPROB, 0, htonl((pp_ptr-iph)- kfree_skb(skb);
}
return -EINVAL;
}
Alan
ARGH! It's a remote crash.. Most people would rather there be a remote crash then a remote exploit.. (RE in most people's minds means the attacker gets root)
PLEASE update the post to indicate that this is a crash and not a root explot.. PLEASE!
Bleading Edge hacker types run 2.2? Hrm. It's the stable kernel for distribution now. Anyone with RedHat 6 or whatever the latest Debian version is (Potato or something) will have this exploit. RedHat better have a fix up on their server pretty damn swiftly.
--
David Coulson (TechNoir)
themes.org Senior Developer
LinuxHQ is having DNS problems (the owner of the name took it back). The maintainer (Jim Pick) had just enough warning to preemptively get another DNS name (kernelnotes.org). Therefore, the LinuxHQ site is currently up and happily running at http://kernelnotes.org. If you want more info, check out the announcement.
----
Open mind, insert foot.
The same number of security holes are present in proprietary OS's. They're not easy to find without the source code, however. The holes that are found, if they're announced by the vendor (or kept secret), typically do not come with solutions.
- A.P.
--
"One World, One Web, One Program" - Microsoft Promotional Ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
banner -w80 'Linux Still Sucks!'
A classic newbie prank is to pipe the output of banner to write to disply obnoxious stuff on someone else's screen. (It's almost as classic as using xloadimage to change someone's root window to a hardcore porn pic). This guy obviously hasn't gotten over it, though honestly I laughed my ass off when I saw it.
Can anyone confirm whether or not this affects 2.3.x kernels? The line in question is present in 2.3.4 (which came out today, though you'd never know it, 'cause Rob appears to have knuckled under to the 31337 weenies and quit announcing dev releases), so my guess would be yes...
The new 2.2.10pre2 patch includes this fix.
Did removing this kfree_skb call cause a memory leak? Or was the memory free always unnecessary?
... I'm not suggesting that the people in the know kernel-wise haven't considered this, I just find it odd that a free can be so readily removed without requiring new code elsewhere to make sure that the memory really does get freed at the right time.
If I ever fix a bug in my code by removing a call to free() I tend to get very suspicious
I would love to agree with you, but can't.
:-) You can't ever really test this kind of general purpose system.
...
It would be damn near impossible to run a full qual. test on a modern OS. The complexity level is just to high and there are really no requirements to test anyway. The government will not (I hope) step in here. There is no reason for them to do so.
Think of it this way: it takes WEEKS of 24 hour computing to run a FQT on an aircraft digital flight control system. WEEKS. and this is a system with super super rigid, well defined, realtime requirements. There is no code in the system that is not used.
Now consider the Linux kernel. How many system calls are in there that joe average user never touches? How many combinations of things could be going on at one time? For all intents and purposes we are dealing with an infinite combination regression test situation here. or something.
With the complexity in modern realtime and avionics systems, we are pushing the limits of software test. Formal qual testing of general purpose software is a lost cause.
i'll stop rambling on now
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
From the archives at www.geek-girl.com
Linux kernel 2.2.x vulnerability/exploit
Piotr Wilkin (pwl@WOTAN.2SLO.WAW.PL)
Tue, 1 Jun 1999 17:43:17 +0200
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Salvatore Sanfilippo -antirez-: "whois_raw.cgi problem"
Previous message: aleph1@UNDERGROUND.ORG: "New Allaire Security Bulletin (ASB99-09)"
I'm sorry if this has been noticed before, but since I did't find anything
in the archives, I post it here.
There seems to be a bug in kernels 2.2.x (tested on 2.2.7 and 2.2.9), that
causes them to panic when they are sent a large number of specific ICMP
packages. I think the problem comes from the combination of the mangled
header length (shorter or longer ihl's don't cause hangup) and the random
ICMP packets (random type/subtype and source address) this program sends.
Windows 9x and FreeBSD 3.0 seem to be unaffected.
I think the most interesting thing is the date, though... I'm sure I'm making a timezone mistake here, but isn't that 8 hours ago? Is that faster or slower than the Linux teardrop fix?
It's annoying to find out about a new DOS attack, but the resolution is all that you could hope for.
It's a little less annoying that there don't seem to be any outstanding instant-crash attacks against Win98 to laugh about - they finally fixed the series of attacks that crashed 95 for 8 months straight, and I haven't seen anything since. Did Microsoft finally get their IP stack right?
Uh... before you apply this patch, notice that the "less-than" in the icmp line should actually be doubled (i.e., a left shift opperation)! The second less-than symbol got swallowed somewhere in the HTML conversion.
Your Servant, B. Baggins
See the following:
= /security/casesensitive.htm
http://www.ntsecurity.net/scripts/loader.asp?iD
In short, every version of NT has a security exploit that allows any user to get root access. That's a far greater security risk than this DoS attack, which can simply crash your system.
It has been known for over ten weeks. And AFAIK, Microsoft hasn't released a fix (at least I can't find one on microsoft.com). It is possible that NT 4.0 Service Pack 5, released six weeks after the hole was found, fixes it -- for NT 4.0 users and NT users willing to pay to upgrade to 4.0 only.
Now, which is a bigger deal -- a DoS attack fixed eight hours after publication, or a root exploit unfixed for at least six weeks after publication?
"a rule banning
incoming ICMP"
has your box breaking MTU path discovery, making
you a bad netizen.
http://www.worldgate.com/~marcs/mtu/
-fb Everything not expressly forbidden is now mandatory.
This is not quite accurate. The actual bug was in Windows 95 (still in 98? Don't know). They discovered that the uptime counter rolled over after approximately the number of days you mentioned, and crashed the box. This was discovered, if I remember correctly, earlier this year (it seems that in 3 and 1/2 years NO ONE had ever successfully kept a Win95 box up for that long!).
NT, however, does not suffer from this particular bug. I have a client who managed to keep his NT box up for at least 78 days -- mostly because the machine was so little used (he's an exec, not a geek). After 78 or so days, he had next to no free RAM left for anything. The leaks in the OS itself had plugged the system horribly. Nevertheless, this man did successfully run it for 78+ days.
DFL
Never send a human to do a machine's job.
For Windows 98: "I sure hope that there aren't any more delays on that service release! It's been a year already! I hope this bug's covered in it or I'll have to wait another 6 to 8 months!"
For Windows NT: "Lessee, I can apply this 'unsupported' hotfix that Microsoft released...or I can wait for Service Pack 6 due in 3-6 months..."
Meanwhile, for Linux, it's this: "5 hours for a patch? What TOOK so long???"
DFL
Never send a human to do a machine's job.
Firewalls are not the answer to these problems either. These bugs need to be fixed, dumb protocols need to be fixed or discarded, in stead of patching things up with kludges and afterthoughts like IPSEC, firewalls and the like.
It would be nice if people would start designing protocols with security in mind, in stead of trying to add it on afterward.
Sorry about the rant.
Even so, this does show that the current system may be out of wack.
Perhaps only some forms of comment-downgrading should count against one's user total? Like Flamebait or Troll, while Offtopic and Redundant will only affect the single comment and not your alignment?
Designing a proper comment rating system is hard work, to be sure. I wonder if Godel's theorem that no set of logical axioms can be both consistent and complete extends to ANY SYSTEM, be it a comment-rating system, or an OS? Heh...reminds me of the other comment here suggesting a formal proof of an OS...microkernel territory there...probably the extending of Godel to any system is one of those truisms that can't be proven...totally meta...
Felix
arvind rulez
[snipped from bugtraq, dated jun 1]
From: Piotr Wilkin
Subject: Linux kernel 2.2.x vulnerability/exploit
I'm sorry if this has been noticed before, but since I did't find anything
in the archives, I post it here.
There seems to be a bug in kernels 2.2.x (tested on 2.2.7 and 2.2.9), that
causes them to panic when they are sent a large number of specific ICMP
packages. I think the problem comes from the combination of the mangled
header length (shorter or longer ihl's don't cause hangup) and the random
ICMP packets (random type/subtype and source address) this program sends.
Windows 9x and FreeBSD 3.0 seem to be unaffected.
[exploit code snipped, check www.geek-girl.com for it in the archive if you really need to know]
The double-slash was originally intended to work with C++ only, not C. People liked the idea so they started using it in C as well. Then it finally became a standard.
However, not all compilers have not caught up. I don't know of specific examples, but some Unix variants still do not understand it. Therefore you should not use it if you intend to make your source code widely available. And if you think your source code will never, ever be widely available or maintained by someone else, think again.
Incidentally, in C and C++ another way to comment out source code is like this:
main() {
char *s = "Hello world!";
#if 0
s = "World, hello!";
#endif
puts(s);
}
Since "0" is always false, s = "World, hello!" will not be compiled.
That way the commenting can be nested and you can be sure compilers will recognize it. A drawback is that colorized editors will not recognize it as a comment. Another drawback is that there is no equivalent in Java and you have to fall back to regular comments.
linux/ means the directory where the Linux kernel sources live. Typically, when one refers to linux/ one means /usr/src/linux/ although this isn't a given. net/ means the dibdirectory called net/ ; ipv4/ means the subdirectory of net/ called ipv4/ ; ip_options.c is the file you want to edit. You want to open this file with your favorite text editor, preferably one that displays line numbers somewhere. (You can toggle whether emacs displays your current line number with M-x line-number-mode.) To comment out C code, you can use /* ... */ . Comments like these can't be nested. It's pretty easy to comment out large sections of code like this. (You'll fairly often see people using // for comments in C code, but it's a bad idea, and you shouldn't do it. Don't Be That Guy (tm)!)
HTH
You're a suburbanite.
The instructions (as they appear on a previous reply to your post) are quite straightforward. Now, about recompiling - It shouldn't take that long. If you just compiled 2.2.9, then this patch will only take a few seconds to get compiled, make will automatically notice this is the only file with a modification time newer than the object (compiled) code.
How about in future articles, you post a link to the patch as well? This would be very helpful to newbies like myself who don't quite know where to find everything yet...
And I JUST compiled 2.2.9 today!!! Arrgh!
"I have no respect for a man who can only spell a word one way." - Mark Twain
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin