Date: Tue Mar 28 22:52:49 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Security Alert: Unofficial IE patches appear
	on	internet

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Learn how to use plain text e-mail, kid.

n3td3v wrote:
> On 3/28/06, *Matthew Murphy* <mattmurphy@...rr.com
> <mailto:mattmurphy@...rr.com>> wrote:
> 
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: RIPEMD160
> 
> 
>>     Newsflash, idiot: you're not the first one to think of this.  Plenty of
>>     people at Microsoft beat you to the punch.  When the threat environment
>>     created by a vulnerability is as serious as this case and the available
>>     code-independent workarounds (i.e., other than patches) are so poor,
>>     Microsoft will be inclined strongly against holding on to this patch.
> 
>  
> Matthew firstly starts off his rant by claiming n3td3v is an idiot and
> then uses some clever words to talk about something thats not entirely
> clear, but I guess what he is trying to say is hidden inbetween his
> wording.

Perhaps not to you.

>     I'd venture to bet that Microsoft will make this patch available as soon
>     as they're confident in the quality of it.  Their first patch day
>     is, at this point, nothing more than a benchmark.  They might beat it but 
>     they almost certainly won't fall short of it unless there are major quality
>     issues.
>   
> You would venture to bet? Theres no betting involved. They do only
> release a patch after Q.A testing. Although they can in certain
> situations bring forward a patch sooner. Its not about beating a patch
> day. Microsoft often have patches ready but wait for the corporate known
> about Tuesday and Thursday press release days that all corporations
> globally adhere to in the world of security and otherwise.

You completely fail to answer my argument.  When Microsoft faces a
vulnerability where the threat is this significant and the
counter-measures are this poor, patches will get released early if
they're ready.

Microsoft can do this rarely enough that most organizations will be
prepared for an out-of-cycle release.

Out-of-cycle releases are necessary only when:

1) The vulnerability at issue is being or will imminently be exploited.

2) The vulnerability at issue is a high-impact threat (i.e., code
execution, total system failure, etc.)

3) The vulnerability at issue is easy to exploit or difficult to block
(true of most browser exploits)

4) The workarounds available are of poor quality.  This can be true when
a workaround is a partial solution or non-solution (i.e., update AV) or
when the workaround solves the attack scenario but has such a high
impact on purpose-critical functionality to be unusable.

The fourth factor is entirely a matter of internal, under-the-hood
product flexibility.  If Microsoft is having to issue out-of-cycle
patches on a regular basis, that means that they need to be expanding
the configurability of their product.  I proposed features like
disabling specific methods, rendering engines, etc., that allow an
immediate stopgap until a patch can be issued.

The ultimate goal, of course, is to make a piece of code so modular that
attacks against it can be foiled by simply removing or replacing the
vulnerable function for a time until a longer-term solution can be
developed.

>     The other thing that you obviously have no clue of is that even a
>     release on patch Tuesday is "out-of-cycle" as far as Microsoft's test
>     processes are concerned.  Microsoft normally issues IE patches on a two
>     month cycle -- February, April, June, August, October, December.  
>  
> The other thing I "obviously" have no clue about? There you go on
> assuming my knowledge base, even though i've been around the security
> scene longer than you. 

There is no "scene".  Security right now is a set of groups and
individuals, each of whom want something different and only occasionally
desire to work together.

I highly doubt that you've been around longer than me, unless you can
provide something you've ACTUALLY DONE before I became involved in
research.  If you count the days from before I did vulnerability
research, my experience stretches back as far as you claim yours does.

> Sure, Microsoft have a "comfortable" release
> cycle, although thats just to space everything out in their minds as a
> corporation. Remember the days before Microsoft started patch tuesday?
> Yeah, they would release critical patches whenever they see fit. To me
> the mistake was that they started "Patch Tuesday", so as a corporation,
> even though its a good thing for normal bug fixes to be issues only once
> monthly, it makes it harder for Microsoft to release a patch out of
> cycle for "critical flaws". 

I'm assuming, by "critical" you actually mean vulnerabilities of this
sort (unpatched, public and exploited) rather than those assigned a
"critical" risk by Microsoft in later bulletins.

> You seem to think theres not employees at
> Microsoft who don't want to release patches inbetween patch tuesday.

Nope.  In fact, I'm personally in contact with some employees who find
that to be the reasonable course of action on issues such as this --
_if_ the patch is ready before Tuesday rolls around.  For Microsoft to
COMMIT to a 20-day timeframe is pretty impressive (considering their
typical performances).  They also haven't ruled out an out-of-cycle
patch *ahead* of that date, either.

Microsoft has put customers on notice: be ready for a patch BY April
11th.  That's laudable, in my opinion, and may be a BENEFIT, rather than
a negative consequence, of patch Tuesday.

