Microsoft Zero Day security holes being exploited

Michael Bednarek wrote:

On Fri, 22 Sep 2006 22:37:55 -0400, imhotep wrote in
microsoft.public.security:

Microsoft Zero Day security holes being exploited

"Microsoft has issued warnings about a serious flaw in Internet Explorer
that allows attackers to hijack a PC via the popular browser
[snip]

Workaround:
regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
I've done that and tested successfully (see below).

A non-Microsoft fix: http://isotf.org/zert/download.htm.

To test, see (at your own risk) http://www.isotf.org/zert/testvml.htm.


Nice job...

Imhotep

"imhotep" wrote in message
...
Ian wrote:


Think we'll only achieve secure computing when C is dropped in favour of
a
better language. The list of buffer-overflow exploits in every single
major software-package gets monotonous.


As a C programmer (one of many languages I know) that is one of the most
foolish statements I have heard all year. Buffer-overflows are not caused
by the programming language. They are caused by bad
programmers!!!!!!!!!!!!

The problem here is that some people want a language to cover up their
lack
of programming skills!!!!!!! Utter foolishness!!!



After all, nobody ever got prosecuted for 'Not realising that guy was
going to do something silly.' But people do get prosecuted for driving
cars with no brakes.


If you do not possess the skills to drive a car, why are you attempting to
drive it??? Driving a car requires a skill set, if you do not possess it,
don't drive...in either case don't blame the car for your ineptness.


If you are a skilled car driver why would you choose to use only an
inferior, cheaply made, sardine tin of an auto that could not meet the
safety standards of many governments of the day ?

Why did safe sting classes come about?

Would you choose to go back to GO TO based programming?

Use of a language that enforces safe code is a good thing.

Remember Dijstra? The set of 4 constructs proved sufficient for
any general purpose language? Remember the arguably academic
language Pascal (Wirth?) designed to show this? Remember how
that ushered in a new era in programming and vastly simplified
software lifecycles?

Are you saying that languages designed to not allow major problems
plaguing the sofeware industry are worth naught ?

You surely do sound to be doing so.

--
ra

ps. my, my - your follow-ups are under your control

Karl Levinson, mvp wrote:


"imhotep" wrote in message
...
It really make my blood boil knowing that they patched the DRM security
hole
in a couple of days, yet I am sure by the time this patch comes out a
crap load of people will get infected...

I assure you, a crap load of people will NOT be infected by this or any
other IE vuln in the future. IE vulns just don't do that.

So, your guarantee means what? Will you personally pay for damages to user's
PCs? Will you pay for the IT departments cost at rebuilding/removing
spyware, viruses, etc?

If you are going to make such a guarantee back it up, like most
guarantees...You see it is pretty easy to make such a statement when you
have no direct possibilities caused by the repercussions of such foolish
statements.

So I guess the Entertainment Industry is more important?

No.

Then how do you explain the record breaking time to patch Microsoft's DRM
hole? Three days to patch? Please explain (no propaganda necessary).

Imhotep

"imhotep" wrote in message
...
Karl Levinson, mvp wrote:


"imhotep" wrote in message
...

To think that the World's richest software company can't fix a serious
patch in a reasonable amount of time is inexcusable (not doubt Roger
will
try though). To think that a third party can release a patch in 2 days
but the World's richest software company can't is inexcusable. To think
that Microsoft can patch a DRM security hole in a record 2-3 days leads
one to believe that Microsoft's priorities are somewhere other than
their
users and that is inexcusable. The fact that Roger Abell is trying to
defend the obvious ineptness of Microsoft is well, hilarious.

I'm getting tired of explaining this to you over and over. Microsoft's
~45 days to test and release patches has nothing to do with being cheap,
inept
or dishonest. It's just a fact of the Windows architecture that you have
to accept if you choose to use Windows.

Karl, I am getting tired of explaining my point but I will one more time.
So
here it goes: Why did DRM patch NOT GO THROUGH THE SAME 45 DAYS TO
TEST????
Total time to patch for the DRM holes was 3 days. Again, it seems
Microsoft
priorities here was to "protect" the Entertain Industry. Please address
this point should you decide to reply...

The simpleset work around being what? Use Firefox? Then we agree. Better
yet, the *best* work around is to ditch Microsoft all together and get
an
Apple or Linux PC....

Please, go ahead and do that, and then go away. I care nothing about how
many people switch to Mac or Linux, as long as they don't pester the rest
of us by running at the mouth about it.

Again, you are trying craftfully to NOT ANSWER the question. Sorry but, I
will not let you off the hook:

Again:

You claim it takes 45 days to test a patch in Windows. Again, why did
Microsoft break patching records to produce the DRM patch (3 days). This
is
the contention point here.

