Zero-day IE exploit...

"Microsoft has expressed concern that this new vulnerability was not
disclosed to them first, potentially putting users at risk. Although there
is currently no patch for this vulnerability, disabling Active Scripting or
switching to an alternate browser such as Mozilla Firefox would effectively
mitigate the risk."

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.

Advertisements

Imhotep <> writes:
> 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.
>
> http://www.securityfocus.com/brief/58

To be fair, in May, everyone was convinced the problem was just a DOS
condition, and not exploitable for remote access. Only recently
has proof of concept code emerged to exploit it.

Advertisements

"Imhotep" <> wrote in message
news:...
> "Microsoft has expressed concern that this new vulnerability was not
> disclosed to them first, potentially putting users at risk. Although there
> is currently no patch for this vulnerability, disabling Active Scripting
or
> switching to an alternate browser such as Mozilla Firefox would
effectively
> mitigate the risk."
>
> 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.
>
> http://www.securityfocus.com/brief/58
>
> Imhotep
###############################
I have been disabling active scripting along w/ other things in IE for
years. It has served me well.
donnie

Imhotep wrote:
> "Microsoft has expressed concern that this new vulnerability was not
> disclosed to them first, potentially putting users at risk. Although there
> is currently no patch for this vulnerability, disabling Active Scripting or
> switching to an alternate browser such as Mozilla Firefox would effectively
> mitigate the risk."
>
> 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.
>
> http://www.securityfocus.com/brief/58
>
> Imhotep
Great Link thanks!

"Imhotep" <> wrote in message
news:...
> 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.

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.

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.

As far as is public, you are correct--there is a proof of concept page which
can run Calc.exe on your system.

It has been known since May that there was a denial of service
vulnerability.

So, yesterday this was shown to allow code execution in some cases--and
released to the public and to Microsoft at the same moment. Do you feel
protected by this action?
--

"Imhotep" <> wrote in message
news:...
> "Microsoft has expressed concern that this new vulnerability was not
> disclosed to them first, potentially putting users at risk. Although there
> is currently no patch for this vulnerability, disabling Active Scripting
> or
> switching to an alternate browser such as Mozilla Firefox would
> effectively
> mitigate the risk."
>
> 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.
>
> http://www.securityfocus.com/brief/58
>
> Imhotep

Bill Sanderson wrote:
> As far as is public, you are correct--there is a proof of concept page
> which can run Calc.exe on your system.
>
> It has been known since May that there was a denial of service
> vulnerability.

Well, someone did not review this exploit well. In fact, I would say that MS
dropped the ball in evaluating what the security hole can do....
> So, yesterday this was shown to allow code execution in some cases--and
> released to the public and to Microsoft at the same moment. Do you feel
> protected by this action?

Well, I do sure. However, the point you are trying to make is if the "news"
should have been posted. My answer is this. MS has know about this since
May....MAY...it is now the end of November.

Clearly they have had plenty of time to fix it...put the blame where it
belongs.

Karl Levinson, mvp wrote:
>
> "Imhotep" <> wrote in message
> news:...
>
>> 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...
> 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?

In a nutshell, you always try to pu a spin on MS. However, a fact is a fact.
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.

Winged wrote:
> Imhotep wrote:
>> "Microsoft has expressed concern that this new vulnerability was not
>> disclosed to them first, potentially putting users at risk. Although
>> there is currently no patch for this vulnerability, disabling Active
>> Scripting or switching to an alternate browser such as Mozilla Firefox
>> would effectively mitigate the risk."
>>
>> 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.
>>
>> http://www.securityfocus.com/brief/58
>>
>> Imhotep
> Great Link thanks!
>
> Winged

Donnie wrote:
>
> "Imhotep" <> wrote in message
> news:...
>> "Microsoft has expressed concern that this new vulnerability was not
>> disclosed to them first, potentially putting users at risk. Although
>> there is currently no patch for this vulnerability, disabling Active
>> Scripting
> or
>> switching to an alternate browser such as Mozilla Firefox would
> effectively
>> mitigate the risk."
>>
>> 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.
>>
>> http://www.securityfocus.com/brief/58
>>
>> Imhotep
> ###############################
> I have been disabling active scripting along w/ other things in IE for
> years. It has served me well.
> donnie

Imhotep <> writes:
> ...I tested it today and, bang, got a calculator...have you tried?
>
> In a nutshell, you always try to pu a spin on MS. However, a fact is a fact.
> 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.

Oh, yes I'm sure this was quite an evil plot. (rolls eyes).

