Hi,

Thanks very much for your note and for sending this on.  We really
appreciate it.

To understand the issue fully, it would be good to expand this somewhat.
There really are two issues here:  One related to the ability to mount
an attack successfully, and one related to how data is stored on a
system and what could happen to that in light of a successful attack.

To be clear, none of the attack scenarios that you've described are
mounted through MBSA itself.  Also, the attack you've described does not
exploit a vulnerability in any product: in a default system this attack
fails.  It's only when a user chooses to run code from an untrusted
source and proceed despite the security warnings provided that this
attack could succeed.  Protecting systems against untrusted code is
vitally important, and we call this out in our 10 Immutable Laws of
Security as Law #1
(http://www.microsoft.com/technet/columns/security/10imlaws.asp), to
underscore it's importance.

If an attacker were able to convince a user to run their code, that code
would then be able to take any actions on the system that the user can
take.  While it's true that MBSA stores its information in a known
location, storing it in an unpredictable location wouldn't measurably
change the situation.  An attacker's code could just as easily search
the local system for the file. Likewise, it's true that MBSA's
information can be read by the user (or code running as the user).  But
even if the MBSA information weren't present on the system, code running
as the user would be able to determine the presence or absence of
patches, simply by consulting the time/date information contained in the
publicly available MSSecure XML database.  Again, it's a question of
degree rather than feasibility.  

The larger issue in both cases is the presence of code running with the
user's privileges.  If the attacker can't run code, it doesn't matter
how the MBSA data is stored, because the attacker can't access it.  If
the attacker can run code, he or she doesn't need the MBSA data, as they
already have all the privileges needed to duplicate the MBSA processing.
(For that matter, the attacker could simply run MBSA itself and do a
"screen scrape").

That said, we are always looking to make improvements and we appreciate
concerns and feedback like this.  Our MBSA team are looking at these
suggestions along with others that we've received and consider them as
they design future versions of this tool.

Thanks again for sending this on, we really appreciate it.

Regards,
secure () microsoft com