A secondary contention point would be why 45 days (unless you are the
Entertainment Industry!). If Microsoft needs more
programmers/Managers/Code
Debuggers hire them. Afterall they have what 60 billion in the bank? Why
can everyone else get a patch out sooner (Apple, Red Hat, Novell, Open
Source) as well as have an overall better track record of patch successes?

Now either answer those questions *or* go away yourself...


Enough of this Im.
It IS off-topic.

Besides, contrary to your claim Karl DID answer you.

In my initial post I also indicated this fact of life to you.

But, here goes again, one last time.

An impacted piece of code has a dependency tree, and test coverage
must be directed by that.

When a piece of code has few uses, and especially when those uses
are not complex relative to internationalization, regression testing is
a much smaller task.

When a code is a general library, the dependency tree itself can be
difficult to determine, and coverage testing larger and hence longer.

You have a comp sci background so I would assume you can see
those facts quite clearly (should you decide to).

But, this part I feel you have no real clue about, especially if the code
can impact visual renderings, then the internationalization becomes a
very real part of testing. Once a code change might start changing the
sizes of things it can start changing them differently in the 45 or so
supported locales, and there are a lot of interfaces that need to have
designed sufficiently for the possible size changes.

Please, take the conspiracy theorist motivated part of this discussion
to alt dot something.

This thread should be about the present risks, workarounds, and
degrees of exposure in the wild - that is, keep to YOUR subject.

Regards,
Roger

From: "Roger Abell [MVP]"

snip

| Please, take the conspiracy theorist motivated part of this discussion
| to alt dot something.
|
| This thread should be about the present risks, workarounds, and
| degrees of exposure in the wild - that is, keep to YOUR subject.
|
| Regards,
| Roger
|

I totally agree.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm

"imhotep" wrote in message
news
Michael Bednarek wrote:

On Fri, 22 Sep 2006 22:37:55 -0400, imhotep wrote in
microsoft.public.security:

Microsoft Zero Day security holes being exploited

"Microsoft has issued warnings about a serious flaw in Internet Explorer
that allows attackers to hijack a PC via the popular browser
[snip]

Workaround:
regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
I've done that and tested successfully (see below).

A non-Microsoft fix: http://isotf.org/zert/download.htm.

To test, see (at your own risk) http://www.isotf.org/zert/testvml.htm.


Nice job...


Actually, it is not that good to the world however.

regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
which is the first workaround mentioned in the MS advisory,
may fail in some locales.

As Jesper (and others) have indicated,
it should use %CommonProgramFiles%
http://msinfluentials.com/blogs/jesp...-a-domain.aspx
http://tinyurl.com/mtcbd
quote
Update Sept. 21, 2006
Uploaded a new version of the archive that uses %CommonProgramFiles%
instead of %ProgramFiles%\Common Files to specify the file location.
This helps make it work on non-English systems that have translated the
name of the Common Files directory.
/quote

