Re: Zero-day IE exploit...

Re: Zero-day IE exploit...

Secure Home | Search | About
 Microsoft Applications Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
Re: Zero-day IE exploit... karl levinson, mvp 11-23-2005
Posted by karl levinson, mvp on November 23, 2005, 7:13 am
If you were  Registered and logged in, you could reply and use other advanced thread options

> Karl Levinson, mvp wrote:
>
>>
>>
>>> I do not believe that there is real malicous code flouting arround for
>> this,
>>> this has been a known issue since May.....I believe MS has marked it as
>> low
>>> and as such did nothing about it....typical.
>>
>> You left out the reason why: "The vulnerability targeted by the exploit
>> was originally announced in May as a stability issue resulting in the
>> browser closing."
>>
>> There are tons of ways an attacker could cause IE or any other browser to
>> lock up or shut down, and little reason for an attacker to want to do so.
>> I do not at all blame Microsoft for putting this vulnerability on the
>> back
>> burner as it was known in May.
>
> I will. Certianlly, someone did not reasearch this vulnability well. They
> slapped and incorrect statement about it being a "low" priority and well,
> put their users and clients where they are now. F'd....but then again, the
> XBox was coming out...
>
>> Many vulnerabilities are not fixed right away because Microsoft cannot
>> reproduce the vuln, which is the first step towards writing a patch. If
>> the finder is not available to work with Microsoft on reproducing the
>> vuln, that makes the task harder.
>
> Well, certainly, oter people can reproduce this one...now sure why MS
> could
> not... :-)

Let's be clear here... the vuln reported in May was a denial of service, and
Microsoft correctly prioritized it as such.

>> I could be mistaken, but I understand there is code out there [at the
>> frsirt.com site for example] and that Microsoft has confirmed the code.
>> Some people have reported problems getting the exploit code to work,
>> suggesting my "Microsoft cannot fix what they cannot repro" theory could
>> be correct.
>
> ...I tested it today and, bang, got a calculator...have you tried?

The discussions I've heard in the public are it works for some and not
others. I believe it's harder to figure out how to turn a denial of service
vuln into a remote code execution one if it only occurs on certain system
configurations. Otherwise, the vuln finder might try successful exploit
code on a system that is not vulnerable and discard it as non-working.

I'm not saying Microsoft had any trouble reproducing the code that came out
a few days ago... I'm saying this makes it harder for MS or the original
finder to turn the DoS into a remote code exploit. It seems likely the
original finder would have tried to do this and probably only released this
as a DoS when s/he was unable to do so. S/he also had six months afterwards
in which to try to turn this into a remote code execution vuln, as did the
rest of the world.

> In a nutshell, you always try to pu a spin on MS.

I don't always spin things in Microsoft's favor.

> MS dropped the ball, yet again, but classifiying this as a "low risk" when
> clearly, it is a critical risk...put the blame where it belongs. Microsoft
> screwed everyone again....like clockwork.

It's a critical risk now that remote code execution is found to be possible.

If it was so easy for Microsoft to research the denial of service
vulnerability in May and figure out how to make it exploit code, then why
didn't anyone else do it? It's not like there's no one on the Internet
trying to turn IE denial of service vulns into remote code execution vulns.
I suspect it wasn't as easy as you think. Neither of us are really IE vuln
finders, so in the end we're both guessing about how easy or hard it may
have been to research this vuln.

You may also be thinking that Microsoft could have fixed this six months ago
had they just fixed the denial of service. That is not necessarily the
case. It is entirely possible that if they had released a patch for the DoS
attack, the patch may not have prevented this remote code execution vuln.
Since MS did not know the details of this remote code execution vuln six
months ago, they would not have been able to test it against their patch.

It's also possible that properly fixing this vuln requires a major
architectural change and that was why they delayed on releasing a patch, we
don't know.





Posted by Imhotep on November 23, 2005, 5:49 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
karl levinson, mvp wrote:

>
>> Karl Levinson, mvp wrote:
>>
>>>
>>>
>>>> I do not believe that there is real malicous code flouting arround for
>>> this,
>>>> this has been a known issue since May.....I believe MS has marked it as
>>> low
>>>> and as such did nothing about it....typical.
>>>
>>> You left out the reason why: "The vulnerability targeted by the exploit
>>> was originally announced in May as a stability issue resulting in the
>>> browser closing."
>>>
>>> There are tons of ways an attacker could cause IE or any other browser
>>> to lock up or shut down, and little reason for an attacker to want to do
>>> so. I do not at all blame Microsoft for putting this vulnerability on
>>> the back
>>> burner as it was known in May.
>>
>> I will. Certianlly, someone did not reasearch this vulnability well. They
>> slapped and incorrect statement about it being a "low" priority and well,
>> put their users and clients where they are now. F'd....but then again,
>> the XBox was coming out...
>>
>>> Many vulnerabilities are not fixed right away because Microsoft cannot
>>> reproduce the vuln, which is the first step towards writing a patch. If
>>> the finder is not available to work with Microsoft on reproducing the
>>> vuln, that makes the task harder.
>>
>> Well, certainly, oter people can reproduce this one...now sure why MS
>> could
>> not... :-)
>
> Let's be clear here... the vuln reported in May was a denial of service,
> and Microsoft correctly prioritized it as such.