> So you see,
> its not that Microsoft don't agree with out of cycle patch releases, its
> just they don't want to spoil their overall patch tuesday policy.
> Microsoft don't like to send out mixed messages, so until the higher
> folks at MS start listening, then patch tuesday will continue to pose a
> threat for when critical remote access flaws come along.

Microsoft has already demonstrated a willingness to patch on an
as-soon-as-possible basis when vulnerabilities pose an extreme risk, as
I've outlined in the four points above.  They did it with WMF.

The bottom line, though, is this: no scheduling change at Microsoft will
eliminate the zero-day threat.  To do that, better defenses against
unknown vulnerabilities (both those intrinsic to the exposed products
and add-on defenses) are required.

>>     You can bet that they don't release patches for non-public
>>     vulnerabilities with a mere 20 days of testing (and that assumes they
>>     started on the patch the day the issue was published).  When I reported
>>     a vulnerability in August that was (originally) scheduled for a
>>     bulletin, Microsoft said that if it made a bulletin, the earliest would
>>     be December.  That was just shy of four months, and they weren't even
>>     certain it would make that release cycle.  Microsoft doesn't have that
>>     kind of time here, and it's a damn sure bet that they aren't taking it.
>  
> We're not talking about non-public flaws! I'm talking about 0-day that
> goes into the wild, where exploit code is then release, and where media
> hype is created and then eeye and the others create a bigger security
> issue than the intial flaw.

Yet again, you fail to argue anything on-point.  The point I made is
that for Microsoft to be ready with a patch in time for this Tuesday is
a strong statement, patch Tuesday or not.  This release isn't
"scheduled", even if it falls into the monthly rotation.  That is the
point you fail to grasp again and again.

Secondly, eEye and Determina created NO security issue by releasing
these patches.  The fact that third-party patches exist for this
vulnerability is a symptom of a bigger problem.  That is, of course, the
fact that the workarounds for this vulnerability... absolutely suck.
Plain and simple.

If you want people to stop releasing third-party patches, you need to
look at ways to eliminate the demand -- the need for people to take
drastic measures to protect themselves.  Better, more general zero-day
defense is a HUGE part of that.

>>     Some good documentation on Microsoft's patch development processes (and
>>     how they vary for products) would help you avoid this ignorant and
>>     noobish mistake and put an end to ignorant media reporting about how
>>     Microsoft is sticking to its schedule with this patch -- which couldn't
>>     be much further from the truth.
>   
> Microsoft are about to release out of its cycle again for this IE
> vulnerability, according to my contacts.

They're certainly out of the standard four-to-six-month test cycle, and
I expect that they most likely WILL release an early patch for this
vulnerability, if and only if the patch is of release quality before
April 11th.

> Because of patch tuesday, it now makes it more difficult for
> them to break this

Duh... because their previous patch process was disorganized.  It is a
fact of today's world that Microsoft's patch releases have the potential
to cause a significant shift in the threat landscape, in and of
themselves.  The patch is now available for professionals to
reverse-engineer, which spreads knowledge about the vulnerabilities that
have been fixed and could increase the likelihood that these
vulnerabilities will be imminently-exploited.

Recognizing that, Microsoft selected a monthly schedule so that those
affected by these vulnerabilities could, to some degree, PLAN on these
releases.  Single, scheduled, large sets of updates are far more
efficiently deployed than sporadic, unplanned single updates, meaning
that protection occurs for more people more quickly after the patch release.

Organization necessarily trades off with immediacy, but not necessarily
with security.  In this case, though, that trade off certainly DOES
exist.  This is why I believe Microsoft most likely will release the
patch as soon as testing completes (if the option presents itself)
rather than delaying it until April 11th.

> its only the issues of
> critical flaws hitting the wild, where exploit code is released, where
> media hype is created 

...when Microsoft allows exceptions to the "Patch Tuesday" schedule.

Eliminating Patch Tuesday is a non-starter.  It's just a terrible idea.
 So, given that, we can only hope for Microsoft to make more aggressive
use of exceptions for active exploitation and then to address any need
this creates for a disproportionate number of deviations from schedule
(i.e., emergency patches because no workarounds/poor workarounds exist).

> and then where folks like eeye release a patch,
> which will only ever be available to the security community and all of
> its malicious users, 

Disproven by experience.  Legitimate users who have nothing to do with
the industry other than knowing me are using the fixes, because I cannot
convince them to dump IE...

The patches by eEye/Determina are a stopgap measure for users who see
the risk of being exploited as greater than the compatibility risk of
applying a reputable, if only less-tested, third-party patch.  They are
out there.

> where script kids can patch systems for their own
> evil agendas, 

