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 for Android: free password hash cracker in your pocket

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

Message-ID: <438D21CF.8F262FB4@dessent.net>
Date: Wed Nov 30 03:51:56 2005
From: brian at dessent.net (Brian Dessent)
Subject: Google Talk cleartext credentials in
	processmemory

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.  There are a number of resources
on how to do this, it is far from impossible:
<http://nonadmin.editme.com/> and
<http://blogs.msdn.com/aaron%5Fmargosis/> are two.

The fact is that if you get to the point where you A) can run code on
the target's computer and B) that code has sufficient privileges to read
another process's memory, then you've already lost, it's too late. 
Trying to mitigate things at that point is just re-arranging deckchairs.

Even if the target program scrambles the password in memory, it by
definition has to use the password in cleartext at some point (otherwise
it would have no need for it in the first place) and so the attacking
program could use a number of methods (like dicking around with process
or thread priorities to create a race condition, using the debug API,
using the hooks API, intercepting window messages, etc) to read the
process's memory at the moment that it had the password in cleartext.

As you yourself point out, there are a very large number of programs
that don't bother to try to obfuscate cleartext secrets in their own
process memory, because they realize it's just not their problem to deal
with.  Fixing all of them would be nearly impossible.  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.

Brian