Bugtraq mailing list archives
Re: Windows 2000 Run As... Feature
From: jdglaser () NTOBJECTIVES COM (jdglaser)
Date: Tue, 25 Jan 2000 00:10:26 -0800
David LeBlanc wrote to me about this as well. And it's a valid point. The point I want to make is related to David Terrell's original concern, which quite frankly, alot of NT users have. And that is this issue of the Trusted Path SAS. They give more trust to SAS than it deserves. SAS says you can trust that this will safely get your password to the kernel with out intervention. If this were not the case, Terrell would not even have expressed a concern. Because MS documentation is the way it is, it appears that SAS is deeply tied to the kernel and hardware and that it is Trojan proof. This is not the case. SAS is modular, comprised of many components and has a MS "built-in guaranteed way" to alter the Trusted Path. This is important for the following reason: If an attack occurs on an NT service, it doesn't usually cross the mind of admins that SAS is now possibly not safe. Admins do not think to look at this as a possibility to examine because while it's obvious that some bi naries might have been altered, it is not obvious that the trusted path has been broken, that it could be broken. To me, the danger is, on the one hand, MS makes known to developers the methodology for changing this trusted path, while on the other, leaves a false impression to admins. I think this is relevent to the training of NT admins about Trojan behavior in NT and about correcting the belief that SAS is trojan proof as any NT book would have you believe. Lastly, I'll say that this type attack is pretty simple as an overflow (which would bypass the ACL) could drop the trojan and leave. Since we are talking trojans and trust, this seems to apply to me. I would classify this as a different catagory of attack than binary kernal modifications. I concede I may be wrong, but admins should understand the correct behavior. And at the least have that information available to them. _jdg NT OBJECTives, Inc. http://www.ntobjectives.com -----Original Message----- From: Camillo Sars [SMTP:Camillo.Sars () F-Secure com] Sent: Monday, January 24, 2000 11:41 PM To: jdglaser () ntobjectives com Cc: BUGTRAQ () SECURITYFOCUS COM Subject: Re: Windows 2000 Run As... Feature jdglaser wrote:
I'd like to add that MS Secure Attention Sequence is not exactly so trusted. Nothing prevents another Gina from being put into play, nor prevents process code injection - DLL API hooking.
This requires Administrator privileges, or the ability to act under the SYSTEM account. With such privileges, anything is possible. I wouldn't agree that this is a problem. The SAS is a guaranteed way of passing control to a SYSTEM process. Provided, of course, that your system has not been compromised, and that any other SAS implementations do not utilize non-privileged code. Regards, Camillo -- Camillo Sars <Camillo.Sars () F-Secure com> http://www.iki.fi/ged/ Researcher, Crypto Research http://www.F-Secure.com/ F-Secure Corporation (formerly Data Fellows Corporation) F-Secure products: Integrated Solutions for Enterprise Security
Current thread:
- Re: Windows 2000 Run As... Feature, (continued)
- Re: Windows 2000 Run As... Feature Steve Wolfe (Jan 26)
- Re: Windows 2000 Run As... Feature Kenn Humborg (Jan 27)
- SAS behavior in Windows NT - RE: Windows 2000 Run As... Feature jdglaser (Jan 26)
- Re: SAS behavior in Windows NT - RE: Windows 2000 Run As... Feature Jesper M. Johansson (Jan 26)
- Re: SAS behavior in Windows NT - RE: Windows 2000 Run As... Feature Peter Berendi (Jan 27)
- Re: SAS behavior in Windows NT - RE: Windows 2000 Run As... Feature David LeBlanc (Jan 26)
- Re: Windows 2000 Run As... Feature Camillo Särs (Jan 24)
- multicasts from hell Tim Yardley (Jan 25)
- Re: Windows 2000 Run As... Feature David LeBlanc (Jan 25)