No, let's be crystal clear here. The vulnerability reported in May is the
SAME vulnerability now. Microsoft did not EVALUATE the security hole
correctly, and as such, classified it as a "low" instead of a critical. In
short, MS screwed up and screwed their customers again....


>>> I could be mistaken, but I understand there is code out there [at the
>>> frsirt.com site for example] and that Microsoft has confirmed the code.
>>> Some people have reported problems getting the exploit code to work,
>>> suggesting my "Microsoft cannot fix what they cannot repro" theory could
>>> be correct.
>>
>> ...I tested it today and, bang, got a calculator...have you tried?
>
> The discussions I've heard in the public are it works for some and not
> others. I believe it's harder to figure out how to turn a denial of
> service vuln into a remote code execution one if it only occurs on certain
> system
> configurations. Otherwise, the vuln finder might try successful exploit
> code on a system that is not vulnerable and discard it as non-working.
>
> I'm not saying Microsoft had any trouble reproducing the code that came
> out a few days ago... I'm saying this makes it harder for MS or the
> original
> finder to turn the DoS into a remote code exploit. It seems likely the
> original finder would have tried to do this and probably only released
> this
> as a DoS when s/he was unable to do so. S/he also had six months
> afterwards in which to try to turn this into a remote code execution vuln,
> as did the rest of the world.

So, if MS was on the ball, we would not be having this conversation would
we?

>> In a nutshell, you always try to pu a spin on MS.
>
> I don't always spin things in Microsoft's favor.

Well, honestly, you do...you are much more apt to try and defend their
position rather than simply saying MS dropped the ball again.

>> MS dropped the ball, yet again, but classifiying this as a "low risk"
>> when clearly, it is a critical risk...put the blame where it belongs.
>> Microsoft screwed everyone again....like clockwork.
>
> It's a critical risk now that remote code execution is found to be
> possible.

No. It always WAS a critical security hole. Microsoft, did not spend much
time evaluating this security hole. If they have it WOULD NEVER had been
labled a "low" risk. If they had spent time, they would have seen the
obvious; that remote code execution is possible.

> If it was so easy for Microsoft to research the denial of service
> vulnerability in May and figure out how to make it exploit code, then why
> didn't anyone else do it? It's not like there's no one on the Internet
> trying to turn IE denial of service vulns into remote code execution
> vulns.

The specifics were never released. Maybe, Microsoft should just release the
specifics of vulnerabilities and let the World tel that which ones to
patch. Clearly, this would be better than relying on them to produce
quality....

> I suspect it wasn't as easy as you think. Neither of us are really IE
> vuln finders, so in the end we're both guessing about how easy or hard it
> may have been to research this vuln.

Well, when you are the biggest software company in the World, making how
many billions a year?, I do expect better....but hey, it takes time and
resources to put that XBox 3 whatever out...

> You may also be thinking that Microsoft could have fixed this six months
> ago
> had they just fixed the denial of service. That is not necessarily the
> case. It is entirely possible that if they had released a patch for the
> DoS attack, the patch may not have prevented this remote code execution
> vuln. Since MS did not know the details of this remote code execution vuln
> six months ago, they would not have been able to test it against their
> patch.

So, what you are saying is that Microsoft is incompetent. OK, I will agree
with that.

> It's also possible that properly fixing this vuln requires a major
> architectural change and that was why they delayed on releasing a patch,
> we don't know.


Again, excuses. Face it. Microsoft gets away with this crap because people
are lazy and do not look for better software from alternate
companies/sources. People do not hold Microsoft's feet to the fire because
most people in the IT world are quite ignorant. You pay an extreme amount
of money for their "solutions" then make feeble excuses trying to pretend
your "investment" was worth it. All along ignoring the obvious; you just
got ripped off!

Imhotep

