On 11/29/05, Dave Korn <davek_throwaway@hotmail.com> wrote:
pagvac wrote in
b7a807650511280546t25619236y7e442f3a475e3265@mail.gmail.com">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.
That's right. The problem is that about 99% of Windows users run
processes using accounts that belong to the "administrators" group.
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.
Again, my testing is based on today's reality which is that most
Windows users use administrative accounts for regular tasks such as
web browsing and using their email clients. As you know Windows NT OSs
(such as NT 4/2000/XP) grant full access to most processes to
administrative accounts (except for some special processes which only
the SYSTEM account has access to).
Yes, my testing methodology needs improvement, and that's why I'm
trying to humbly learn every day. If I was a guru I wouldn't post
messages to a non-moderated list in which users give their feedback.
This is the points of lists like this, you get unrestricted feedback
from other users. This is why I thank you for posting your opinion.
Thank you very much indeed.
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.
I couldn't agree more.
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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
