Full Disclosure mailing list archives
Re: Google Talk cleartext credentials in processmemory
From: "Dave Korn" <davek_throwaway () hotmail com>
Date: Tue, 29 Nov 2005 15:12:55 -0000
pagvac wrote in news:b7a807650511280546t25619236y7e442f3a475e3265 () mail 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.... _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Google Talk cleartext credentials in process memory, (continued)
- Message not available
- Re: Google Talk cleartext credentials in process memory pagvac (Nov 29)
- Message not available
- Re: Google Talk cleartext credentials in process memory pagvac (Nov 29)
- Re: Google Talk cleartext credentials in process memory Stelian Ene (Nov 29)
- Message not available
- Re: Google Talk cleartext credentials in process memory Jaroslaw Sajko (Nov 29)
- Re: Google Talk cleartext credentials in process memory Nasko Oskov (Nov 29)
- Re: Google Talk cleartext credentials in process memory Jaroslaw Sajko (Nov 29)
- Re: Google Talk cleartext credentials in process memory Georgi Guninski (Nov 29)
- Re: Google Talk cleartext credentials in process memory Kurt Grutzmacher (Nov 29)
- Re: Google Talk cleartext credentials in processmemory Brian Dessent (Nov 29)
- Re: Google Talk cleartext credentials in processmemory Kurt Grutzmacher (Nov 30)
- Re: Re: Google Talk cleartext credentials in processmemory pagvac (Nov 29)