RE: [VulnDiscuss] Re: iDEFENSE Security Advisory 01.28.03: SSH2 Clients Insecurely Store Password
Dave Ahmad <[email protected]>
| Newsgroups | gmane.comp.security.vulnerabilities.watch.general |
|---|---|
| Message-ID | <[email protected]> |
Michal, >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. I agree that these issues are not vulnerabilities, however, I do think they are worth noting. That is why we classify them as weaknesses. We are not really in disagreement so I'll keep this short. This topic isn't really worth lengthy discussion anyways. > 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? Of course not. That is a silly example and not really an interesting problem -- I am not saying that all memory, everywhere, should be scrubbed because of the possibility that it could store something sensitive. Scrubbing buffers used to store credentials, keys, etc after they are no longer necessary is good practice, that is all. It is not very expensive to iteratively write to a region of memory (let's hope not optimized out ;)).. so why should sensitive information persist in process memory? This is not a perfect solution -- there is none. It is just one additional measure to reduce the likelyhood of leakage through other vulnerabilities or some other condition that is not under the control of the developer. > 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. Perhaps, but I don't feel as strongly as you do. You can read memory with format string bugs and there have been other vulnerabilities where memory is output. In my opinion, the relatively few cycles required to zero out most sensitive buffers in programs such as clients, encryption software, etc, are worth it. Kind regards, David Mirza Ahmad Symantec 0x26005712 8D 9A B1 33 82 3D B3 D0 40 EB AB F0 1E 67 C6 1A 26 00 57 12