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: jdglaserat_private Cc: BUGTRAQat_private 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:24 PDT