OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: Win NT 4.0 UserId and Password available in memory
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Win NT 4.0 UserId and Password available in memory

At 11:33 AM 12/15/98 -0500, David LeBlanc wrote:
>Someone told _you_ that you didn't know anything about security? ROTFL.

You try to help out and learn while your doing it. You are going to make
mistakes, and believe me I have plenty of times in public forums. People
are going to be snappy and give you a little poke when you are wrong - that
is the nature of techie people (myself included). But, some people just
suck, and instead of poking you they yell about how stupid and wrong you
are. Those kinds of people just better be damn sure they are right!

>However, I do have somewhat of a disagreement with your position.  As you
>very well know, when we break into one machine at admin level, we'd like to
>be able to leverage that to gain access to other systems.  So making it
>more difficult for one admin to become another user is of some benefit.
>We'd especially like to make it more difficult for people to make that jump
>using methods which we can't easily audit.

I do agree, and there is probably no good reason for the password to be
stored in plaintext in memory. Ideally it is not there, but you know my
point was that it is not a security threat leveraged by un-trusted users.
Your point starts getting into the area of how to provide robust security
in a hostile environment. Unfortunately, I have to agree with the paper
"The Inevitability of Failure: The Flawed Assumption of Security in Modern
Computing Environments" in that we can not provide truly robust security
with discretionary security controls that exist in current commercial
operating systems.

>One other point which I'd like to add is that now that we know that this
>information is kept in clear-text, we may be able to develop ways to get to
>it using some other method than just opening the process like we're
>supposed to.  That's worth a bit of examination.  We're clearly not looking
>at the newest gaping NT hole, but this isn't something I feel comfortable
>completely dismissing, either.

Nor do I, and I was a bit hard-lined and frustrated in my post. I don't
think there is any good reason for the plaintext to exist in the process
space, so it probably shouldn't. At the same time, the risk of it being
there is of little consequence when the whole architectural model is taken
into account. I rather see MS spend time and money putting assured
mandatory security controls into NT than fixing this issue. The difference
between 5 minutes of work and 75 man years of work is pretty great though
;) You know me - I could talk forever about a myriad of issues surrounding
all this stuff, but I going to shut up now!

Dominique Brezinski CISSP                   (206) 898-8254
Secure Computing        http://www.securecomputing.com