full-disclosure - Re: 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] [thread-next>] [day] [month] [year] [list]

Date: Tue Nov 29 15:34:33 2005
From: davek_throwaway at hotmail.com (Dave Korn)
Subject: Re: Google Talk cleartext credentials in
	processmemory

pagvac wrote in
news:b7a807650511280546t25619236y7e442f3a475e3265@...l.gmail.com

> Google Talk stores all user credentials (username and password) in
> clear-text in the process memory. Such vulnerability was found on
> August 25, 2005 (two days after the release of Google Talk) and has
> already been patched by Google.

> It was noticed that the Google Talk client was loading all the
> credentials unencrypted in the memory of the process "googletalk.exe".
> It was possible to recover the password by dumping the process memory
> to a file with PMDump and which could then examined with a hex editor.
>
> The vulnerability would allow anyone with access to the client system
> to obtain the username and password of the current user.

  No it wouldn't.  Only Administrators can access a different user's process
space, since w2k at the very least.  There are ACLs on processes, in case 
you didn't know, and they don't allow users to open each other's processes.

  Your testing methodology needs improvement.  You shouldn't make a claim 
like the one above without having tested it.  What _you_ tested is whether 
the credentials could be recovered in memory by /the same/ user, not /any/ 
user.

> This
> vulnerability could also be exploited by fooling the user to execute
> malicious code which would dump the memory of the process
> "googletalk.exe" and then parse the credentials and finally send them
> to the attacker.

  That certainly could work.  Still, if you can get the user to run your
malware, it doesn't matter whether or not any apps on their system are
vulnerable.  The code can do anything it wants.  It could install a 
keylogger and get _all_ your passwords.

  None of this, however, is a vulnerability in Google Talk.

> It is also worth mentioning that sometimes, no direct user interaction
> is required for the execution of malicious code. Crackers often
> exploit vulnerabilities in web browsers and email clients that allow
> them to execute malicious code on the victim's machine without
> requiring the victim to manually execute the trojaned executable. This
> means that given the right scenario, this vulnerability could have
> been exploited in such a way.

  And, of course, when that happens the malware generally does get to run
under the logged-in user's id.  But then again, there are an awful lot far 
more malicious things to do then scan memory for someone's googletalk 
password, if you can just get them to run your malware.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....