The ability to patch a box against an unknown exploit is not a
significant furtherance to an "evil agenda".  It's a detectable action
(especially with a run-time patch) and once someone owns your box, their
"evil agenda" is intact, anyway.

> phishers can release bogus eeye
> patches, or release a patch under another name with malicious code
> inserted, a lot of the time to execute another malicious code, unrelated
> to the intial exploit code vulnerability.

Sure... if users get used to being e-mailed a link to a patch and
clicking on it.  That's why eEye, Determina and folk like them don't do
this.  Users have to come to them.

This means that a lot of users won't know about the patch, but they
shouldn't get duped as a result of being "trained" to read and click.
That's why, if you're going to recommend a third-party fix to a
less-clued user (which should always be done carefully), you go OUT OF
YOUR WAY to ensure you don't distribute it in a fashion that would make
them more likely to accidentally install malicious code.

>     I guess it's easier to bash Microsoft for made-up, delusional reasons
>     like "they're standing and watching while people get 0wn3d!" than for
>     the real reasons (i.e., a six-month "standard procedure" patch process).
>     Those in the latter category actually require some work to understand,
>     and apparently don't give people the instant ego boost of thinking
>     they're "taking on the monopoly".  
>  
> NO, i'm not anti-Microsoft, lots of my friends work there. The only evil
> is folks like eEye providing tools (patches) to the security community,
> where legitimate users will never get a hold of, but you can bet
> malicious users will and use the patch to their advantage.

Plenty of legitimate users will get a hold of them.  Orders of magnitude
fewer in number than an official patch?  Sure.  But a significant number.

> Microsoft only ever releases out of its new patch tuesday cycle when
> eeye and all the others release third party patches. If you really were
> pro Microsoft, you would be behind me in calling for all third party
> patches to be slammed as a bad thing for Microsoft and the security
> community and the public at large. 

I disagree.  I don't think the third-party patches are a "bad thing" for
anybody.  What is bad is reckless deployment of those patches, but I
don't think that means we should take the choice to use them away from
people.

My view could not be described as pro-Microsoft or anti-Microsoft.  I
think those terms are really kind of ridiculous.  I'm pro-security, and
if that means criticizing Microsoft, so be it.  On the other hand, if it
means criticizing people like you who attack Microsoft's policies for no
reason, so be it.

> Theres folks at Microsoft in complete
> agreement at what i'm saying. Who agree, like me, that patch tuesday is
> a good thing normally, but as soon as the evil third patches are
> released, then Microsoft has no choice but to release out of cycle.

I don't think Microsoft's choices to release ahead of schedule have much
to do with third-party patches coming out.  I think the choice to
release ahead of the 11th (if it is indeed made here) will be made
because the workarounds available are not adequate to sustain operations
in the current threat environment.

That is the *reason* third-party patches come out and it is also a major
reason why the official patch process would be feeling some pressure.
It's not really been demonstrated that Microsoft's hand is forced
*because* of third-party patches.  Rather, what happens is that the
things that motivate Microsoft to expedite patch delivery are,
understandably, similar or identical factors to those that motivate the
development of third-party patches.

> If you had contacts at Microsoft like I do, you would realise everything
> i'm saying is in line with what individuals within ms are thinking.

"If I had contacts at Microsoft"... isn't that a laugher.  I've
personally met more people at Microsoft than you could probably count
and I'm in contact with some of them on a daily basis.

> Patch Tuesday = Good before third party patches appear

Patch Tuesday = Good period, if it's not treated as some inflexible
gospel ala the 11th commandment ("Thou shalt release security patches on
the second Tuesday").  When exceptional circumstances arise, the
schedule should bend accordingly.

> Third party patch = Evil

Third-party patch = Good, if the verification of the patch's function is
performed by competent, trustworthy people and that patch is only
deployed in environments where compatibility is not critical and time
for recovery from compatibility problems is acceptable (if they arise).

> Patch Tuesday = Bad for everyone after third party patches appear, even
> Microsoft, because they hate breaking out of the Patch Tuesday policy,
> even though a lot of the time a patch is ready for distrubution,
> Microsoft don't want to break out of company policy, even though
> indviduals at Micrsoft wish it was easier for a multinational to
> backtrack on its policy for critical *public 0-day*

For reasons I've already stated, strict adherence to the Tuesday
schedule is bad in these cases.

But... sticking to the Tuesday schedule isn't bad *because of*
third-party patches, it's bad *in times when a third-party patch is
necessary*.  That is the difference that your "advice" (if you call it
that) fails to account for.

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38

iD8DBQFEKbBlfp4vUrVETTgRAzDqAKCUyYYFvpD570zhTMxPj2B7zerM0QCePkok
p0M7xp0ZMPG0XJ0a7XaUniA=
=ltoi
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3436 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060328/b9d48a70/smime.bin

Powered by blists - more mailing lists