Posted by Martin Spencer-Ford on November 23, 2005, 7:47 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
karl levinson, mvp wrote:
>
>>Karl Levinson, mvp wrote:
>>
>>
>>>
>>>
>>>>I do not believe that there is real malicous code flouting arround for
>>>
>>>this,
>>>
>>>>this has been a known issue since May.....I believe MS has marked it as
>>>
>>>low
>>>
>>>>and as such did nothing about it....typical.
>>>
>>>You left out the reason why: "The vulnerability targeted by the exploit
>>>was originally announced in May as a stability issue resulting in the
>>>browser closing."
>>>
>>>There are tons of ways an attacker could cause IE or any other browser to
>>>lock up or shut down, and little reason for an attacker to want to do so.
>>>I do not at all blame Microsoft for putting this vulnerability on the
>>>back
>>>burner as it was known in May.
>>
>>I will. Certianlly, someone did not reasearch this vulnability well. They
>>slapped and incorrect statement about it being a "low" priority and well,
>>put their users and clients where they are now. F'd....but then again, the
>>XBox was coming out...
>>
>>
>>>Many vulnerabilities are not fixed right away because Microsoft cannot
>>>reproduce the vuln, which is the first step towards writing a patch. If
>>>the finder is not available to work with Microsoft on reproducing the
>>>vuln, that makes the task harder.
>>
>>Well, certainly, oter people can reproduce this one...now sure why MS
>>could
>>not... :-)
>
>
> Let's be clear here... the vuln reported in May was a denial of service, and
> Microsoft correctly prioritized it as such.
>
>
>>>I could be mistaken, but I understand there is code out there [at the
>>>frsirt.com site for example] and that Microsoft has confirmed the code.
>>>Some people have reported problems getting the exploit code to work,
>>>suggesting my "Microsoft cannot fix what they cannot repro" theory could
>>>be correct.
>>
>>...I tested it today and, bang, got a calculator...have you tried?
>
>
> The discussions I've heard in the public are it works for some and not
> others. I believe it's harder to figure out how to turn a denial of service
> vuln into a remote code execution one if it only occurs on certain system
> configurations. Otherwise, the vuln finder might try successful exploit
> code on a system that is not vulnerable and discard it as non-working.
>
> I'm not saying Microsoft had any trouble reproducing the code that came out
> a few days ago... I'm saying this makes it harder for MS or the original
> finder to turn the DoS into a remote code exploit. It seems likely the
> original finder would have tried to do this and probably only released this
> as a DoS when s/he was unable to do so. S/he also had six months afterwards
> in which to try to turn this into a remote code execution vuln, as did the
> rest of the world.
>
>
>>In a nutshell, you always try to pu a spin on MS.
>
>
> I don't always spin things in Microsoft's favor.
>
>
>>MS dropped the ball, yet again, but classifiying this as a "low risk" when
>>clearly, it is a critical risk...put the blame where it belongs. Microsoft
>>screwed everyone again....like clockwork.
>
>
> It's a critical risk now that remote code execution is found to be possible.
>
> If it was so easy for Microsoft to research the denial of service
> vulnerability in May and figure out how to make it exploit code, then why
> didn't anyone else do it? It's not like there's no one on the Internet
> trying to turn IE denial of service vulns into remote code execution vulns.
> I suspect it wasn't as easy as you think. Neither of us are really IE vuln
> finders, so in the end we're both guessing about how easy or hard it may
> have been to research this vuln.
>
> You may also be thinking that Microsoft could have fixed this six months ago
> had they just fixed the denial of service. That is not necessarily the
> case. It is entirely possible that if they had released a patch for the DoS
> attack, the patch may not have prevented this remote code execution vuln.
> Since MS did not know the details of this remote code execution vuln six
> months ago, they would not have been able to test it against their patch.
>
> It's also possible that properly fixing this vuln requires a major
> architectural change and that was why they delayed on releasing a patch, we
> don't know.
>
>
>
>

Well here's my 2 pennies worth ....

MS get told of the vulnerability maybe in a cryptic clue, such as there
is a flaw in there chaps, can you see what it really is, i will give you
6 months to suss it, after all you do have the source code, and after
all you have all these security evaluators checking your code, and
telling the developers how to avoid the pitfalls, but if you can't
manage to find it with all your extensive facilities and minds, then i
will make it real clear for you.

Now i have nothing but respect for the guys who take the time to reverse
engineer and find these exploits, not because of the damage they can do,
but for their skills, and i find it a crying shame that many use those
skills to cause problems, but when you think of the total disregard of
the EULA committed by these people, and with microsofts policy of being
heavy handed with legal pursuits, its little wonder that there are few
who want to work with them to reproduce the failures, its often easier
to release the flaw and then merge back into the crowd, but with a smug
grin of satisfaction, and a possible slap on the back from other exploiters.

All the best guys

Martin Spencer-Ford
(TpwUK)

Similar ThreadsPosted
Zero-day IE exploit... November 22, 2005, 7:46 pm
Possible new exploit... Have you seen these? April 26, 2006, 2:03 pm
Re: Where is the IE zero day exploit in the news... November 27, 2005, 2:12 pm
Why was IE6 vulnerable to the wmf exploit? January 5, 2006, 7:45 pm
Dcom Exploit May 16, 2008, 2:14 pm
Bloodhound.Exploit.54 bundled with I.E.beta7 ?? June 3, 2006, 2:43 pm
My machine was compromised via mshta.exe. Is this a new exploit? July 28, 2006, 9:28 pm
XP security exploit causes BSOD - when will patch be released? July 7, 2005, 1:37 pm
Reporting cross-platform possible exploit vulnerability November 25, 2005, 11:45 am
Unknown exploit - Boot.ini/Windows shares February 20, 2006, 5:05 am

The site map in XML format XML site map

Contact Us | Privacy Policy