Microsoft Zero Day security holes being exploited

Dan wrote:

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.

Honestly it is not that people, like me, view Microsoft as evil in the real
sense of the word. This is not the case.

Microsoft has drifted away from the golden rule. What do I mean with that
statement? Microsoft has used their marketshare as a stick to force people
into doing things Microsoft's way instead of making solutions that their
customer want. This is bad. Their is no reason that Microsoft could not
completely integrate with Apple, Linux or BSDs.

Anytime a company starts to play games with it's users instead of listening
to it's users is a cause for alarm.

As an example, I recently bought a new car. My car as a really nice
navigation system that can interface with my GSM phone. Now, what if my
car's manufacturer tried to force me into buying only *their* phone? By
doing this, they can supply the cheapest phone they can find yet charge me
a fortune for it. Even worse, suppose their phone needs and expensive
upgrade every year! This is the sort of thing that Microsoft does everyday.
That is why people like me (I am an X-Windows user going back to DOS 2.1)
have become dis-enchanted with them and their games. I want to design
systems that benefit my company NOT Microsoft's wallet (or any other
companies wallet). I want options as to what systems comprise my companies
infrastructure. I do not want artificial limitations. I want options!

Microsoft intentionally tries to take away options because they truly do
fear competition. Which is a shame.

Again, you do not have to agree with me, but at least try to understand my
point.

Imhotep

Roger Abell [MVP] wrote:

"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.

Man, you are the absolute best at *not* answering something that debunks
your arguments. To bad, you can't disiguse it more....

Im

ra

Dan wrote:

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.

I beg to differ. For the amount of money and resources Microsoft has, they
clearly could do much better. Why is it patching is only risky on Windows?
Why is it other platforms (some totally free) never have patching problems?
Why is it that the time from security hole discovery to patch is a couple
of days for Linux (which is free) and Microsoft is 30+ days? When Microsoft
clearly has billions of dollars in the bank and rich resources????

Still think that do a "darn good job"?

Imhotep

cquirke (MVP Windows shell/user) wrote:

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.

Totally disagree. In fact I could not disagree more.

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.

How? Please specify? Buffer overflows? All low level languages can be
improperly programmed by bad programming technique, not just C.


The real problem here is not the language. The real problem is that many
software companies push release dates over quality.

When I first graduated from college it was quality first marketing second.
Sadly, this has inverted. It is now, marketing first quality second.

The second problem is that when I first started out, the senior programmers
were well respected and considered a prized resource within the
organization. Also sadly, a lot of companies have outsourced these people
to third parties who's people have no direct pride or ties to the
organization.

Is there any question why quality has gone away?


Lastly, C/C++ are low level languages and as such have little restrictions
for the programmers that use it. This is how it should be with low level
languages since they are often the languages that kernels and other complex
programs are written in.

Middle layer and High layer languages take away some of "dangerous things"
within the language BUT AT A COST. These languages add restrictions at the
cost of flexibility. They are designed to address the most common
programming needs, say 80%. However, should you need to program in the 20%
area, they become clumsy if not impossible to use.

Removing the so called "dangerous things" from a programming language does
not make a better programmer if they did not understand the fundamentals in
the first place. All it does is make a poor programmer look better. If you
do not understand shared memory, semaphores, IPCs, pointers, memory
management, etc, etc you are not a programmer. You are a glorified
scripter. Not that there is anything wrong with being a scripter....If you
do not understand a simple statement like "***ptr = &object" you should not
be programming...

So, the comment about removing low layer languages will make security better
is just plain bogus. Buffer overflows are poor programming!!! If you want
to make more secure and better quality programs, make quality a priority
again instead of marketing!!!


Imhotep

"Stephen Howe" sjhoweATdialDOTpipexDOTcom wrote:


"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


....and good technique. Well, I guess there is one thing we agree on...go
figure.

Imhotep

cquirke (MVP Windows shell/user) wrote:

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...

