A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » Security and Administration with Windows XP
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Microsoft Zero Day security holes being exploited



 
 
Thread Tools Display Modes
  #31  
Old September 25th 06, 03:52 PM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
Roger Abell [MVP]
external usenet poster
 
Posts: 71
Default Microsoft Zero Day security holes being exploited

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

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?


No, and I have not seen a reason to ask.

MS took the unusually step of detailing workarounds that
crippled functionality in their initial advirory. That was no
doubt in response to analysis showing code availability,
exploit character, and extent of testing that would be needed
(i.e. time to delivery). From that I fully trust resources were
marshalled in appropriate scale.

Typically the owning group of the involved code finishes its
work, which includes review for similar/related flaws, quite
quickly. For something like this, that could have impacts on
non-MS code, the test cycle is where the time gets consumed
(read: not all testing is in-house).

(You trapped me with that dumb follow-up once more !!)


Ads
  #32  
Old September 25th 06, 10:48 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
Smitty
external usenet poster
 
Posts: 8
Default Microsoft Zero Day security holes being exploited

I have to agree with Imhotep.

I have been thoroughly p****ed off this week as a result of a virus which
somehow evaded the countless security systems I have in place. In
retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing
WinLogon to to load arbitrary DLLs into its address space simply by adding
entries into the registry.

WinLogon is supposed to be my first line of defense against security issues.

What are they thinking ?

About money, obviously !
  #33  
Old September 25th 06, 11:33 PM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
imhotep
external usenet poster
 
Posts: 155
Default Microsoft Zero Day security holes being exploited

Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

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?


No, and I have not seen a reason to ask.



Surely the critically merits promptness. Does it not?


MS took the unusually step of detailing workarounds that
crippled functionality in their initial advirory. That was no
doubt in response to analysis showing code availability,
exploit character, and extent of testing that would be needed
(i.e. time to delivery). From that I fully trust resources were
marshalled in appropriate scale.


Typically the owning group of the involved code finishes its
work, which includes review for similar/related flaws, quite
quickly. For something like this, that could have impacts on
non-MS code, the test cycle is where the time gets consumed
(read: not all testing is in-house).


(You trapped me with that dumb follow-up once more !!)


Asking if you knew of a ETA? Sorry, but I thought you actually might know.
No trapping this time....


  #34  
Old September 26th 06, 12:08 AM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
imhotep
external usenet poster
 
Posts: 155
Default Microsoft Zero Day security holes being exploited

Karl Levinson, mvp wrote:


"imhotep" wrote in message
...

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.


That's a really stupid argument and shows a total lack of understanding of
computer security. Security is risk management. First you assess risks,
and then either you accept a risk, or you mitigate a risk. I assessed the
risk, and backed up my assessment by noting the two next largest IE vulns
to
hit the media. Asking me to put out a monetary guarantee before you'll
accept the validity of my argument, with past examples, is just dumb.




No. What is dumb is making a guarantee that you *can't* back up. It is both
dumb and irresponsible...

And if you *really* knew computer security you would understand that risk
management is highly dependant on one's computer systems and the business
that runs on them. What you might call acceptable risk might not be for
someone else....now, not realizing that *is* dumb....



Suffice it to say that past IE vulns have always been widely overrated.


BS Propaganda! I guess their are no problems with spyware on Microsoft
platforms either? Hahahahaha

You're constantly coming here and saying that the sky is about to fall in,
and it never does. You're backing up your baseless panic with "what if"
and
"it could happen" statements. Security and risk assessment just don't
work that way, and for good reason.


On the contrary. I am saying that Microsoft has failed and is failing at
securing their systems (unless it is DRM related). Furthermore, Microsoft's
overall security seems to be getting worse.

I bet the organization where you work has accepted the risk of this
vulnerability, and is doing little to nothing, at least on the client
side,
to lessen the risk. That's a very common real world posture to these IE
vulns.


First, luckily we have not had a Microsoft server in years. The only
remaining Microsoft PCs are a couple of people who have not been converted
to Apple yet. The desktop guys went around and issued the temp fix, that
was listed on their site.

My company deals with large sums of money and security is paramount.

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


I already did.



No you did not. You, or some else here, tried to use the excuse of patch
management (QA proceedsure and steps). True QA is an important step.
However, the DRM patch *ALSO* went through the same procedures and was out
in 3 days. Please explain that...(this has been the unanswered question)


Without propaganda? That's what I should be demanding of you. A good
example of propaganda is when you said that Microsoft bases its patching
policy on laziness, greed and/or incompetence.



Nice try. Please answer my question above.


Imhotep
  #35  
Old September 26th 06, 04:04 AM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
Dan
external usenet poster
 
