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."

7 of 208 comments (clear)

  1. How about http://blogs.technet.com/swi/ by PerfectSmurf · · Score: 4, Informative

    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.
  2. Re:Let's get the preliminary stuff out of the way. by Anonymous Coward · · Score: 4, Informative

    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.

  3. Re:Let's get the preliminary stuff out of the way. by Arainach · · Score: 5, Informative

    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.

  4. Re:Let's get the preliminary stuff out of the way. by guruevi · · Score: 4, Informative

    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
  5. Event ID 4226 by Xenographic · · Score: 5, Informative

    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.

    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... :-] 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.

    1. Re:Event ID 4226 by Jugalator · · Score: 4, Informative

      There are a lot of misinformation spread on the lvllord patch though. The people using it often don't seem to have a good idea of what it actually does, and when it is actually mostly in effect. This should be mandatory reading before binary patching your system files...

      --
      Beware: In C++, your friends can see your privates!
  6. Rootkit? by Xenographic · · Score: 4, Informative

    > 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.