-----BEGIN PGP SIGNED MESSAGE-----

Hi All -

I'd like to provide some additional information about the
vulnerabilities reported by Camisade regarding the Windows
2000 RunAs service. Briefly, RADIX1112200101 and
RADIX1112200102 discuss scenarios in which the author
reports that it could be possible to compromise the
credentials of a RunAs user, while RADIX1112200103
discusses a denial of service opportunity against the RunAs
service. Microsoft investigated all the reports thoroughly
as soon as we received them, and kept Camisade abreast of
our progress. Here's what we found.

RADIX1112200101. In order to exploit this vulnerability,
the attacker would need the ability to pause the RunAs
service. However, this requires administrative privileges.
Clearly, if the attacker already has administrative
privileges on the machine, the system is completely
compromised and all bets are off. Even an attacker who did
have administrative privileges on the machine would need to
exploit the vulnerability at exactly the moment when
another user used the RunAs service in order to recover the
other user's credentials.

RADIX1112200102. We investigated this report extensively.
However, the only case in which we were able to recover the
credentials was one in which the attacker had
administrative privileges on the machine, and used a
debugger to directly access memory. We repeatedly asked
Camisole to provide information or code to substantiate
their claim that an attacker could exploit this
vulnerability with normal user privileges, but they never
provided it.

RADIX1112200103. The most important point to note here is
that this is a denial of service against the RunAs service
only -- it would not allow the system or any other services
to be disrupted. Further, the exploit scenario is fairly
restricted. An attacker could only exploit this
vulnerability on the local machine, so the sole outcome of
a successful attack would be to deny use of the RunAs
service to the attacker himself (or, in the case of a
terminal server, to other users of that machine)

We do agree with Camisade that in each case there is a flaw
we need to fix. However, the changes are fairly complex
and will require significant testing to ensure their
quality. After weighing the many mitigating factors
associated with these bugs versus the complexity of the
needed changes, we concluded -- and continue to believe --
that fixing them in Windows 2000 Service Pack 3 is the best
course of action.

I hope that helps to clarify what's going on here.

Regards,

Christopher Budd
Security Program Manager
Microsoft Security Response Center

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQEVAwUBO/K0co0ZSRQxA/UrAQHnmggAgLWah3FgxnW6/x1gAABm5qkFo6Y+oz4f
2sXNLiHTbvDe7OmW3KxAhRWG2eWQr80CyivAOjAz6wNBDtJwtqvlWgUA4Ae/teRh
uB5e5CyNzvlGYbCqe1Bd5VmyQ9AUpMQgzrSL50KIp1qD65M/RZhJKYKQStESUGcZ
K4AeDGMHTM0MUgcDxHXwjiaMATCRSpllrMJ1WcsomL6k89yC1LmQ1OVyrukwIvoZ
9DV6k2eJ2Jitsjc+L3M/WYXW/sZzV9CEFv2JyvFrpYnIxf8RfQVoyID6ms9VF44M
ejuU2Ik8z00PLHsyJML9L3SmrrmyXU9hFEUiu+558d8XvqgKrsINGw==
=noxj
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]