Slashdot Mirror
XP/Vista IGMP Buffer Overflow — Explained
HalvarFlake writes "With all the hoopla about the remotely exploitable, kernel-level buffer overflow discussed in today's security bulletin MS08-0001, what is the actual bug that triggers this? The bulletin doesn't give all that much information. This movie (Flash required) goes through the process of examining the 'pre-patch' version of tcpip.sys and comparing it against the 'post-patch' version of tcpip.sys. This comparison yields the actual code that causes the overflow: A mistake in the calculation of the required size in a dynamic allocation."
>This comparison yields the actual code that causes the overflow:
>A mistake in the calculation of the required size in a dynamic allocation
I hope no one else makes this mistake.
that M$ is a bunch of NIGGERS?!?!
Nigger Nigger Nigger
does anyone know where i can find some "reduced cost editions" of the software used?
Hooray! Windows vulnerabilities are so commonplace now that there are public educational documentaries about their life-cycles and internals, so that the people can stay informed. Brilliant!
OMG! I thought it might be a bug, but thankfully it's just a mistake!
Engineering is the art of compromise.
It's a fucking advert
Darn pesky kids and their fancy buffer overflows. I outta HEAP on the insults, but I'll try to stick to my PROGRAM of keeping my smoke STACK cool.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Why upgrade?
I don't plan to upgrade from Windows 95, NT 3.51, and NT 4 on the desktop. With network booting, Windows 95/NT do everything I need for user workstations. Of course, I run OpenBSD on the server. Modern graphical user interfaces are mess. Even modern versions of X are very bloated. And don't get me started on mainstream window managers.
Microsoft should go back to Windows 95's user interface. Combine it with NT and add a good command line shell with SFU. That would be perfect for end users. Windows 95 is actually very stable. I've had no problems supporting it for many desktops with network booting - as long as I don't install IE 5.5 and it's new Explorer.
Microsoft should go back to fast, light user interfaces like Windows 95. Windows 95 was the best consumer operating system in 1995 (I like Apple, but Macs still had cooperative multitasking though OS 9.)
To all IT admins: Just put all users on Windows 95. Office 97 has all the features you need. Anything else can be accessed through NCSA TELNET, SecureSHell, or even vnc.
Yep, the submitter's email is from the company that stands to gain from more hits to this video (the ad at the end of the video).
Lol MS sux0rz! ph34r my 1337 h4x!1one
Everyone should be forced to give up manual memory allocation regardless of the power it can afford.
#include "fucktard_troll.h"
Now that that's done with, I see things like this as an argument in favor of moving stuff off of the CPU and into dedicated hardware. Why should your CPU be tied up with things at this level? The absolutely overwhelming majority of all data on every network uses one of two network layer protocols (IPv4 or IPv6) and one of two transport layer protocols (TCP or UDP). Why shouldn't those four combinations be handled by hardware, so we can leave the computer to run the applications? We already do this with 3d rendering, why not networking?
Yes, I'm correcting myself. I know that I made an error. I should have typed "its" instead of it's." The former is the possessive form. I know better than this. :(
Or you could read about it on the Security Vunerability Research and Defense blog at http://blogs.technet.com/swi/
I smurf everything and everything I smurf is perfect.
I see things like this as an argument in favor of moving stuff off of the CPU and into dedicated hardware. Why should your CPU be tied up with things at this level? The absolutely overwhelming majority of all data on every network uses one of two network layer protocols (IPv4 or IPv6) and one of two transport layer protocols (TCP or UDP). Why shouldn't those four combinations be handled by hardware, so we can leave the computer to run the applications? We already do this with 3d rendering, why not networking?
Do you have any idea how many millions of ethernet cards have been sold? Are they all going to be made obsolete?
These days CPUs are so fast that the minor overhead of a network driver is negligible, unless you're going to ultra-fast speeds (some high-performance network cards do offload this to hardware).
However, you still could have buffer overflows in the network drivers/firmware.
This movie (Flash required) goes through the process of examining the 'pre-patch' version of tcpip.sys and comparing it against the 'post-patch' version of tcpip.sys. This comparison yields the actual code that
See? And they said without FOSS, this couldn't be done!
You see? You see? Your stupid minds! Stupid! Stupid!
win32time service is broken in their Active Directory enviroment post these updates. It is as yet unclear if they are related.
The cards won't be made obsolete, any more than 2d cards are made obsolete, a number of my machines have 2d only cards and they work fine for a large amount of the non gaming I do.
I don't think anyone advocates softmodems, so why do we tolerate mostly soft network cards.
Software is more flexible than hardware. We have plenty of hardware to do the work, and the parts that benefit from offloading (e.g. checksumming) are already offloaded. No point to adding new hardware.
Even with a buffer overflow in the firmware of the card it would be much harder to exploit it for system access, the most you could do with it is control the network adapter (granted that is still a lot but much better than root). That is unless the application using the network card just blindly read in data without sanitizing it, in which case you are back to square one.
i read about it in a blog once
Because TCP and UDP headers aren't of fixed sizes and as such are incredibly difficult to handle in hardware. Hardware switching has been tried - ATM for instance - but it's not that simple. TCP/IP was designed as a software protocol, and it's an unfortunate reality that some protocols are easily handled in hardware and others are not.
IPv6 makes some steps towards having simpler hardware handling, but as long as IPv4 is still around, we won't see hardware switching become commonplace.
Or unless it DMAs stuff over, right on top of the kernel...
Ewige Blumenkraft.
Everyone should be forced to give up manual memory allocation regardless of the power it can afford.
I beg your pardon?? What is it you're suggesting with that respect exactly?
You just got troll'd!
In flash no less! Someone's about to leave somewhere for a lot more money.
The problem is more fundamental then smarter network hardware, it's the CPU/Memory architecture. Long ago, there where computers that had dedicated hardware for memory content management. Two schemes were used: segment descriptors and memory tag bits. The segment hardware checked that addresses for the data structure fell inside the segment memory limits, and tag bit described memory contents (i.e. integer, float, pointer, etc). This was in the days when logic and memory was much more expensive then today. These design choices made the machines much more reliable.
Specifically I'm referring to Symbolics Lisp Machines and Burroughs stack machines, both of which had very low software failure rates. Even when a program crashed, the OS kept going. Note that both of these computers had all their main software written in high level languages that had automatic garbage collection that was integrated with the hardware memory support.
Unfortunately, the quest for performance eliminated these features. Realistically, without hardware support software will never be very reliable. (Even with better hardware there will still be problems, but the current situation will never be very good.) Now that logic and memory are cheap and reliability is a critical issue, we should be considering putting resources into these kind of reliability checks. What are we doing instead? Putting more cores on the die. Yeah, more multi-threading will make software even more reliable in the future.
I'm so looking forward to reconfigurable hardware; that'll make the whole argument moot. The CPU as we know it will do nothing but setup reconfigurable logic units and direct data streams. You want hardware networking? Bam. Hardware complex math? Bam. Hardware neural net? Bam.
TCP/IP offloading is already done on-chip by several network cards. Spend $10-$50 more on a network card and you would get it. Off course a lot of TCP/IP is still handled in the kernel of the OS just because it is too flexible to be done on-chip. Off course, if you need more performance along the lines of firewalling or traffic shaping, you could get an external appliance that handles it.
Custom electronics and digital signage for your business: www.evcircuits.com
Because Ethernet is a physical component of the networking chain; protocols other than TCP or UDP can (and are!) be implemented.
Besides, networking is something that barely taxes CPU power on every processor made from the Intel Pentium days to this date, unlike 3D acceleration. There's little justification to loose the flexibility provided by running it in software to get a negligible CPU performance increase.
And yes, hardware can be buggy too. There's a shitload of issues with specific hardware that are addressed on their device drivers - again, easier to solve in software than to fix in hardware. Even CPUs suffer from this.
I'm so looking forward to reconfigurable hardware; that'll make the whole argument moot. The CPU as we know it will do nothing but setup reconfigurable logic units and direct data streams. You want hardware networking? Bam. Hardware complex math? Bam. Hardware neural net? Bam.
Behold, the bright future!
Actually, there's one more comparison they've screwed up. Anyone who has installed the Event ID 4226 patch to increase the allowed number of half-open connections so their BitTorrent speeds don't suck ass just had that patch undone by this new version of TCPIP.SYS.
:-] Oh, and I'll add one more detail not mentioned here. According to F-Secure, there haven't been any exploits for this found in the wild--yet.
The only good thing is that, while the page hasn't been updated since 2006, the patch seems to work on the new TCPIP.SYS (I just tested it on my own machine).
I realize I'm sort of hijacking the first post, but given how many of us are probably downloading Linux ISOs right now, I figured it's important enough that people wouldn't mind a reminder...
Because in the end an application is going to get a packet of arbitrary size from network stack and has to allocate buffer accordingly. This is nature of asynchronous communication.
Woah...
Now, don't get me wrong. I think that's a really cool hack. I admire the effort.
Seriously though, WTF? That's a rootkit technique. Changes of this nature should be made to source code, not binaries. It's way more maintainable and sustainable that way.
I don't mean an FPGA, I mean something like a magnetologic array. Something that's both fast and quickly reconfigurable on the fly. Scientific American had a story in the August 2005 issue if you can find it.
> Seriously though, WTF? That's a rootkit technique.
Rootkits use a lot of techniques that are also used by legitimate software. Yes, that patcher (and its patch) does get detected by a few anti-virus programs because worms, like torrents, benefit from being able to connect to more peers. It's not a virus in or of itself, though, plenty of people have checked it out.
> Changes of this nature should be made to source code, not binaries. It's way more maintainable and sustainable that way.
I fully agree, but it's kinda hard to get the source for Microsoft programs. Last I heard, you had to be a big university, pay tons of money, sign NDAs, etc. Besides, this limitation wasn't an accident. It was a deliberate "feature" they put in because they thought it would slow down worms. They're not going to fix it just because people ask.
Xfce: Lighter than some, heavier than others. Just right.
"It could be that the purpose of your life is only to serve as a warning to others." http://despair.com/mis24x30prin.html
Wow! I thought I was retro with Windows 2000!
:)
Turns out this patch MS08-0001 is Patch NUMBER 100! Yea! Yea! Yes!
Finally, the number of patches to Windows 2000 is in TRIPLE DIGITS!
( actually, for us, 2K users, there are two patches, KB941644 and KB943485 )
( I found the actual patch count from a Winternals System informataion program )
( WinTernals is my bestest friend! )
Since you can 'blind' Windows 2000 to look like vista, ( if you have the graphics hardware ),
or you can 'blind' Windows 2000 to look like Windows98, I have the best of both worlds.
but ALL MY PATCH COLLECTION CDs ARE NOW OUT OF DATE.
Actually, there is one feature I need that Office 97 doesnt have, and that is the ability to read Office 2007 excel files. So, its Win2k and Office 2k for me. ( btw, I am going to set up a DOS machine to play some old games...
Some ethernet hardware can offload a number of expensive yet common operations to be done in hardware. But it doesn't always work.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
That's not really fair. OSs now use virtual memory for protection. There are schemes to use canaries on the stack so that buffer overflows are guaranteed to cause a crash rather than an exploit - software can be updated over the net to fix the crashes. There is a move to VM based software like Java and .Net that uses garbage collection and can be statically verified before it is JITted to native code.
I don't really believe that segment based protection could ever have eliminated stack overflow exploits at an acceptable performance level. Look at the assembler for a function that uses stack variables - they are all allocated by a single subtract operation. If they were allocated individually as far pointers the OS would need to be called for each one. It would need to switch to kernel mode and modify the descriptor table and then return. Once the function was done the whole process would need to be repeated. Most C functions would run hundreds of times slower if this was the case.
The performance cost of VM based solutions is far lower and they can still be run on current PCs, not some radically new architecture which would probably spend most of short life emulating old code badly anyway. E.g if you look at Itanium it is far less radical than a stack based machine and yet it still failed because it had a relatively minor performance disadvantage on old binaries.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Most Ethernet cards aren't "mostly soft". The network stack is, well, a stack. The physical layer and link layer are usually handled by the card. The stuff above that might be handled in firmware or a driver, but I'd rather not have IPv4 shove onto my Ethernet card as the only option. Some cards have gone soft to cut costs, but mid to high end cards are all hard. High-end server cards often have IP acceleration built in, but leave other options open.
Because as we all know, manual memory allocation is hard to understand. Programmers shouldn't have to know basic math, right?
Why don't we just make a language that does it automatically, and then we won't have any problems like this? Right?!
Those of us who cut their teeth on assembly and C look at this and just wonder in wide amazement. A part of us wonders how anyone could be so negligent - but the other part knows how things work in proprietary software shops. (A hint - the management doesn't consider it a bug unless the customer notices it.) Yes, we've all done this before, but the solution isn't to create a language which dumbs down the programmer (Dude - you're writing directly to memory!!! You must be some kind of uber-hacker!!). Rather, there are steps you can take to virtually eliminate this kind of problem:
You know, there was a time when formal methods were taught, when programmers were expected to know how to properly allocate and release memory. When things like calculating the size of the buffer, applying basic math(!) and testing your own code were considered just a part of the programmer's job. Now we're hearing people blame languages for the faults of the programmer.
If I keep going, I suppose I'll start to sound like Bill Cosby. But consider this: the most reliable operating systems to date were built on C (UNIX) and assembly (MVS). If a bunch of old farts (well, perhaps they were young then...) can crank out correct, reliable, fast code without an IDE and a bunch of GUI tools, clearly the language is not to blame.
The old adage still applies: a poor workman blames his tools . Software engineering works, regardless of the implementation language. This isn't a failure of the language or the environment, but rather, failure to do software engineering right:
The society for a thought-free internet welcomes you.
Isn't that pretty much what a CPU already does?
For the few people, who are hanging to their Windows 2000 for dear life ?
The absolutely overwhelming majority of all data on every network uses one of two network layer protocols (IPv4 or IPv6) and one of two transport layer protocols (TCP or UDP).
You forgot ICMP. And even if you had remembered it, the bug was in IGMP, which is still not on your list, and would thus need to be implemented in software anyway. Sure, IGMP is not used that much, but it only takes one bad guy to send the packet that takes over your system.
bindiff.exe
But that is the primary reason for
Considering that Firefox crashes whenever I happen to hit the "Insert" key when writing a reply on Slashdot, and randomly otherwise, I'm inclined to agree. Programmers, in general, are apparently incapable of dealing with memory management or bounds checking, so they should just use automation.
Of course simply moving them to Java will just have them do things like starting threads from object constructors (which causes all kinds of weird and wonderfull bugs), use 100+ threads for low-volume network communication (I'm looking at you, Freenet) and in general write such inefficient code that a lookalike but less featured remake of a DOS-era game running on a 1 GHz machine feels like watching a glacier (FreeCol, that means you).
Most programmers are incompetent, there's no getting around that. And giving more power to an incompetent is propably not such a bright idea.
Sorry about the rant. I blame it on Firefox crashing three times this morning.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I think he's suggesting the .NET framework.
Quite what I was afraid I understood. If you're afraid of doing dynamic allocation yourself you shouldn't be allowed to use a real programming language in the first place anyways. I mean seriously, that trend that consists in going "eww, dynamic allocation", "omg, a pointer, what is that thing!?" or even "I wonder how people could live without garbage collection" makes people sound like sissies.
You just got troll'd!
Forget these other retards. Your hardware idea is one of the best I've ever heard.
Write it out in VHDL, get an FPGA, and take the proof of concept to someone with money. Any web server admin with half a brain can see why having your TCP/IP stack in hardware is preferential to software, even if it does replace the ethernet card.
Fantastic!!!
Well, for starters you'd need to actually *find* the IP header in the frame before you start mooking around for the transport headers.
But people keep saying "You really need to get a TV" etc. We're social animals and now social mores are based around TV.
Mind you, I now need so little money I'm able to work part time and STILL have a lot of money to enjoy it.
OK, so the poor artists (and engineers, etc) will starve because nobody is buying their product any more, so I can't see that being allowed.
It's a physical layer component ,which is not a physical component,but a logical one.
pi = 2*|arg(God)|
Hear, hear. Once upon a time I designed a packet-ized format for data telemetry and storage. The design was straightforward, but it included a variable-sized record-header (but always a factor of 8) on top of variable-sized record payloads. I thought it was a good idea at the time, but it turned out to be problematic for S/W implementation, especially for inexperienced devs. I could have saved ourselves a lot of time and pain if I had made the record headers fixed-length. Mea culpa.
Makes one appreciate just how complex handling TCP/IP can be. I can't imagine how it could easily be ported to firmware. It obviously can be done, but it's no easy task.
In the course of every project, it will become necessary to shoot the scientists and begin production.
Shit, this error needs to be fixed in BSD Unix as well.
Of course simply moving them to Java will just have them do things like starting threads from object constructors (which causes all kinds of weird and wonderfull bugs), use 100+ threads for low-volume network communication (I'm looking at you, Freenet) and in general write such inefficient code that a lookalike but less featured remake of a DOS-era game running on a 1 GHz machine feels like watching a glacier (FreeCol, that means you).
Most programmers are incompetent, there's no getting around that. And giving more power to an incompetent is propably not such a bright idea.
Sorry about the rant. I blame it on Firefox crashing three times this morning.
Wow, Java programmers start threads in constructors? I admit I have no idea what havoc that would cause, but on the other hand it would never occur to me to do such a thing. Seems to me that's what the Runnable interface is for.One of my big pet peeves of the software industry is that no project I've ever been on bothers to do CPU or memory profiling unless there's an absolutely god-awful bug. I mean, something like "a tiny transaction is taking 1.5 hours" or "Our small app is bloating from 25MB to 1GB". No one on these projects but me has EVER thought "This thing should be performing faster and using less memory" and then ran the tools to figure out why. Then again, I've spent most of my time at a company that sells hardware and software, so it's probably good for business that their apps waste memory and CPU cycles.
I actually don't mind marketing that actually *is* clever. Be it entertaining, informative, or just cool, when a company spends enough bucks to make an Ad truly worth watching/reading, I won't complain. For such ads on the internet, they usually don't even need to spend much on distribution - people will pass it on of their own accord. "Viral Marketing." I do think companies that do this should include a Creative Commons type license so people know it's ok to pass it on.
C is a horrible abomination of a language when seen from the perspective of modern languages like Haskell, Erlang, ML, Scala etc. There are even operating systems written in these languages. C has cost the IT industry billions of dollars as a result of safety and security problems.
C served its purpose, it's now time to be replaced with a better language.
Remember kids, if you need a vBlog to make your Blog interesting it may be more about you not being interesting than the format.
-
Yeah. And CPU's are ridiculously fast nowadays anyway. The demands put on them by stuff like networking are so low it's just in the noise in most cases.
I think if you continue your "off course" comments, you'll never stop stating the obvious.
Well, I seem to get plenty of 4226s when I don't patch it and I'm using uTorrent. Also, the site linked seems to rely on MSDN documentation, which I don't really trust. I've used the LVLlord patch for years now with absolutely no troubles, though I admit that I don't (and never would) use Media Center.
Moreover, the LVLlord patch (which is the one linked above, BTW) can be run again to uninstall itself and makes a backup of your TCPIP.SYS.
Anyhow, it's up to people to make their own choice on the matter. I'm not too worried about worms--I've never had one in all my years of running Windows (I do my own checks for malware, rather than just relying on a virus scanner) and the patch works for me.
*shrug* But you don't have to take my word for it.
I seem to remember assembly programmers saying the same things about high-level languages...
My blog. Good stuff (when I remember to update it). Read it.
Hopefully the GTK developers will fix this issue soon.
Hrm... doesn't seem to crash for me. What version are you using? Or do you have your Insert key somehow tied to something else? Because I just hit Insert 20 or 30 times while typing this and nothing happened.
My blog. Good stuff (when I remember to update it). Read it.
Why should I *slave* for micro$soft?
Let them release the code for Win98 GPL and see how fast it surpasses Pista!
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
I seem to remember assembly programmers saying the same things about high-level languages...
Sure, we might go "wtf do you need exception handlers for? Just write bug-free code!" or even "operator overloading is for pansies", but there's no way you can turn it into making us sound like sissies.
You just got troll'd!
Now that that's done with, I see things like this as an argument in favor of moving stuff off of the CPU and into dedicated hardware. Why should your CPU be tied up with things at this level?
It's been done over and over again, and in every single case, with the excepting carefully selected benchmarketing, it's had worse performance than doing it in the CPU with a cheaper and simpler NIC.
Personally, I'm glad it's NOT in the card. Imagine a vulnerability found in a network card's stack! A PCI card can scribble all over system RAM just as easily as a buggy kernel driver. Imagine no more iptables. Imagine nobody experimenting with IPv6 at all because they'd have to get an expen$sive new card carved from pure unobtanium.
I'm not too sure about using strlen in a loop like that. C strings are NULL terminated so each time you are going through that loop and doing your test you are also having to iterate over foo to find its length (unless foo is const variable and the compiler notices etc).
I'm not so sure about the "you forgot to terminate your string constants" bit. My understanding is that string constants are NULL terminated in C. I would be a bit cautious about assigning a string constant to a fixed sized array though (it feels wrong... If copying happened there's potential for wasted/too little memory, questions over whether you are actually throwing a pointer to rewritable memory away, are you trying to change read only memory later etc). Whether more memory is zeroed before use depends on your platform, libraries, how the memory allocation was done and your compiler (e.g. on Linux the glibc malloc function switches between brk and mmaped memory allocations depending on size and mmaped memory is zeroed by the kernel before being passed to your program).
I think you've chosen a bad example there. The TCP/IP stack is a very speed critical part of current kernels. At gigabit (or faster) speeds a very large number packets will arrive so that is code that is executed an awful lot (especially if you are running a stateful firewall). You don't want gettimeofday to be slow because it is called so many times. The same goes for your TCP/IP stack - you want it to be fast AND robust.