Posts: 157
Default Microsoft Zero Day security holes being exploited

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.


Nice point and even then you get users with tons of posts to the
Microsoft update newsgroup about why the download did not work properly
and folks who suddenly say they hate Microsoft because they can't get
the patch to work right. Sure, Microsoft is not perfect but I feel they
do a darn good job supporting their user base.
  #36  
Old September 26th 06, 04:07 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
Dan
external usenet poster
 
Posts: 157
Default Microsoft Zero Day security holes being exploited

Smitty wrote:
I have to agree with Imhotep.

I have been thoroughly p****ed off this week as a result of a virus which
somehow evaded the countless security systems I have in place. In
retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing
WinLogon to to load arbitrary DLLs into its address space simply by adding
entries into the registry.

WinLogon is supposed to be my first line of defense against security issues.

What are they thinking ?

About money, obviously !


Possibly, but Microsoft is not the big evil cooperation that users
associate it to be. Microsoft does have some problems that are common
in a big company but they do try. For example, they had the security cd
for free that has been very help in countless 98SE machines that I service.
  #37  
Old September 26th 06, 05:40 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
Dan
external usenet poster
 
Posts: 157
Default Microsoft Zero Day security holes being exploited

snip

It is interesting that the NT (New Technology) source code was
originally nicknamed the "Not There" source code since it did not have a
true maintenance operating system like the 9x had. Chris Quirke, MVP
can post more information on this because he knows about it extensively.
9x had DOS which was really nice because you could get down and dirty
and solve many problems with commands and it overcame the limitations of
fixing things that are inherent in GUI (Graphical User Interface). I
researched and read about this in a book about Microsoft's early
history. The actual base of 9x has a more secure and solid foundation
than NT.

Check this out for further information:

http://secunia.com/product/22/?task=advisories (XP Pro. -- critical extreme vulnerability)


http://secunia.com/product/16/?task=advisories (XP Home -- critical extreme vulnerability)


http://secunia.com/product/1/?task=advisories (2000 Professional -- critical extreme vulnerability)


http://secunia.com/product/13/?task=advisories (98 Second Edition -- only 3 less critical vulnerabilities)


Well, you people get the idea and all the garbage about XP being so
secure is just plain foolishness if people would just remove the
blinders from their eyes and see the truth then we would be getting
somewhere. BTW, I tri-boot with 98SE, XP Pro. and am testing Windows
Vista Ultimate 32 bit with glass "Aero" interface enabled.




  #38  
Old September 26th 06, 05:57 AM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
Roger Abell [MVP]
external usenet poster
 
Posts: 71
Default Microsoft Zero Day security holes being exploited

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

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?


No, and I have not seen a reason to ask.



Surely the critically merits promptness. Does it not?


Contrarily, surely it is the scope of disruption to installed base,
or potential thereof, that merits thoroughness and correctness.
Does it not?

See. Yet another game of trade-offs.


MS took the unusually step of detailing workarounds that
crippled functionality in their initial advirory. That was no
doubt in response to analysis showing code availability,
exploit character, and extent of testing that would be needed
(i.e. time to delivery). From that I fully trust resources were
marshalled in appropriate scale.


Typically the owning group of the involved code finishes its
work, which includes review for similar/related flaws, quite
quickly. For something like this, that could have impacts on
non-MS code, the test cycle is where the time gets consumed
(read: not all testing is in-house).


(You trapped me with that dumb follow-up once more !!)


Asking if you knew of a ETA? Sorry, but I thought you actually might know.


If I knew I could not say, something true for all that might.

No trapping this time....


I would call you a liar, were it not so obvious you did not understand
"follow-up" did mean follow-up, as set on your post, which is again to
only the ie.sec NG


  #39  
Old September 26th 06, 08:25 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
cquirke (MVP Windows shell/user)
external usenet poster
 
Posts: 274
Default Microsoft Zero Day security holes being exploited

On Sun, 24 Sep 2006 02:45:01 -0700, Ian

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.


Yes, that makes a lot of sense.

As C tends to be used across all platforms (UNIX, Linux, MacOS,
Microsoft) it's unsurprising that all of these platforms share the
same sort of exploits and code repairs.

It's a lot like the Y2k problem, i.e. trade-offs made in the interests
of performance on the slower hardware of the time.

We now waste processing power on eye candy (animated menus, Glass in
Vista, etc.) and underfootware (indexing, thumbnailers, .PF and SR
management). Plus, the risks from bad code often mean thatr the real
code is preceded by several layers of "is this safe?" content testing,
from av to code that checks for "shapes" that will exploit the real
code to full-blown emulation of the real code in an attempt to
"sandbox" it. One's tempted to say it would be more efficient to
simply use a less "powerful" language that doesn't use pointers and
data-driven buffer operations instead.