Seems his is more of a Microsoft problem than anyone else. Maybe it is not
languages fault after all!

....and the problem with high level languages is that they put to many
restrictions on you. Higher layer languages were not designed, nor any
language, to hide the programmers ineptness!

Languages, and the program that results, will ONLY be as good as the
programmer is...

Imhotep




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

I always thought "NT" stood for "Not Tested"...



Dan wrote:

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.

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


Who said anything at al about popularity ?
Scale of potential implacts/disruptions in simply a feel obtained
from the dependancy tree size, etc all as previously outlined but
apparently not comprehended by yourself.


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...


That then explains some of your blind spots


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

On Tue, 26 Sep 2006 07:46:22 -0400, "karl levinson, mvp"

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?

Sure, but the wrong entities come to own systems all the time.
Defense in depth means planning for how you get your system back; you
don't just faint in shock and horror that you're owned, and destroy
the whole system as the only way to kill the invader.

It's tougher for pro-IT, because they've long been tempted into
breaking the rule about never letting anything trump the user at the
keyboard. By now, they need remote access and admin, as well as
automation that can be slid past the user who is not supposed to have
the power to block it, in terms of the business structure.

But the rest of us don't have to be crippled by pro-IT's addiction to
central and remote administration, any more than a peacetime urban
motorist needs an 88mm cannon in a roof-top turret. We need to be
empowered to physically get into our systems, and identify and rip out
every automated or remotely-intruded PoS that's got into the system.

It's absolutely pathetic to have to tell posters "well, maybe you have
'difficult' (i.e., compitently-written) malware; there's nothing you
can do, 'just' wipe and re-install" because our toolkit is bare.



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

Roger Abell [MVP] wrote:


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


Who said anything at al about popularity ?
Scale of potential implacts/disruptions in simply a feel obtained
from the dependancy tree size, etc all as previously outlined but
apparently not comprehended by yourself.

Because your comments make no sense....


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...


That then explains some of your blind spots

Well, one of us is....


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

Leythos wrote:

In article ,
says...
Why is it other platforms (some totally free) never have patching
problems?

You are completely delusional of you think that ANY OS never has patch
problems.


I have over 12 years running misc Unix OSes (Sun/Solaris, Linux and
FreeBSD). In this time, I have NEVER been burned. Not once. Installing a
patch just works...

You do the math, kid.

Imhotep

Leythos wrote:

In article ,
says...
Leythos wrote:

In article ,
says...
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...

Your thinking is flawed - most OS vendors don't release patches
quickly. Most of them come out with a workaround until they can get
their patches out after testing. Follow the HP-UX group and see how
long they take, follow the MAC groups and see how long they take....


You are flawed. Reasearch linux patch times...from time of discovery to
patch release.

Check it again, if you actually look, not all patches are quick and not
all patches are without problems.



All I can say is this. I have been using UNIX (Sun/Solaris, Linux and
FreeBSD) for over 12 years. I HAVE NEVER BEEN BURNED BY INSTALLING A PATCH.
Not once. So you can read whatever third hand information you wish, but I
have 12 years of first hand information.

Again, in 12 years I have not been burned (with UNIX). Not once....the
patches just work. There is no excuse for Microsoft's screw up with
patches. If other people can do it, why can't Microsoft???

Im

cquirke (MVP Windows shell/user) wrote:
On Tue, 26 Sep 2006 07:46:22 -0400, "karl levinson, mvp"

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?

Sure, but the wrong entities come to own systems all the time.
Defense in depth means planning for how you get your system back; you
don't just faint in shock and horror that you're owned, and destroy
the whole system as the only way to kill the invader.

It's tougher for pro-IT, because they've long been tempted into
breaking the rule about never letting anything trump the user at the
keyboard. By now, they need remote access and admin, as well as
automation that can be slid past the user who is not supposed to have
the power to block it, in terms of the business structure.

