-----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-----
This archive was generated by hypermail 2b30 : Wed Nov 14 2001 - 12:48:12 PST