The challenge is that much of the code logic only works because the
need to know how big material is, relative to the buffer space, isn't
needed to code it. That's unsafe, but to fix this is more than just a
matter of changing the source code language. Wherever there's a
dynamic buffer that's having ad-hoc material added to it, it may be
difficult to track remaining buffer size and incoming data size.

One way is to truncate data to fit, but that can create a different
sort of exploitability, where this can match the wrong (malicious)
object when truncated.


Pointers are another story... it's hard to re-write code that relies
on pointers to work in some other way. Object Orientated Programming
may mix code and data within multiple small objects, thus creating
opportunities for code to overwrite (or point into) data areas that
would have been avoided if the older code segment, data segment model
was used instead.


Finally, what really blows the doors off safety is the irresistable
urge to "make everything work". It's so cheap in terms of programming
effort to massively extend functionality by passing logic outwards
into additional content and syntax parsers, such as programming
languages that include some sort of SystemAPI( ) calls - but this is
where the original intention of the code is trumped by unintended
possibilities that can be exploited.

This is very similar to the Internet, where any IP that can't be found
locally is sought through the next in a chain of gateways. We love
the Internet, though we wish coders wouldn't treat it as one big
network just because it's made out of networking. We have less love
for sprawling extended interpreters that allow any content to be
activated from any kind of visible wrapper.



------------ ----- --- -- - - - -

Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -

  #40  
Old September 26th 06, 08:53 AM posted to microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
cquirke (MVP Windows shell/user)
external usenet poster
 
Posts: 274
Default Microsoft Zero Day security holes being exploited

On Sun, 24 Sep 2006 16:06:41 -0400, imhotep
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.


cough

See http://cquirke.mvps.org/9x/mimehole.htm, Google( BadTrans B )

That's a very old bug, long fixed unless you "just" re-installed any
OS predating XP, as every such OS uses an IE that is both exploitable
and too "old" to be patched other than by upgrading the whole of IE.

If you read up that bug, you'd see how the nature of exploits and code
bugs have changed.

The MIME hole was a design safety failure, not a code defect - IOW, it
"worked as designed" but the design was brain-dead.

There's still design failures in Windows, and until these are proven
to be exploitable, they won't be patched because "it's working the way
we expected it to". Most exploits that are being patched today are
genuine code defects, and may be harder to exploit.

Then again, the modern malware industry is optimised to overcome any
"an attacker would have to..." mitigations. Once an exploit shape is
found, the source code becomes rapidly available, and malware coders
then drop it straight into attack vehicles that are ready to roll;
either full-fledged multi-function bots, or simple stubs that can pull
down the "real" malware. If these malware haven't been released
before, av won't "know" them at the signature level.


Malware can always out-turn patching. The attacks are smaller than
the patches and can drown out the patching process by sheer volume,
even before you consider DDoSing the fewer number of patching sources
or poisoning the patch pool via fake patching sources.

The other reason malware will always win the race is that the required
software standards are far lower. A malware has to work on some PCs,
and it doesn't matter if it trashes others. But a patch has to work
on all systerms, and not cause new problems of any of them.

If you insist on butting heads with malware on a level playing field,
you will always lose. Better to tilt the playing field so that the
user at the keyboard has the ability to trump all code and remote
access - but MS's fixation on centrally-managed IT and DRM undermines
this and rots the top of the Trust Stack.

See http://cquirke.blogspot.com/2006/08/trust-stack.html

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


Well, it could be that the nature of the hole was trivial to fix -
e.g. simply changing some static "secret" info that became harvested
and used by the attackers. I suspect this is the case, given how
quickly the fix has been circumvented by the attackers.

We have a very small sample from which to draw conclusions. Sure, we
have a lot of defects that allow user interests to be attacked, and we
have a smaller number where users were left hanging out to try while
patching caught up with ITW exploits. But we have a sample of 1
prompt DRM fix, and it may just happen to have been an easy one to
fix; maybe the next one (or even the continuation of this one) will
take a far longer time to fix. If so, don't expect to read about it!

So... are you saying that all fixes should be held back the same
amount of time, even if they are ready earlier, so that MS can be seen
to act more promptly on the issues we'd most like to see fixed first?


BTW, the post I'm replying to has a ?bug of its own; the sole
newsgroup set for replies is not found to exist on my news server.
Maybe it exists on other news servers, who knows? Here, it's 100%
broken and buggy. Should I wave this around as "proof" that the
poster I'm replying to is trying to hide refutations to his post?



------------ ----- --- -- - - - -

Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -

  #41  
