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:[EMAIL PROTECTED]]
Sent: Monday, January 24, 2000 11:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
