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).
> 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
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 ...
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.
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...
DDoSes and exploits in the TCP/IP stack, whoa... This brings back memories of Winnuke (http://en.wikipedia.org/wiki/WinNuke), Teardrop and follow-ups, when it was easy to crash any windows computer with just the IP.
18 comments
[ 2.5 ms ] story [ 58.8 ms ] threadBut 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.
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).
I agree in principle, but this is hardly the most accurate way to measure this
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 ...
Am I surprised that a product got rushed out with major issues? Of course not, they do it every day.
Because it's in the IP stack, would a software firewall offer any sort of defense here?
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.
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.