But the rest of us don't have to be crippled by pro-IT's addiction to
central and remote administration, any more than a peacetime urban
motorist needs an 88mm cannon in a roof-top turret. We need to be
empowered to physically get into our systems, and identify and rip out
every automated or remotely-intruded PoS that's got into the system.

It's absolutely pathetic to have to tell posters "well, maybe you have
'difficult' (i.e., compitently-written) malware; there's nothing you
can do, 'just' wipe and re-install" because our toolkit is bare.



-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

Exactly, Chris! The school computers (XP Pro. ones -- the school also
has 98SE computers) where I work were all configured by someone who did
not know what they were doing. They are have the remote assistance
boxes checked and that is like saying to everyone "come on in to this
machine and welcome to the party" This setting is just asking for
trouble and yet the person or people who originally set up these
machines configured them in this manner.

On Thu, 28 Sep 2006 21:24:32 -0600, Dan wrote:
cquirke (MVP Windows shell/user) wrote:

Defense in depth means planning for how you get your system back; you
don't just faint in shock and horror that you're owned, and destroy
the whole system as the only way to kill the invader.

It's absolutely pathetic to have to tell posters "well, maybe you have
'difficult' (i.e., compitently-written) malware; there's nothing you
can do, 'just' wipe and re-install" because our toolkit is bare.

The school computers (XP Pro. ones -- the school also has 98SE
computers) where I work were all configured by someone who did
not know what they were doing. They are have the remote assistance
boxes checked and that is like saying to everyone "come on in to this
machine and welcome to the party" This setting is just asking for
trouble and yet the person or people who originally set up these
machines configured them in this manner.

All your setup dudes did wrong was to install the OS while leaving MS
duhfaults in place. By duhfault, XP will:
- full-share everything on all HDs to networks (Pro, non-null pwds)
- perform no "strength tests" on account passwords (see above)
- disallow Recovery Console from accessing HDs other than C:
- disallow Recovery Console from copying files off C:
- wave numerous services e.g. RPC, LSASS at the Internet
- do so with no firewall protection (fixed in SP2)
- allow software to disable firewall
- automatically restart on all system errors, even during boot
- automatically restart on RPC service failures
- hide files, file name extensions and full directory paths
- always apply the above lethal defaults in Safe Mode
- facilitate multiple integration points into Safe Mode
- allow dangerous file types (.EXE, etc.) to set their own icons
- allow hidden content to override visible file type cues
- dump incoming messenger attachments in your data set
- dump IE downloads in your data set
- autorun code on CDs, DVDs, USB storage and HD volumes
- allow Remote Desktop and Remote Assistance through firewall
- allow unsecured WiFi
- automatically join previously-accepted WiFi networks
- wastes huge space on per-user basis for IE cache
- duplicates most of the above on a per-account basis
- provides no way to override defaults in new account prototype

Every time one "just" reinstalls Windows (especially, but not always
only, if one formats and starts over), many or all of the above
settings will fall back to default again. Couple that with a loss of
patches, and you can see why folks who "just" format and re-install,
end up repeating this process on a regular basis.

Also, every time a new user account is created, all per-account
settings start off with MS defaults and you have to re-apply your
settings all over again. If you limit the account rights, as we are
urged to do, then often these settings lip back to MS defaults and
remain there - so I avoid multiple and limited user accounts
altogether, and prefer to impose my own safety settings.


-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
----------------------- ------ ---- --- -- - - - -

Great Job, Chris!

I will copy and paste your reply to assist me in hardening all XP Pro.
computers. Do you have similar advice for the hardening of all the 98
Second Edition computers as well --- they are connected to the Internet
as my machine is and also are connected to the school's domain.

BTW, what are the advantages and disadvantages of connecting my machine
to the school's domain and if the school's domain is down will my
machine be down from the Internet as well if I use their domain? Thanks
and what I really need besides your advice on domains is a good article
about domains that I can read when I get a chance since I know so little
about them.