full-disclosure - Google Talk cleartext credentials in process memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed Nov 30 03:06:50 2005
From: grutz at jingojango.net (Kurt Grutzmacher)
Subject: Google Talk cleartext credentials in process
	memory

Nasko Oskov wrote:

>If you want to protect the credentials in memory from dumps that go to
>Microsoft, why not use CryptProtectMemory() instead of home-grown
>obfuscation? This function encrypts the memory with a key that changes
>over reboots, so even if you send a dump to MS, they wouldn't know how
>to decrypt it.
>  
>
We have a long list of applications that store credentials cleartext in 
memory. I can only remember a few but it's stuff like Google Talk, 
PuTTY's SSH Key Agent, Lotus Sametime, .net apps, even XPsp0/1 and the 
old Novell GINA.

While the attack method of "sending a trojan that grabs this stuff" is 
an easy one to make, lets look at this from the perspective of an inside 
attacker who gains control of an administrator's workstation. It would 
be easier for the attacker to pull the password from memory and use it 
rather than placing the trojan, waiting for it to be executed, getting 
the result, etc. All that code laying around is just waiting to be 
caught. If they pull the credentials from some running process there's 
NO interraction required and no waiting around for the keylogger to get 
caught.

Sure a REALLY GOOD attacker would backdoor the system but again, the 
more traces you leave the more you're begging to be caught.

We as security freaks have hounded and hounded on using secure methods 
to transport credentials. NTLMv2, SSL, SSH, etc. etc. We also have asked 
that applications not store our passwords in the clear either. MD5, DES, 
AES, etc. These are things that we could solve with a bit of programming 
and harrassment. Now it's time for local applications to get the hint as 
well. If you only need the password once to log in to the server with, 
clear out the freaking memory as soon as possible.

If you need to resend credentials then use some sort of a session key 
that will expire or be refreshed.

Just stop keeping our secrets laying around in the "open." That's all we 
ask.

grutz;