Date: Tue Nov 29 16:00:21 2005
From: unknown.pentester at gmail.com (pagvac)
Subject: Re: Google Talk cleartext credentials in
	processmemory

On 11/29/05, Dave Korn <davek_throwaway@...mail.com> wrote:
> 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.

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/
>

Powered by blists - more mailing lists