I dislike the evil empire as much as the next open source champion and
security professional, but you're not being reasonable on this one.

They put a low on it because no exploit was thought possible. Firefox
has the same sort of situations in its young history too.

Don't like it? Quit whining and download Firefox like the rest of
us. Save the wailing and moaning for a situation where Microsoft
actually might have a smoking gun situation.

Todd H. wrote:
> Imhotep <> writes:
>> ...I tested it today and, bang, got a calculator...have you tried?
>>
>> In a nutshell, you always try to pu a spin on MS. However, a fact is a
>> fact. 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.
>
> Oh, yes I'm sure this was quite an evil plot. (rolls eyes).

No evil plot, they (Microsoft) dropped the ball again. No evil plot, just
incompetence...so, roll you eyes all you want.
> I dislike the evil empire as much as the next open source champion and
> security professional, but you're not being reasonable on this one.

I disagree, they (Microsoft) dropped the ball in evaluating this security
hole. They knew about it for sometime....

But, hey, did you get your new XBox?
> They put a low on it because no exploit was thought possible. Firefox
> has the same sort of situations in its young history too.

This is not about Firefox or Opera or whatever. This is about the richest
company on the Planet that no matter can't do anything right. But hey, did
you buy your new XBox?
> Don't like it? Quit whining and download Firefox like the rest of
> us. Save the wailing and moaning for a situation where Microsoft
> actually might have a smoking gun situation.

Did you even bother to look at my newsheaders? I do not use MS
products...and P.S. I will whine all I want. If you do not like it filter
me or shutup.

"Imhotep" <> wrote in message
news:...
> Karl Levinson, mvp wrote:
>
>>
>> "Imhotep" <> wrote in message
>> news:...
>>
>>> 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.

karl levinson, mvp wrote:
>
> "Imhotep" <> wrote in message
> news:...
>> Karl Levinson, mvp wrote:
>>
>>>
>>> "Imhotep" <> wrote in message
>>> news:...
>>>
>>>> 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!

karl levinson, mvp wrote:
> "Imhotep" <> wrote in message
> news:...
>
>>Karl Levinson, mvp wrote:
>>
>>
>>>"Imhotep" <> wrote in message
>>>news:...
>>>
>>>
>>>>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.

Martin Spencer-Ford wrote:
> karl levinson, mvp wrote:
>> "Imhotep" <> wrote in message
>> news:...
>>
>>>Karl Levinson, mvp wrote:
>>>
>>>
>>>>"Imhotep" <> wrote in message
>>>>news:...
>>>>
>>>>
>>>>>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)

Every good comments. Microsoft has in many ways caused the current
situation...

"Imhotep" <> wrote in message
news:...
>> 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.
> Every good comments. Microsoft has in many ways caused the current
> situation...

Oh come now. If a vuln finder was really concerned about being sued,
finding and releasing a vuln without contacting Microsoft increases rather
than decreases your likelihood of being hassled.

The vuln finders that ARE worried about being hassled typically stop finding
and/or releasing vulns publicly, as RFP and others did. They typically do
NOT release them direct to the public as this vuln finder did, because that
doesn't really get rid of the risk of being hassled. None of this really
explains why the vuln was released as a DoS in May and took until November
before anyone admitted to discovering how to use it to execute code
remotely.

While Microsoft has occasionally tried to hassle a few vuln finders for this
reason or that, other vendors like Cisco and Oracle are much worse than
Microsoft, in that they actually hassle vuln finders that are working
responsibly with them.

Anyways, if it's true as you suggest that this vuln finder did not release
details about the vuln to Microsoft, then it's absurd to fault Microsoft for
not independently figuring out the vulnerability.

"Imhotep" <> wrote in message
news:...
> Bill Sanderson wrote:
>
> > As far as is public, you are correct--there is a proof of concept page
> > which can run Calc.exe on your system.
> >
> > It has been known since May that there was a denial of service
> > vulnerability.
>
> Well, someone did not review this exploit well. In fact, I would say that
MS
> dropped the ball in evaluating what the security hole can do....

You're right *and* wrong on this one, IMHO.

It's probably worth remembering that, when people to refer to the "same
exploit", they may be talking about the same line of code, or the same
10,000 line-of-code RTL/DLL/whatever. In this case it involves JScript's
window() object, th code for which could be in one place or shotgunned all
over the shop.

"Same" does not always mean "same", if you see what I mean ;o)

Just as a reminder, if you're a support tech and receive a bug report, the
sequence goes something like this:

1. Try to gather as much information about how the bug manifests itself,
what it does, and grade it accordingly. Under this method, a
one-in-a-million serious bug might actually get a lower priority than
something that, say, simply causes major annoyance to 90% of your customer
base.

2. Initial code inspection, looking for the obvious (e.g. a developer with a
propensity to not initialize his variables. If I had a penny for every time
that this one turns up, I'd have.. um.. well, enough for a beer or two )

3. If that didn't find the bug that you were looking for (remember that
phrase), then keep looking. A lot of modern IDEs and tools let you pump data
into a debugger to look for that specific condition (remember that phrase as
well). In the old days, you'd be looking at a lot more theory and -
probably - a more structured approach. Because you didn't have any choice.

4. Once the bug's been tracked-down, fixed, and module-tested, ship it
either to the customer or to QA - depends upon the bug, the customer, and
who you work for. Usually a bug is of high enough priority that you won't
get time to smooch around the rest of the code, even in the unlikely event
that you're permitted to change stuff that hasn't been reported as broken -
after all, each change could introduce a /new/ bug.

5. Move on to the next job.

In general (99%+ of cases, I'd imagine) you aren't sufficiently
under-employed to just rummage through someone else's code. Which makes your
stipulation more than a little unreasonable - no matter how large they get,
I very much doubt that MS will ever employ one prson per module, or line of
code. Mind you, looking after a comment line would be a pretty cushy numberD

In any event, you tend to find what you're looking for; in the case of the
infamous Linux kernel attempted back-door, someone looked because he rceived
an odd error message. Someone else pointed-out the C quirk that gave you
root (IIRC, an "=" instead of an "==")
> > So, yesterday this was shown to allow code execution in some cases--and
> > released to the public and to Microsoft at the same moment. Do you feel
> > protected by this action?
>
> Well, I do sure. However, the point you are trying to make is if the
"news"
> should have been posted. My answer is this. MS has know about this since
> May....MAY...it is now the end of November.

So? If the code's not looked-at (i.e. doesn't need to be changed), then it
could have been a lot older. But. Here's the bit where you're so very
right... according to the original exploit description by Benjamin Tobias
Franz, *it was a bug that had already been fixed*.

*That's* where there's blame attached to Microsoft's actions - some idiot
reintroduced a serious bug.
> Clearly they have had plenty of time to fix it...put the blame where it
> belongs.

Well, aside from the rather serious problem above (what other fixes were
lost?!?), a quick look at the Secunia advisory
(http://secunia.com/advisories/15546) reveals that, although Franz reported
the DoS bug, it was someone else entirely, in a different country, that
released the remote execution exploit. One Stuart Pearson of "Computer
Terrorism UK". Interesting company name. Appears to be a one-man band in
Maltby (no criticism implied or intended - most of this stuff is found by
individuals, IME)

As an aside, his PoC causes Firefox to hang... IE took about a minute or so
(fast machine on a 3Mb line), and involved ignoring a popup window
(presumably blocked by default on an XP machine) and clicking "OK" on
several different "do you want to run this script" prompts... I can follow
his logic, so I didn't look at the PoC code itself.

Oh, as simply as an aside, I've personally handled a CERT advisory for one
of my company's products, so I've a fairly clear idea of the process.

--

Hairy One Kenobi

Disclaimer: the opinions expressed in this opinion do not necessarily
reflect the opinions of the highly-opinionated person expressing the opinion
in the first place. So there!

Martin Spencer-Ford wrote:
> 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.

That's a little optimistic. The reports sent to MSRC are not always clearly
written, with simple instructions on how to reproduce the problem. Often, a
crash is reported as a vulnerability, despite the gulf between the two -
there are many ways to crash a computer without introducing a vulnerability.
Despite this, every report sent to gets an
investigation, with an engineer and a security program manager often
spending several days trying various scenarios that might be able to
reproduce the original problem, and communicating with the original
discoverer (where there is a return address) to try and nail down the extent
of the flaw.
> 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.

Microsoft has spent (and continues to spend) a considerable amount of time
and effort reaching out to exploit discoverers, to allow them to engage with
Microsoft on a more direct, personal level, rather than the usual
"big-company" style of having an email drop-box that may, or more likely,
may not, be responded to.

If you're going to point out a company as the canonical "bad example", I'd
say Oracle fits that description far better.

Share This Page

Welcome to Velocity Reviews!

Welcome to the Velocity Reviews, the place to come for the latest tech news and reviews.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to chat with other enthusiasts and get tech help from other members.
Sign up now!