Old September 26th 06, 12:46 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
karl levinson, mvp
external usenet poster
 
Posts: 73
Default Microsoft Zero Day security holes being exploited


"Smitty" wrote in message
...
I have to agree with Imhotep.

I have been thoroughly p****ed off this week as a result of a virus which
somehow evaded the countless security systems I have in place. In
retrospect, the 'vulnerability' is simply MS stupidity. Imagine allowing
WinLogon to to load arbitrary DLLs into its address space simply by adding
entries into the registry.

WinLogon is supposed to be my first line of defense against security
issues.


All operating systems do that. They are designed to launch code at boot
time by reading registry values, text files, etc. Because those registry
values are protected from unauthorized access by permissions, someone would
have to already own your system to modify those values, wouldn't they?


  #42  
Old September 26th 06, 08:20 PM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
Roger Abell [MVP]
external usenet poster
 
Posts: 71
Default Microsoft Zero Day security holes being exploited

Check your update processes (MU, WSUS sync.)
but note that your channels may still be staging out.

http://www.microsoft.com/technet/sec.../MS06-055.mspx

--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4

"imhotep" wrote in message
...
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

Researcher Adam Thomas uncovered the exploit which revolves around the way
that the Internet Explorer browser handles a particular form of graphics
known as vector graphics.

A properly crafted webpage can exploit this problem and install almost
anything they want on the target machine.
Unusable PC

Tests by Sunbelt Software on a Windows machine patched with all the latest
security updates showed attackers installing a huge amount of spyware and
other malicious programs."

http://news.bbc.co.uk/2/hi/technology/5365296.stm

Imhotep



  #43  
Old September 27th 06, 08:22 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin,microsoft.public.security.homeusers,microsoft.public.internetexplorer.security
cquirke (MVP Windows shell/user)
external usenet poster
 
Posts: 274
Default Microsoft Zero Day security holes being exploited

On Mon, 25 Sep 2006 05:45:39 +0100, "Stephen Howe"
"Ian" wrote in message


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


Humans are just system components, along with everything else - and as
such, they have notoriously high error rates.

When designing languages, that should be taken into account.

With C, it wasn't - the mindset was that programmers are smart enough
not to need training wheels, and the beauty of C was that it stayed
out of your way so you had full control (and full responsibility).

And we can see how well human programmers have filled those shoes...



------------ ----- --- -- - - - -

Drugs are usually safe. Inject? (Y/n)
------------ ----- --- -- - - - -

  #44  
Old September 27th 06, 09:06 AM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
Roger Abell [MVP]
external usenet poster
 
Posts: 71
Default Microsoft Zero Day security holes being exploited

"Stephen Howe" sjhoweATdialDOTpipexDOTcom wrote in message
...
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



Point taken.

I also sometimes get lost in the "what is most relevant?"
when considering the fractured view today's search engines
yield with currently primative (ill thread xref'd) hits.

--
ra


  #45  
Old September 28th 06, 03:18 AM posted to microsoft.public.internetexplorer.security,microsoft.public.security,microsoft.public.security.homeusers,microsoft.public.windowsxp.security_admin
imhotep
external usenet poster
 
Posts: 155
Default Microsoft Zero Day security holes being exploited

Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

"imhotep" wrote in message
...
Roger Abell [MVP] wrote:

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?


No, and I have not seen a reason to ask.



Surely the critically merits promptness. Does it not?


Contrarily, surely it is the scope of disruption to installed base,
or potential thereof, that merits thoroughness and correctness.
Does it not?


An how does one predict what tomorrow brings? Crystal ball? Surely one can
not. This is why is much better rate to the security hole based on the
critically rather than popularity...CRITICALITY DOES NOT CHANGE POPULARITY
DOES!!!


See. Yet another game of trade-offs.


I do not see a trade off here. Honestly, I do see mistakes in how some
people try to evaluate security holes thus resulting in making things
worse...


MS took the unusually step of detailing workarounds that
crippled functionality in their initial advirory. That was no
doubt in response to analysis showing code availability,
exploit character, and extent of testing that would be needed
(i.e. time to delivery). From that I fully trust resources were
marshalled in appropriate scale.


Typically the owning group of the involved code finishes its
work, which includes review for similar/related flaws, quite
quickly. For something like this, that could have impacts on
non-MS code, the test cycle is where the time gets consumed
(read: not all testing is in-house).


(You trapped me with that dumb follow-up once more !!)


Asking if you knew of a ETA? Sorry, but I thought you actually might
know.


If I knew I could not say, something true for all that might.

No trapping this time....


I would call you a liar, were it not so obvious you did not understand
"follow-up" did mean follow-up, as set on your post, which is again to
only the ie.sec NG


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 07:38 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.