Those interested should see his Friday's blog that not only discusses the
third-party patch route, but also outlines another approach to the current
(and the Direct Animation control's path) vulnerabiltiy
http://msinfluentials.com/blogs/jesp...-a-domain.aspx
http://tinyurl.com/h3buq

Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Ian wrote:


Think we'll only achieve secure computing when C is dropped in favour of
a
better language. The list of buffer-overflow exploits in every single
major software-package gets monotonous.


As a C programmer (one of many languages I know) that is one of the most
foolish statements I have heard all year. Buffer-overflows are not caused
by the programming language. They are caused by bad
programmers!!!!!!!!!!!!

The problem here is that some people want a language to cover up their
lack
of programming skills!!!!!!! Utter foolishness!!!



After all, nobody ever got prosecuted for 'Not realising that guy was
going to do something silly.' But people do get prosecuted for driving
cars with no brakes.


If you do not possess the skills to drive a car, why are you attempting
to drive it??? Driving a car requires a skill set, if you do not possess
it, don't drive...in either case don't blame the car for your ineptness.


If you are a skilled car driver why would you choose to use only an
inferior, cheaply made, sardine tin of an auto that could not meet the
safety standards of many governments of the day ?

Why did safe sting classes come about?

Would you choose to go back to GO TO based programming?

Use of a language that enforces safe code is a good thing.

Remember Dijstra? The set of 4 constructs proved sufficient for
any general purpose language? Remember the arguably academic
language Pascal (Wirth?) designed to show this? Remember how
that ushered in a new era in programming and vastly simplified
software lifecycles?

Are you saying that languages designed to not allow major problems
plaguing the sofeware industry are worth naught ?

You surely do sound to be doing so.


Let's review some things. Ian replied by blaming the C language for security
vulnerabilities. To which I replied BS!!!!!!

A language does what the programmer tells it to do. If you tell the program
to do something stupid, it will. If you do not posses good programming
style or technique neither will your program. And if there is a security
vulnerability in the software it is the programmers fault. Inept
programmers will always try to blame someone or something else. After all
it is much easier to blame someone else, or something else, than to admit
you are crappy programmer....

Now you can try and spin anything you wish. However, it seems to me that
debating something so obvious as this only servers to make you look
foolish. But by all means go ahead....

Imhotep

Roger Abell [MVP] wrote:

"imhotep" wrote in message
news
Michael Bednarek wrote:

On Fri, 22 Sep 2006 22:37:55 -0400, imhotep wrote in
microsoft.public.security:

Microsoft Zero Day security holes being exploited

"Microsoft has issued warnings about a serious flaw in Internet Explorer
that allows attackers to hijack a PC via the popular browser
[snip]

Workaround:
regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
I've done that and tested successfully (see below).

A non-Microsoft fix: http://isotf.org/zert/download.htm.

To test, see (at your own risk) http://www.isotf.org/zert/testvml.htm.


Nice job...


Actually, it is not that good to the world however.

regsvr32 -u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"
which is the first workaround mentioned in the MS advisory,
may fail in some locales.

As Jesper (and others) have indicated,
it should use %CommonProgramFiles%

http://msinfluentials.com/blogs/jesp...-a-domain.aspx
http://tinyurl.com/mtcbd
quote
Update Sept. 21, 2006
Uploaded a new version of the archive that uses %CommonProgramFiles%
instead of %ProgramFiles%\Common Files to specify the file location.
This helps make it work on non-English systems that have translated the
name of the Common Files directory.
/quote

Those interested should see his Friday's blog that not only discusses the
third-party patch route, but also outlines another approach to the current
(and the Direct Animation control's path) vulnerabiltiy

http://msinfluentials.com/blogs/jesp...-a-domain.aspx
http://tinyurl.com/h3buq


I will pass this along to the helpdesk guys. Thanks.

Any ETA about the patch/fix from Microsoft?

Imhotep

Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Karl Levinson, mvp wrote:


"imhotep" wrote in message
...

To think that the World's richest software company can't fix a serious
patch in a reasonable amount of time is inexcusable (not doubt Roger
will
try though). To think that a third party can release a patch in 2 days
but the World's richest software company can't is inexcusable. To think
that Microsoft can patch a DRM security hole in a record 2-3 days leads
one to believe that Microsoft's priorities are somewhere other than
their
users and that is inexcusable. The fact that Roger Abell is trying to
defend the obvious ineptness of Microsoft is well, hilarious.

I'm getting tired of explaining this to you over and over. Microsoft's
~45 days to test and release patches has nothing to do with being cheap,
inept
or dishonest. It's just a fact of the Windows architecture that you
have to accept if you choose to use Windows.

Karl, I am getting tired of explaining my point but I will one more time.
So
here it goes: Why did DRM patch NOT GO THROUGH THE SAME 45 DAYS TO
TEST????
Total time to patch for the DRM holes was 3 days. Again, it seems
Microsoft
priorities here was to "protect" the Entertain Industry. Please address
this point should you decide to reply...

The simpleset work around being what? Use Firefox? Then we agree.
Better yet, the *best* work around is to ditch Microsoft all together
and get an
Apple or Linux PC....

Please, go ahead and do that, and then go away. I care nothing about
how many people switch to Mac or Linux, as long as they don't pester the
rest of us by running at the mouth about it.

Again, you are trying craftfully to NOT ANSWER the question. Sorry but, I
will not let you off the hook:

Again:

You claim it takes 45 days to test a patch in Windows. Again, why did
Microsoft break patching records to produce the DRM patch (3 days). This
is
the contention point here.

A secondary contention point would be why 45 days (unless you are the
Entertainment Industry!). If Microsoft needs more
programmers/Managers/Code
Debuggers hire them. Afterall they have what 60 billion in the bank? Why
can everyone else get a patch out sooner (Apple, Red Hat, Novell, Open
Source) as well as have an overall better track record of patch
successes?

Now either answer those questions *or* go away yourself...


Enough of this Im.
It IS off-topic.

Besides, contrary to your claim Karl DID answer you.

In my initial post I also indicated this fact of life to you.

But, here goes again, one last time.

An impacted piece of code has a dependency tree, and test coverage
must be directed by that.

When a piece of code has few uses, and especially when those uses
are not complex relative to internationalization, regression testing is
a much smaller task.

When a code is a general library, the dependency tree itself can be
difficult to determine, and coverage testing larger and hence longer.

You have a comp sci background so I would assume you can see
those facts quite clearly (should you decide to).

But, this part I feel you have no real clue about, especially if the code
can impact visual renderings, then the internationalization becomes a
very real part of testing. Once a code change might start changing the
sizes of things it can start changing them differently in the 45 or so
supported locales, and there are a lot of interfaces that need to have
designed sufficiently for the possible size changes.

Please, take the conspiracy theorist motivated part of this discussion
to alt dot something.

This thread should be about the present risks, workarounds, and
degrees of exposure in the wild - that is, keep to YOUR subject.

Regards,
Roger


The Simple question that has NOT been answered:

Now, you claimed to have answered the question but you did not. You
identified, and correctly so, the steps it takes to make a patch and test
the patch. The DRM patch had to go through the same tests. It was done in 3
days. Why can't this one. How about a week?

Now, you might use the excuse of complexity. OK, I will give you a little
room there. However, this patch is most critically needed and releasing it
some 45 days later does not seem proportional when compared to the DRM
patch...

There are no conspiracy theories here. However, it is becoming clear, that
Microsoft takes DRM more seriously than it's users security.

-- Imhotep

Leythos wrote:

In article ,
says...
[snipped most, as I agree with Roger]
Please, take the conspiracy theorist motivated part of this discussion
to alt dot something.

This thread should be about the present risks, workarounds, and
degrees of exposure in the wild - that is, keep to YOUR subject.

I don't think I've seen this stated better (all that you said, not just
want I kept) in thousands of posts I've read this weekend.


Sure. However, you can not deny that it would be nice to have a patch out in
days instead of months....we know they can do it, they have in the past...

Imhotep

David H. Lipman wrote:

From: "Roger Abell [MVP]"

snip

| Please, take the conspiracy theorist motivated part of this discussion
| to alt dot something.
|
| This thread should be about the present risks, workarounds, and
| degrees of exposure in the wild - that is, keep to YOUR subject.
|
| Regards,
| Roger
|

I totally agree.


Sure. And sorry about that. It's just that this sort of thing is all to
common in the Microsoft Word and even getting worse....when is it going to
stop? The Worlds richest software company can't get more resources to put
patches out in a timely manner? That is just down right sad.

Again, if this happened once-and-a-while, so be it. But it has become all to
common....

Imhotep

Leythos wrote:

In article ,
says...
Leythos wrote:

In article ,
says...
[snipped most, as I agree with Roger]
Please, take the conspiracy theorist motivated part of this
discussion to alt dot something.

This thread should be about the present risks, workarounds, and
degrees of exposure in the wild - that is, keep to YOUR subject.

I don't think I've seen this stated better (all that you said, not just
want I kept) in thousands of posts I've read this weekend.


Sure. However, you can not deny that it would be nice to have a patch out
in days instead of months....we know they can do it, they have in the
past...

I think you misunderstand regression testing and proper QA methods. If I
want to patch a program that does not interact with any other programs,
then I only need to test the program. If I want to patch a interface,
something that interacts with many programs and services, it means that
I have to regression test all interconnected parts.

MS has no reason to lag in pushing out patches or fixes, they do it as
quickly as possible with the least risk they can manage to end-users.


Not at all. I understand regression testing quite well. You know as well as
I QA testing does not need to be done in a serial fashion. Indeed, most QA
testing can be, and usually is, done in parallel...and often is automated.

The problem I have is the time to patch. Just when you think Microsoft is
getting their crap together by releasing a patch for the DRM security hole
in three days (same testing and QA processes apply) they drop the ball
again by pretty much saying that it will be 45 days for this Outlook/IE
security vulnerability....

The idea that Microsoft is allowing it's users to be unsafe for so long is
inexcusable. Why is it that everyone else can release timely patches but
Microsoft can't. Damn, even open source has a much better time to patch
than Microsoft. The average time to patch for Linux is a couple of days.
And it is free...

So why can;t Microsoft get their sh$t together??? It is not a lack of
money...

PS. can you not control your newreader and its use of followups?

Why can't you prune the conversation to what is relevant?
Too difficult for you?
Must you quote everything?

Stephen Howe

"Ian" wrote in message
...

Think we'll only achieve secure computing when C is dropped in favour of a
better language. The list of buffer-overflow exploits in every single
major
software-package gets monotonous.

Your right in one sense. What I don't understand is with MS's trustworthy
programming initiative, why havent they visited all Windows APIs and proofed
them by now? MS 's approach seems reactionary not pro-active.

And note, I don't regard C as inheritently unsafe - it is just it requires
programmer discipline.

Stephen Howe

"imhotep" wrote in message
...

The Simple question that has NOT been answered:

Now, you claimed to have answered the question but you did not.

Sorry. I guess I cannot cure your blind spots.

ra