full-disclosure - Google Talk cleartext credentials in processmemory

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] [day] [month] [year] [list]

Message-ID: <438DD9C7.3070202@jingojango.net>
Date: Wed Nov 30 16:57:00 2005
From: grutz at jingojango.net (Kurt Grutzmacher)
Subject: Google Talk cleartext credentials
	in	processmemory

Brian Dessent wrote:

>Kurt Grutzmacher wrote:
>  
>
>>Just stop keeping our secrets laying around in the "open." That's all we
>>ask.
>>    
>>
>
>In my opinion this is not a very effective thing to rally against.  The
>operating system already presents a means to protect against one process
>snooping on the other, as has already been pointed out elsewhere in this
>thread.  If this sort of attack is a concern then you should be urging
>the user to not run as administrator.
>
Why is it not effective to try and make our operating systems and
applications a little more secure by not storing our secrets? Until such
time as we deploy usable two or three factor authentication methods
we're stuck with passwords. Since application developers are lazy
they're going to expose those passwords to every tom, dick and harry who
gains access.

I see the password storage issue as falling into three categories:

1 - Password is used once for session
2 - Password is stored for multiple session use but disperses at app closing
3 - Password is stored locally and reused every application execution

Cat 1 can easily be fixed by using functions that clear the memory or
put the variables in a OS-protected keystore (CryptProtectMemory) area
until such keystore is broken ala lsadump2.

Cats 2 and 3 can only really be solved by using the OS-protected keystore.

The CryptProtectMemory function exists for a reason and we should rally
that programmers begin using it or demand that something better be
developed. Yes the attacker could use OTHER methods to obtain the memory
data as it's being used but if the password usage falls under Cat 1,
which a large majority of applications do, then they have to be in the
right place at the right time.

The longer an attacker has to wait for something the greater the
possibility of detection.

>From a
>cost/benefit analysis, which is more effective: Using the operating
>system's built-in protection which works for all processes, or trying to
>convince every Tom, Dick, and Harry that has ever written a throwaway
>shareware app that they need to make some change?  It's whack-a-mole.
>  
>
C Libraries have had strncpy available for a long time but that
certainly doesn't mean developers still don't use strcpy. We've had to
force it down their throats that writing secure code is a GOOD THING. To
me clearing the memory after using a password once is a GOOD THING and
should also be shoved down developers throats. Not storing credentials
in cleartext files is a GOOD THING.

Cleartext passwords just makes the attackers job so much easier with so
little risk.

grutz;