Windows Update breaks the system!
Jafar As-Sadiq Calley
received. If anyone else is experiencing problems, please let us know.
A number of people have reported weird problems with one of the MS patches
released yesterday, specifically MS05-051 Vulnerabilities in MSDTC and
COM+ Could Allow Remote Code Execution (902400).
Symptoms include, but are not limited to:
- Inability to visit Windows Update
- Inablility to use the Search tool off the Start Menu
- blank screen (no icons) upon login
- Symantec LiveUpdate stops working
- SpySweeper stops working
- problems with Office apps
- VirtualPC becomes extremely sluggish
Lee said he had spoken to a Microsoft engineer about this. From what he
could tell:
"this issue is only affecting people with very specific NTFS permissions.
If the C:WinntRegistration folder is locked down and cannot be written to
by COM+ you will have errors similar to those listed in your alert. All of
those tasks use COM+ in one way or another."
So, it appears that Microsoft is blaming others as usual. Their response
to this problem?
"This is not a "known issue" or "problem" with the patch, but a
"complexity with the increased security provided by the patch when running
on systems where settings have been incorrectly changed from the default
settings".'"
I see, so changing system settings to make the machine more secure is
"incorrect?"
Windows sucks plain and simple.
--
Jafar Calley
http://planetblog.homelinux.org
http://fatcat.homelinux.org - Pics from Mars and Saturn!
Erik Funkenbusch
> "this issue is only affecting people with very specific NTFS permissions.
> If the C:WinntRegistration folder is locked down and cannot be written to
> by COM+ you will have errors similar to those listed in your alert. All of
> those tasks use COM+ in one way or another."
>
> So, it appears that Microsoft is blaming others as usual. Their response
> to this problem?
>
> "This is not a "known issue" or "problem" with the patch, but a
> "complexity with the increased security provided by the patch when running
> on systems where settings have been incorrectly changed from the default
> settings".'"
>
> I see, so changing system settings to make the machine more secure is
> "incorrect?"
> Windows sucks plain and simple.
No, changing the system settings to something that is incorrect for the
system to function is "incorrect".
The problem here is that you did not give the COM+ subsystem rights to a
resource it needs. You don't have to make the folder world writable, just
give COM+ access. Because you changed this setting from it's default, you
are at fault.
This is like complaining that your system won't boot if you delete the
kernel. It's something YOU did. And you didn't do it correctly.
Bobbie Gill
>
> This is like complaining that your system won't boot if you delete the
> kernel. It's something YOU did. And you didn't do it correctly.
You mean there's a correct way to delete the kernel and still have the
system boot?
--
Bobbie the Triple Killer
My website:
http://members.shaw.ca/bobbie4/index.htm
Check out:
http://www.iuoe882.com/
[Bob@S01060050046f293e Desktop]$ emacs signature
Today's posting is brought to you by:
The numbers 0 & 1, Fedora Core 4 and Mozilla Thunderbird.
The ideal engineer is a composite ... He is not a scientist, he is not a
mathematician, he is not a sociologist or a writer; but he may use the
knowledge and techniques of any or all of these disciplines in solving
engineering problems.
N. W. Dougherty, 1955
Roy Schestowitz
I have some callers who are unable to work out their merging connection
issues. After a while it turns out that they recently updated Windows. It's
great, ain't it?
Roy
--
Roy S. Schestowitz | "Computers are useless. They only solve problems"
http://Schestowitz.com | SuSE Linux | PGP-Key: 74572E8E
8:35am up 51 days 20:49, 6 users, load average: 0.18, 0.45, 0.54
http://iuron.com - next generation of search paradigms
DFS
William Poaster
Schestowitz console, was as follows:
Obviously they're preparing people for what happens when Fista crawls out
of the woodwork.
--
slashdot users make Jerry
Springer's audience look
like the Vatican Council.
- Jeremy Malcolm http://jmalcolm.ilaw.com.au/ -
Mart van de Wege
> On Sun, 16 Oct 2005 07:51:00 +0200, Jafar As-Sadiq Calley wrote:
>
>> "this issue is only affecting people with very specific NTFS permissions.
>> If the C:WinntRegistration folder is locked down and cannot be written to
>> by COM+ you will have errors similar to those listed in your alert. All of
>> those tasks use COM+ in one way or another."
>>
>> So, it appears that Microsoft is blaming others as usual. Their response
>> to this problem?
>>
>> "This is not a "known issue" or "problem" with the patch, but a
>> "complexity with the increased security provided by the patch when running
>> on systems where settings have been incorrectly changed from the default
>> settings".'"
>>
>> I see, so changing system settings to make the machine more secure is
>> "incorrect?"
>> Windows sucks plain and simple.
>
> No, changing the system settings to something that is incorrect for the
> system to function is "incorrect".
>
> The problem here is that you did not give the COM+ subsystem rights to a
> resource it needs. You don't have to make the folder world writable, just
> give COM+ access. Because you changed this setting from it's default, you
> are at fault.
I'm a sysadmin, not a COM+ developer. *How* am I supposed to know what
permissions the COM+ system needs? Where is that documented? Where
actually *is* documented what subsystems need what folders and what
permissions thereon?
So it's either accept the (possibly unsafe) defaults, or start reading
developer-level documentation. I thought the main buy for Windows was
that it was cheaper to admin? This way, it costs either in time or in
admin education (better educated admin are *lots* more expensive than
mere MCSEs).
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
7
>> I see, so changing system settings to make the machine more secure is
>> "incorrect?"
>> Windows sucks plain and simple.
>
> Not as bad as you, or Debian:
>
> http://www.zdnet.com.au/news/software/0,2000061733,39196419,00.htm
Doh! DFS! You stuuopid windope!
Completely out of date - June 2005 link.
Roy Schestowitz
Don't flatter Fiesta. It's more like the preparation of an hamburger, not a
wooden merchandise.
I also forgot to mention that my attitude/reply in the above scenario would
have gone along the lines of: no connection after Windows Update? Your O/S
has reached a moribid and misunderstood state. Back up your data,
re-install and re-patch.
Realistically, I must be more comforting than that with the staff (my main
job). As for students with virus issues (secondary job), the response would
usually be re-install, or even better, migrate to a better operating
system.
Roy
--
Roy S. Schestowitz | "Computers are useless. They only solve problems"
http://Schestowitz.com | SuSE Linux | PGP-Key: 74572E8E
2:00pm up 52 days 2:14, 5 users, load average: 0.43, 0.47, 0.47
Peptide One
Actually, you're wrong (again). More than likely, the Admin did not set
the permissions on the directory causing the problem. How many Admins
drill down to the C:\Winnt\Registration folder and exclude system
privileges? Seems kind of silly to say, doesn't it?
I say that because of my experiences with this problem.
We ran into this (and other problems) after running Microsoft's Baseline
Security Analyzer, which caused these errors to happen on several
systems a few years ago.
Also, we encountered problems installing Exchange on systems that had
not yet been locked down (they were being built), then discovered this
article:
http://support.microsoft.com/kb/318731/EN-US/
Nobody changed anything... this box was straight from the factory with a
fresh Windows Server 2000 Standard installation.
So, no, user intervention is not required to cause this error on Windows
machines.
--
Beauty is only epithelial cells deep.
Sinister Midget
> Erik Funkenbusch <er...@despam-funkenbusch.com> writes:
>> The problem here is that you did not give the COM+ subsystem rights to a
>> resource it needs. You don't have to make the folder world writable, just
>> give COM+ access. Because you changed this setting from it's default, you
>> are at fault.
>
> I'm a sysadmin, not a COM+ developer. *How* am I supposed to know what
> permissions the COM+ system needs? Where is that documented? Where
> actually *is* documented what subsystems need what folders and what
> permissions thereon?
C'mon, you know the answer to this! Leave everything world readable,
writable and executable in case $MONOPOLY needs to manipulate something
or install a new spybot.
Then the only education required is how to reinstall often.
Yes, you'll sometimes have to reinstall a couple of times to make the
soundcard and browser on the company server work OK again. But once you
have this reinstall thing down, it's not /that/ much more trouble to
take a few extra hours to try it again.
Let's just call the added reainstall times "practice".
--
The brain of the average IE user. Divide by five for Outlook.
/
/
.
Rich Bell
Once again a COLAnut is unable to defend against the flaws in a Linux
distro. Instead, he takes a perfectly valid link to a site that shows the
reality of dependency hell and patches that break your system and claims
that it isn't valid because it occured four months ago. Note that this patch
will screw 30% of it's users. The guy says "The upgrade process should be
tested continually during development". Really? What a concept!" Do you
really want to trust you mission critical systems to these "developers"?
Those "many eyes" can't spot a flaw that affects 30% of the systems using
that distro?
What a moron!
DFS
So? It's still an example of how Linux sucks. A new Debian is released
after several years, and it breaks up to a third of users' systems? Windows
has NEVER had such a bad record.
And even though you're a cola reg, and it's your stock in trade, try not to
be so hypocritical - you cola whiners regularly talk about how bad Windows
was 5 or even 10 *years* ago.
Freeride
>
> Once again a COLAnut is unable to defend against the flaws in a Linux
> distro. Instead, he takes a perfectly valid link to a site that shows the
> reality of dependency hell and patches that break your system and claims
> that it isn't valid because it occured four months ago.
> Note that this
> patch will screw 30% of it's users. The guy says "The upgrade process
> should be tested continually during development". Really? What a concept!"
> Do you really want to trust you mission critical systems to these
> "developers"? Those "many eyes" can't spot a flaw that affects 30% of the
> systems using that distro?
>
> What a moron!
No your the fscking moron did you even read the article? If you did you
would see that a "Upgrade" an in complete OS upgrade "MAY" break the
system. Unlike the one little 512K M$ patch that hoses your system.
Have you ever done any OS upgrades with M$? you have about 10% chance of it
working!!
Rich Bell
number. You morons loved to talk about the problems caused by XP SP2 and
that affected far fewer than 30% of it's users. Most of those problems were
related to tightened security. When it was less secure you whined about
that. When it is tightened up and a few apps break, you whined about that.
COLA is a haven for hypocrites.
> Have you ever done any OS upgrades with M$? you have about 10% chance
> of it working!!
I have NEVER had a Windows upgrade break my system. Apparently YOU have
never done an Windows.
7
BWAHAHAHAHAHAHAHAHAHAHAHAHAHA!
Windope XP shite and particularly SP2 still not widely deployed.
Some 30% of the possible installed base only
because stability problems.
Even mega corporations are afraid of being micoshafted.
Talk about hypocrites!!!
7
Idiot!
There is no such thing as a complete update as referred to in the
article. Its probably mentioned it like that to make it
comfortable for windiots to identify with their own upgrade process
disasters.
Distro makers roll out incremental updates and would
never be faced with 100% update situation. You have but
to name one that has this problem!!
7
> I have NEVER had a Windows upgrade break my system. Apparently YOU have
> never done an Windows.
I have never heard of one windope that hasn't had upgrade problems.
So that makes you a supreme astro turfing liar or supremely
lucky windope very distant from reality.
Nigel Feltham
> On Sun, 16 Oct 2005 07:51:00 +0200, Jafar As-Sadiq Calley wrote:
>
>> "this issue is only affecting people with very specific NTFS permissions.
>> If the C:WinntRegistration folder is locked down and cannot be written to
>> by COM+ you will have errors similar to those listed in your alert. All
>> of those tasks use COM+ in one way or another."
>>
>> So, it appears that Microsoft is blaming others as usual. Their response
>> to this problem?
>>
>> "This is not a "known issue" or "problem" with the patch, but a
>> "complexity with the increased security provided by the patch when
>> running on systems where settings have been incorrectly changed from the
>> default settings".'"
>>
>> I see, so changing system settings to make the machine more secure is
>> "incorrect?"
>> Windows sucks plain and simple.
>
> No, changing the system settings to something that is incorrect for the
> system to function is "incorrect".
But the systems were functioning fine until the latest security patch was
installed.
> The problem here is that you did not give the COM+ subsystem rights to a
> resource it needs. You don't have to make the folder world writable, just
> give COM+ access. Because you changed this setting from it's default, you
> are at fault.
Yes with windows anything that goes wrong is always the user's fault - it's
their fault for attempting to make the system safer and not the patch that
caused the system's final demise.
> This is like complaining that your system won't boot if you delete the
> kernel. It's something YOU did. And you didn't do it correctly.
Of course - if installing a security patch deletes the kernel it's the
user's fault?
Erik Funkenbusch
>> No, changing the system settings to something that is incorrect for the
>> system to function is "incorrect".
>>
>> The problem here is that you did not give the COM+ subsystem rights to a
>> resource it needs. You don't have to make the folder world writable, just
>> give COM+ access. Because you changed this setting from it's default, you
>> are at fault.
>
> I'm a sysadmin, not a COM+ developer. *How* am I supposed to know what
> permissions the COM+ system needs? Where is that documented? Where
> actually *is* documented what subsystems need what folders and what
> permissions thereon?
Not a valid argument. If you're a sysadmin, you damn well better know what
permissions each file is supposed to have, or you shouldn't be touching
them.
The same applies to Linux. If you go blindly removing the access to all
files but root, daemons will stop working, various functions will only be
accessible as root, etc..
It's not like the documentation is there for Linux either, you'd be stuck
digging through each and every installed program trying to understand what
each of their security settings are. OR, you can leave it at its default,
which is already secure.
If you must change the security settings, then you should look at what they
are first. For instance, if Users have read permission and you don't want
them to, but COM+ has read/write. You can remove the Users access, but
leave the COM+ rather than willy nilly removing all user access.
> So it's either accept the (possibly unsafe) defaults
Possibly unsafe? If you don't know, you shouldn't be changing it.
> or start reading developer-level documentation.
Not even close. You only need to look at the existing settings and note
any special permissions and keep them.
> I thought the main buy for Windows was that it was cheaper to admin?
If you don't go breaking everything without knowing what you're doing,
sure.
> This way, it costs either in time or in
> admin education (better educated admin are *lots* more expensive than
> mere MCSEs).
The default permissions are secure. Non-priviledged users will not be able
to affect it.
Erik Funkenbusch
It appears you cannot read. The person i'm responding to says they
deliberately changed the permissions to make it "more secure".
"I see, so changing system settings to make the machine more secure is
'incorrect?'"
He's talking about deliberately changing permissions.
> I say that because of my experiences with this problem.
> We ran into this (and other problems) after running Microsoft's Baseline
> Security Analyzer, which caused these errors to happen on several
> systems a few years ago.
I've never heard of MBSA changing security settings. In fact, all it does
is scan, not repair anything.
> Also, we encountered problems installing Exchange on systems that had
> not yet been locked down (they were being built), then discovered this
> article:
>
> http://support.microsoft.com/kb/318731/EN-US/
I'm confused. Nothing in that article says anything about permissions or
changing them. All it does is describe how to delete a corrupted registry
entry and then re-register the component.
> Nobody changed anything... this box was straight from the factory with a
> fresh Windows Server 2000 Standard installation.
I'm sure, since it had nothing to do with this issue.
> So, no, user intervention is not required to cause this error on Windows
> machines.
If that's your evidence, you need to rethink your argument.
Erik Funkenbusch
> Erik Funkenbusch wrote:
>
>> On Sun, 16 Oct 2005 07:51:00 +0200, Jafar As-Sadiq Calley wrote:
>>
>>> "this issue is only affecting people with very specific NTFS permissions.
>>> If the C:WinntRegistration folder is locked down and cannot be written to
>>> by COM+ you will have errors similar to those listed in your alert. All
>>> of those tasks use COM+ in one way or another."
>>>
>>> So, it appears that Microsoft is blaming others as usual. Their response
>>> to this problem?
>>>
>>> "This is not a "known issue" or "problem" with the patch, but a
>>> "complexity with the increased security provided by the patch when
>>> running on systems where settings have been incorrectly changed from the
>>> default settings".'"
>>>
>>> I see, so changing system settings to make the machine more secure is
>>> "incorrect?"
>>> Windows sucks plain and simple.
>>
>> No, changing the system settings to something that is incorrect for the
>> system to function is "incorrect".
>
> But the systems were functioning fine until the latest security patch was
> installed.
So, your car seems to work fine using a screwdriver to unlock your car and
start the ignition. Then you apply a "security patch" that replaces the
locks and suddenly you can't get into your car or start the engine anymore.
Damn, that security patch must have been bad.
Just because it worked before doesn't mean it was correct.
>> The problem here is that you did not give the COM+ subsystem rights to a
>> resource it needs. You don't have to make the folder world writable, just
>> give COM+ access. Because you changed this setting from it's default, you
>> are at fault.
>
> Yes with windows anything that goes wrong is always the user's fault - it's
> their fault for attempting to make the system safer and not the patch that
> caused the system's final demise.
This didn't go wrong by itself. The user deliberately changed their
settings. This resulted in a system that failed after a security patch was
installed. It *WAS* the users (Well, Adminsitrators) fault.
What do you think would happen to a Linux system if you decided to remove
all Group and Other ownership from all files "to secure it"? Would that,
or would that not be the users fault?
>> This is like complaining that your system won't boot if you delete the
>> kernel. It's something YOU did. And you didn't do it correctly.
>
> Of course - if installing a security patch deletes the kernel it's the
> user's fault?
That's not what happened. The patch only tightened the security so that
whatever was letting your system run in the previously incorrect
configuration no longer worked.
Erik Funkenbusch
>> I see, so changing system settings to make the machine more secure is
>> "incorrect?"
>> Windows sucks plain and simple.
>
> Not as bad as you, or Debian:
>
> http://www.zdnet.com.au/news/software/0,2000061733,39196419,00.htm
This is not the same thing at all. This is not a case of security
tightening causing an incorrect configuration that had been previously
working (even though misconfigured) to stop functioning. This is a major
upgrade.
Upgrades are always problematic. Even on Windows, upgrades have a pretty
high failure rate (not 30%, but still significant). That's just what
happens when you change so much at one time. There is always risk for edge
cases to go wrong.
Even when an upgrade works, it tends to leave a system in a non-optimal
state, which is why I almost never do an upgrade.
Erik Funkenbusch
Age is irrelevant. What if I didn't upgrade 4 months ago and am doing it
today?
There are other reasons the argument is invalid, but age is not one of
them.
Jim Richardson
Hash: SHA1
On Sun, 16 Oct 2005 16:24:55 -0500,
Erik Funkenbusch <er...@despam-funkenbusch.com> wrote:
> Just because it worked before doesn't mean it was correct.
With MS software, those are words to live by.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDU1Pud90bcYOAWPYRAlAxAJ9ltGfHWbKv7PPGWyvUY5feEE2U/wCgjkHW
C34UVBKLWJEKcufcojWAFOM=
=A+IT
-----END PGP SIGNATURE-----
--
Jim Richardson http://www.eskimo.com/~warlock
Focus on the goal, not the path.
Mart van de Wege
> On Sun, 16 Oct 2005 13:02:17 +0200, Mart van de Wege wrote:
>
>>> No, changing the system settings to something that is incorrect for the
>>> system to function is "incorrect".
>>>
>>> The problem here is that you did not give the COM+ subsystem rights to a
>>> resource it needs. You don't have to make the folder world writable, just
>>> give COM+ access. Because you changed this setting from it's default, you
>>> are at fault.
>>
>> I'm a sysadmin, not a COM+ developer. *How* am I supposed to know what
>> permissions the COM+ system needs? Where is that documented? Where
>> actually *is* documented what subsystems need what folders and what
>> permissions thereon?
>
> Not a valid argument. If you're a sysadmin, you damn well better know what
> permissions each file is supposed to have, or you shouldn't be touching
> them.
>
Valid argument. Unless you missed my question on where the
documentation is? If I am to admin a system, it behooves the vendor to
give me docs. And yes, that *is* optimistic, but Microsoft is, here as
in other things, the worst of a bad lot.
> The same applies to Linux. If you go blindly removing the access to all
> files but root, daemons will stop working, various functions will only be
> accessible as root, etc..
>
> It's not like the documentation is there for Linux either, you'd be stuck
> digging through each and every installed program trying to understand what
> each of their security settings are.
And since I have the source, I can always find out, even if the
documentation is not up to snuff.
>> I thought the main buy for Windows was that it was cheaper to admin?
>
> If you don't go breaking everything without knowing what you're doing,
> sure.
>
In other words, just do clicky-clicky on the pretty wizards, and let
Microsoft worry about the rest.
No wonder MCSEs have such a bad reputation.
>> This way, it costs either in time or in
>> admin education (better educated admin are *lots* more expensive than
>> mere MCSEs).
>
> The default permissions are secure.
Allow me to laugh heartily. Microsoft and default secure permissions?
I'm dying here.
They even admitted themselves that their defaults used to value
convenience over security, and I am *not* convinced that their 'Secure
Computing' initiative has fixed that yet over the entire line.