4 ms·

Critical Windows Vulnerability in TCP/IP Stack Could Allow Remote Code Execution

68 points by xyzzyrz 15y ago

Mad_Dud 15y ago
Does anybody have PoC on this one?
- packetlss 15y ago
  It's said to be a 32 bit refcounter bug, making it near impossible to predict the triggering packet over WAN.
  - marshray 15y ago
    If so, would require hundreds of GB of UDP packets. But you may not need to predict which one is the one that wraps the counter. It may be that all your packets could be the same.
munin 15y ago
it looks like someone forgot to decrement a reference count where they should have. in microsofts defense, these kinds of bugs are extremely difficult to reason about and I'm not aware of any product, service or technique that you can buy, train in, or subscribe to to enable your developers to accurately reason about reference counting and concurrency. microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too. there are countermeasures in place especially in windows 7 and forward that would make exploitation of this extremely difficult (aslr, safe unlinking in the kernel heap, etc).
- ketralnis 15y ago
  > microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too I agree in principle, but this is hardly the most accurate way to measure this
  - munin 15y ago
    it isn't no, but ask yourself, "what more can I do?" fund academic research? fund industrial research? hire security consultants to do independent audits and assessments? develop a secure software development methodology? hire security professionals and have them interface with both my product developers and the security community? have professionals interface with the global security community and develop strong working relationships with "well known hackers", possibly even hiring some of them? invest in lots of applied research on making exploiting bugs in your software harder? invest in actually building the systems that the previously mentioned academic research theorized about to identify bugs in software that you write? oh, you did all of that? and more? and there are still bugs in your code? somehow I think this says more about the craft of developing software than it does about your company and culture ...
    - wwrap 15y ago
      It's not a secret that Microsoft's hiring practices are somewhat subpar and their internal organization is a mess. Am I surprised that a product got rushed out with major issues? Of course not, they do it every day.
      - josephcooney 15y ago
        Where is the evidence that it was rushed out?
salmanapk 15y ago
Thank god am using XP :))
- udp 15y ago
  Yes, thank god for everything else you're exposing yourself to by using a decade old operating system without UAC.
- pavel_lishin 15y ago
  "I don't have to worry about hackers - I keep all of my life savings in a pickle jar hidden in the trunk of my car!"
  - rosstafarian 15y ago
    so those wherent pickles in that car i stole?:(
reduxredacted 15y ago
I've been tearing through this one and I have a very basic question: Because it's in the IP stack, would a software firewall offer any sort of defense here?
- munin 15y ago
  thinking about it, yes and no. yes, because in windows traditionally third party firewalls are sandwiched between the tcp/ip stack and the network card driver. the firewall will see packets before the TCP/IP stack does and it can make a decision then. but probably no, because since this is a refcounter bug there isn't anything specific about the packets that you are interested in blocking. you can probably try and apply some kind of ratelimiting action or something else, but what you're working around a failure in object life-cycle management on the part of the OS so you'll be guessing. it isn't like there's a "bad pattern" that you can match and drop to make everything OK.
getsat 15y ago
Is this the alleged fifth 0-day in Stuxnet that was allegedly suppressed?
- dsl 15y ago
  Probably not. It was previously known as MS11-064, a Denial of Service bug. Someone expanded on the vulnerability and got remote code execution out of it.
  - getsat 15y ago
    Cool, thanks for the info. I still wonder what happened to the Russian security researching who was tweeting about the fifth 0-day and then vanished...
  - wladimir 15y ago
    DDoSes and exploits in the TCP/IP stack, whoa... This brings back memories of Winnuke (http://en.wikipedia.org/wiki/WinNuke http://en.wikipedia.org/wiki/WinNuke), Teardrop and follow-ups, when it was easy to crash any windows computer with just the IP.

68 points by xyzzyrz 15y ago

Mad_Dud 15y ago

Does anybody have PoC on this one?

packetlss 15y ago
It's said to be a 32 bit refcounter bug, making it near impossible to predict the triggering packet over WAN.
- marshray 15y ago
  If so, would require hundreds of GB of UDP packets. But you may not need to predict which one is the one that wraps the counter. It may be that all your packets could be the same.

munin 15y ago

it looks like someone forgot to decrement a reference count where they should have. in microsofts defense, these kinds of bugs are extremely difficult to reason about and I'm not aware of any product, service or technique that you can buy, train in, or subscribe to to enable your developers to accurately reason about reference counting and concurrency. microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too. there are countermeasures in place especially in windows 7 and forward that would make exploitation of this extremely difficult (aslr, safe unlinking in the kernel heap, etc).

ketralnis 15y ago
> microsoft spends more $ per loc on security than any other organization on Earth so if this slipped through their process, similar bugs probably slip through your processes too I agree in principle, but this is hardly the most accurate way to measure this
- munin 15y ago
  it isn't no, but ask yourself, "what more can I do?" fund academic research? fund industrial research? hire security consultants to do independent audits and assessments? develop a secure software development methodology? hire security professionals and have them interface with both my product developers and the security community? have professionals interface with the global security community and develop strong working relationships with "well known hackers", possibly even hiring some of them? invest in lots of applied research on making exploiting bugs in your software harder? invest in actually building the systems that the previously mentioned academic research theorized about to identify bugs in software that you write? oh, you did all of that? and more? and there are still bugs in your code? somehow I think this says more about the craft of developing software than it does about your company and culture ...
  - wwrap 15y ago
    It's not a secret that Microsoft's hiring practices are somewhat subpar and their internal organization is a mess. Am I surprised that a product got rushed out with major issues? Of course not, they do it every day.
    - josephcooney 15y ago
      Where is the evidence that it was rushed out?

salmanapk 15y ago

Thank god am using XP :))

udp 15y ago
Yes, thank god for everything else you're exposing yourself to by using a decade old operating system without UAC.
pavel_lishin 15y ago
"I don't have to worry about hackers - I keep all of my life savings in a pickle jar hidden in the trunk of my car!"
- rosstafarian 15y ago
  so those wherent pickles in that car i stole?:(

reduxredacted 15y ago

I've been tearing through this one and I have a very basic question: Because it's in the IP stack, would a software firewall offer any sort of defense here?

munin 15y ago
thinking about it, yes and no. yes, because in windows traditionally third party firewalls are sandwiched between the tcp/ip stack and the network card driver. the firewall will see packets before the TCP/IP stack does and it can make a decision then. but probably no, because since this is a refcounter bug there isn't anything specific about the packets that you are interested in blocking. you can probably try and apply some kind of ratelimiting action or something else, but what you're working around a failure in object life-cycle management on the part of the OS so you'll be guessing. it isn't like there's a "bad pattern" that you can match and drop to make everything OK.

getsat 15y ago

Is this the alleged fifth 0-day in Stuxnet that was allegedly suppressed?

dsl 15y ago
Probably not. It was previously known as MS11-064, a Denial of Service bug. Someone expanded on the vulnerability and got remote code execution out of it.
- getsat 15y ago
  Cool, thanks for the info. I still wonder what happened to the Russian security researching who was tweeting about the fifth 0-day and then vanished...
- wladimir 15y ago
  DDoSes and exploits in the TCP/IP stack, whoa... This brings back memories of Winnuke (http://en.wikipedia.org/wiki/WinNuke http://en.wikipedia.org/wiki/WinNuke), Teardrop and follow-ups, when it was easy to crash any windows computer with just the IP.