RE: [VulnDiscuss] Re: iDEFENSE Security Advisory 01.28.03: SSH2 Clients Insecurely Store Passwords

On Thu, 30 Jan 2003, Dave Ahmad wrote:

> That the window of opportunity shrinks is exactly it.

I do not think it makes much sense to say that applications that do not
scrub memory are vulnerable, and those who do, are not, that's all.
Scrubbing the memory, in most cases, is merely a minor mitigating factor,
and does not make applications not vulnerable to the attack. Moreover, the
privilege level is needed to perform the attack, in absence of this
particular vector, is usually still sufficient to perform an equivalent
attack.

An interesting problem: if I type, within a SSH session, 'su -' followed
by my root password, the client does not scrub this memory. The attacker
can access this memory later on and can get my root password on the remote
server. Is the SSH client flawed?

I think it is a foolish assumption that login passwords are the only
sensitive part of information that is being exchanged between two
endpoints. If the system allows one process to read other process's
memory, hijack user's input or read the display, it is the OS where the
exposure is taking place, and this is where it should be stopped (and, as
a matter of fact, usually can be).

The exposure caused by this particular issue seems to be simply irrelevant
in the real world. I think there are only three attack scenarios that are
likely to happen:

  1) The attacker gains an unprivileged access to the account of an
     SSH user before a session is established. This is the most common
     scenario. The attacker would simply do what they are doing today
     - modify user's environment to inject some code when the client is
     executed, and to hijack the password as it is being read. This is a
     common and very trivial practice, and in this scenario, scrubbing
     the memory buys us nothing, as the attacker is not likely to choose
     a more difficult and less reliable method of obtaining the
     information. The issue here is that the attacker can read memory
     and tamper with the environment, not that a password is available
     in memory.

  2) Like 1), but the compromise occurs while the session is already in
     progress. The attacker indeed has an advantage if that's the only
     session ever to be established to this server. But I have a very
     strong feeling that this is unheard of. Most sessions are established
     repeatedly, in which case, the problem is reduced to 1), and this is
     what most attackers do and will continue doing after learning about
     memory scrubbing vulnerabilities. If the attacker is impatient or
     fears of being detected soon, he can easily simulate a lock-up or
     disconnection of the other session to force the user to re-type the
     password.

     If the attacker is very desperate to obtain credentials of this
     particular session, he can inject some commands on logout instead of
     looking for passwords. So it seems that in almost all cases, being
     not able to fetch the password instantly is just a minor annoyance,
     and the problem is somewhere else.

  3) The attacker gains physical access to the device - for example, the
     workstation is stolen. He knows what to look for in the swap file and
     is hoping to find swapped out passwords.

     Now, it's still possible to have the password swapped out, whether
     we scrub 'em or not. It might be easier if the information is kept
     in memory for a long time on a page that is barely used, but I have
     not seen any effort to evaluate whether this is really the case.
     I would expect that a number of implementations actually store
     passwords on "busy" pages or even on stack.

     If you have a reason to be concerned about this, you can't afford
     having passwords "somewhat less likely" swapped out, you need to
     make sure they won't, and a trusted OS plus page locking is the way
     to go.

> Off-list I mentioned to Dragos that the idea is to minimize the amount
> of time that the data is stored in accessible memory.

Yes, I understand the idea. My only point is that, I have a strong feeling
that it buys us very little in the real life.

> A good example of why scrubbing is not a bad idea are the recent
> vulnerabilities in ethernet drivers (padding frames with unscrubbed
> memory).

...except that the solution for that issue is simply not to expose the
previous frame, and there is no way for the attacker to get to the data
once it is fixed if he wasn't able to see those frames in the first place.

> In our vulnerability database, the failure to scrub credentials buffers
> is considered a 'weakness' rather than a 'vulnerability' -- the
> distinction being that weaknesses are noteworthy conditions that cannot
> be exploited on their own.

I think it's a good way to refer to those issues, yup.

Regards,
-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-01-30 12:35 --