or KB document.
gotta find a new OS vendor.
I'm afraid I can't help you much with your paranoia. ;-)
Okay.. so either way.. what you're telling me is that you installed a
"rescan".
But, again, that was in 2003, four years ago. It's really a pointless
discussion now.
Like I said above.. it matters not what the PRODUCT used to scan or install
to install a two year old product onto current hotfix security patches.
TEST TEST TEST TEST TEST.
that, deploy it to production systems.
I really don't think there's much else I can say.
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
....
Post by Lawrence Garvin (MVP)Actually, this is a misconception.
The =engine= is contained within the Windows Update Agent code.
However, the =data= that tells that engine what to do is contained within
the update package itself, and is unique to each update package.
It's generally this data that is the reason updates have "revisions", and
MSRC documents are revised. Case in point -- just today Microsoft revised
MS07-022 for issues affecting people running Windows 2000 Service Pack 4 on
NEC 98 systems.
Thus my comments, elsewhere, indicting the "scanning tools" used to
determine whether the post-install AppCenter2000SP1 system was secure. MBSA
v1.2.1 didn't exist in 2003 when this incident happened. I know that it was
2003, because if it had been 2004 they surely would have installed
AppCenter2000SP2 -- although that wouldn't have been any guarantee either,
since AppCenter2000SP2 (Jun 2003) also predated MS03-026 (Jul 2003).
Hehe... so AppCenterSP2 was released *before* MS03-026, and they chose to
install a slipstreamed *downlevel* version of the application. Go figger...
but it was suicidal, at best (and, of course, we also have the benefit of
hindsight to support that appelation).
Which then makes me want to ask when this really did occur, but either way,
I think it would just complicate the decisions behind the deployment
choices -- either way, the *current* version of the application was not
installed.
Windows File Protection on a Windows 2000 Service Pack 3 system? Service
Pack 4 was only released in June, 2003, and I suspect not yet installed on
the subject system, given that they also were not installing AppCenterSP2
(Jun 2003).
No, I don't think that's what Asher is suggesting, but then I also think
that he's misunderstood that this incident is a legacy incident, that
occurred four years ago, not in the recent past.
It's also irrelevant, because AppCenter2000 isn't a supported product at
all, any more. Mainstream Support expired in July, 2006. Only Security
Updates for AppCenter2000SP2 are available, now.
However, in either situation, the *correct* installation methodology would
have surely alleviated some of the issues experienced. The *application*
being installed was at a SP level dated from October, 2001, on top of a
patch released in July, 2003 (and possibly, even, an unsupported SP level if
this all happened after June 2004).
That means, de facto, the *application* had no knowledge of any updates
applicable to that system beyond that date -- even the most current SP for
that application could not have known.
The logical conclusion (at least to me) would be that *anything* released
after that date was subject to having been corrupted. At a minimum I would
have (RE)INSTALLED Service Pack 4 (Jun 2003), and all security patches
released after Service Pack 4 (which would have included MS03-026) -- but
then I would have also installed the product's most recent service pack as
well.
The second problem was trusting the patch tools available at that point
(Windows Update) to properly identify the deficiencies in the patch level of
the system. In 2003, all that WU did was check a registry value to determine
if a patch had been "installed" or "not installed". The only certain way to
know was to personally verify the file versions and/or simply reapply the
update(s) potentially affected -- and certainly any Critical Security
Updates -- like a Blaster patch!
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....
Post by Harry JohnstonYeah, but I'd define the Windows Update *product* to include both the Windows
Update Agent and the update packages - neither can function without the other,
after all.
Ah. That would explain it. I hadn't quite picked up on quite how far back into
the dark ages we were looking here.
Sure, but that's not my point. I think that if patch corruption isn't reliably
detected - regardless of what may have caused the corruption - this is (or was!)
a legitimate concern. (It could - presumably - just as easily have happened as
the result of a recent but badly written third-party installer.)
Does Windows File Protection address this problem? It seems that it should, but
I don't know a lot about exactly what it actually does. Certainly I've seen
QFECHECK report a problem when WFP was silent - but I'm still not sure whether
or not that was a false negative or a false positive, and slipstreaming was
involved which I suppose bypasses WFP anyway.
Harry.
Post by Lawrence Garvin (MVP)I understand that propensity for the common perception -- but the
distinction is actually very significant.
There's this natural inclination to want to blame WSUS, WUA, or the WSUS/WUA
dev teams for failings that appear to be in the product, that are actually
defects in the detection -parameters- defined by the update itself.
Perhaps the most classic example I can recall off the top of my head is the
(still existing) Snafu with the JVM update (KB816093). See this article for
additional info: http://wsusinfo.onsitechsolutions.com/articles/004.htm
Those update detection parameters are solely the output of the individual
product team's Sustained Engineering groups -- and totally outside the
purview of the WSUS/WUA teams. So, in the above example, the flaw lies in
the work product of the JVM SE group -- no doubt which was long disbanded by
the time the detection flaws in KB816093 were discovered by WSUS 2 admins in
July, 2005.
It's kind of like a beer distributor. They bring the Budweiser to you, and
they're responsible if the glass is broken, or the cans are dented, but they
got nothing to do with whether the beer tastes good, or whether you prefer
MGD to Bud Select.
<VBG>
I absolutely agree with you.
But the appropriate procedures in 2003-2004 are entirely different than the
appropriate procedures in 2007.
In 2003, the situation require a much greater involvment of *human*
verification and validation.
Granted, but either way, there's still a certain amount of undenyable
responsibility that sits in the lap of the person at the console.
*Today* on a Win2003 or WinXP system, yes, WFP would definitely have
prevented that snafu.
Actually, the whole updated patch mechanism built into XP and 2003, which
makes use of the %windir%\$hf_mig$ update cache folder, would have
automatically replaced that downgraded DLL needed by MS03-026.
In fact, just the other day I hit a wall with WFP trying to downgrade a WUA
to do testing on the WUA upgrade patch for WSUS 3.0. Because the wups.dll
files were installed from the WUA v7 package, and covered under WFP, when
the WUA v5.8 installer tried to overwrite them via use of the /wuforce
switch -- or when I tried to manually delete them and replace them with the
v5.8 files -- WFP simply replaced the v7 files.
In fact, it's this very technology that's obsoleted the legacy practice (on
WinNT and Win2000) of having to 'reinstall' the latest service pack after
every OS "life changing" event.
Possibly. I'd have to look at this. WFP is supposed to be protecting core
"RTM" files also, so by that standard, slipstreamed updates should also be
protected. On the other hand, if slipstreaming doesn't properly update the
WFP registration database, WFP would have no way of knowing that a newer
version had been replaced. Also, WFP is quite dependent on the "cache" copy
of those files in the dllcache folder, and if they're not there, they
wouldn't be replaceable.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....
Post by Harry JohnstonI hadn't thought of looking at it that way. Certainly the actual update is not
part of the Windows Update product; for example, if the update doesn't actually
close the vulnerability it is supposed to address, that certainly isn't a
Windows Update problem. By analogy, then, the detection parameters also aren't
part of Windows Update, though the implementation of those parameters is.
Harry.
Post by Lawrence Garvin (MVP)Exactly.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....
Submitted via EggHeadCafe - Software Developer Portal of Choice
Lucene.Net Indexing Searching Entry Level Tutorial
http://www.eggheadcafe.com/tutorials/aspnet/c69ef65f-e3c6-409e-ab97-168897c74f83/lucenenet-indexing-searching-entry-level-tutorial.aspx