RE: Another Low Blow From Microsoft: MBSA Failure
This is referring to MS03-043 on a Windows 2000 system scanning with
MBSA 1.2 (the mbsa version is important, as different versions of MBSA
use entirely different XML files)
The entry in the XML file used by MBSA 1.2 references two files for this
patch. The XML file does not list any reg keys for this entry,
therefore reg keys are not being used.
The MBSA engine is reading the files from disk. That you are not seeing
it as missing, means it sees the expected file version on disk.
Simultaneously, third party tools are telling you that the vulnerability
still exists. Not knowing exactly how these third party tools operate,
we can still reach a conclusion where all tools are operating 'by
design'.
The expected new files are on the target system - they have been written
to disk and are no longer sitting in pendingfilerename queues. However,
the system executed these files and placed them in memory when the
services were started, presumably before the patch was applied. So the
copy of the file in memory (and currently in execution) is the old
vulnerable copy, while the copy of the file on disk is the new copy, not
yet placed into execution. Restarting these services, or restarting the
box will make the service reload the files from disk, thus placing the
new files into execution on the stack against which the third party
vulnerability scanning products are testing.
No reg keys involved - just a difference of file on disk vs. file in
memory\execution.
--eric