Personally I only tested the "patched" version by searching for the
ASCII (decimal) representation of my own password.

In other words, I searched for "mypassword" with a hex editor, rather
than its hexadecimal representation "6d7970617373776f7264"

If what you're saying is that all Google did is change the
cleartext password to its hexadecimal representation then you might be
completely right as I haven't tested this myself.

Anyways, if that's the case, then shame on Google for such a poor
attempt of obfuscation.

11/29/05, 6ackpace <6ackpace (AT) gmail (DOT) comwrote:

Hi,

If i am right Google Talk Beta Messenger cleartext credentials in process
memory still exist on the current version.
googles answer for this issue:
plain char -hex char
>
>
>
6ackpace
11/29/05, Jaroslaw Sajko <sloik (AT) parareal (DOT) netwrote:

pagvac wrote:
Title: Google Talk Beta Messenger cleartext credentials in process
memory
--
Description

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.

This issue would occur regardless of whether the "Save Password"
feature was enabled or not.

The same issue concerns many applications, ie. Gadu-Gadu - another
instant messenger. In my opinion such "vulnerabilities" are not worthy
publishing (for Gadu-Gadu we have not published this kind of software
behaviour) because if you can dump other user process or trick him to
execute any code then reading the password from the process memory is
only one of many things which you can do.

regards,
js

Full-Disclosure - We believe in it.
Charter:

Hosted and sponsored by Secunia - http://secunia.com/
>
>
>

Jaroslaw,

thanks for your post. You're right, the same issue occurs in *many*
applications. However, any vendor that is serious about security should
at least attempt to obfuscate the credentials in the process memory (IMH).

I just published the advisory to let the public know that Google "fixed" this
problem, that's all.

However I respect your opinion and appreciate your post.

11/29/05, Jaroslaw Sajko <sloik (AT) parareal (DOT) netwrote:
pagvac wrote:
Title: Google Talk Beta Messenger cleartext credentials in process memory
--
Description

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.

This issue would occur regardless of whether the "Save Password"
feature was enabled or not.

The same issue concerns many applications, ie. Gadu-Gadu - another
instant messenger. In my opinion such "vulnerabilities" are not worthy
publishing (for Gadu-Gadu we have not published this kind of software
behaviour) because if you can dump other user process or trick him to
execute any code then reading the password from the process memory is
only one of many things which you can do.

regards,
js

pagvac wrote in
@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. 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

11/29/05, Dave Korn <davek_throwaway (AT) hotmail (DOT) comwrote:
pagvac wrote in
@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. 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 Ss
(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

Tue, Nov 29, 2005 at 11:57:00AM +0100, Jaroslaw Sajko wrote:
pagvac wrote:
Jaroslaw,

thanks for your post. You're right, the same issue occurs in *many*
applications. However, any vendor that is serious about security will
at least attempt to obfuscate the credentials in memory (IMH).

Thanks for your post too. I think you're right that obfuscation can help
in some cases. Sometimes the plaintext credentials goes to the Microsoft
as the part of the crash report. Then if the cerdentials are obfuscated,
in a correct way, we can prevent Microsoft from collecting our
credentials. To prevent an attacker from reading credentialas from
process memory dump we need more complicated mechanism (the dump
contains all data & code). Therefore cost of implementing the correct
obfuscation might be uncomparable with the risk of the credential lost
in such manner. That's why I think the obfuscation isn't necessary. But
this is of course only my opinion:]

If you want to protect the credentials in memory from dumps that go to
Microsoft, why not use CryptProtectMemory() instead of home-grown
obfuscation? This function encrypts the memory with a key that changes
over reboots, so even if you send a dump to MS, they wouldn't know how
to decrypt it.

Tue, Nov 29, 2005 at 01:11:47PM -0500, Nasko wrote:

If you want to protect the credentials in memory from dumps that go to
Microsoft, why not use CryptProtectMemory() instead of home-grown
obfuscation? This function encrypts the memory with a key that changes
over reboots, so even if you send a dump to MS, they wouldn't know how
to decrypt it.

old people remember the "nsakey micro$oft" fiasco.

_NSAKEY is a variable name discovered in Windows NT 4 Service Pack 5 (which
had been released unstripped of its symbolic debugging data) in August 1999
by Andrew D. Fernandes of Cryptonym Corporation. That variable contained a
1024-bit public key.

The key is still present in all version of Windows, though it has been
renamed "_KEY2."

11/29/05, Andrew Simmons <asimmons (AT) messagelabs (DOT) comwrote:
pagvac wrote:

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.
--
er, not really. Home users, perhaps, but there are a lot more WIndows
machines in corp environments than at home.

Even in corp environments you still see some users running admin
privileges. Yes, I agree, it doesn't happen as often as in home
environments, but it *does* happen.

Anyways, I don't have any statistics so I'm not going to argue this,
but if you talk to any company that offers pentesting services they
will surely tell you that they come across companies that gives admin
privileges to some of their employees in their Windows desktops (I'm
referring to employees that are *not* network administrators). This is
just for convenience so they can install whatever applications they
need.

It'd be interesting to find some online survey on what percentage of
business and home users use admin privileges for daily tasks.

If you look at Windows 2000/XP, it does it wrong from the very
beginning: the user is asked to add a user account from installation.
This account has admin privileges by default. Even worse, at that
point there is another default admin account ("administrator") on the
system, so by the time you're done installing your copy of Windows
there is two admin accounts on your system.

Wouldn't it make more sense that the second user account which is
created during installation has restricted privileges by default?
Maybe Windows XP could add one of those stupid balloons saying
something like "Problem installing an application? Now you can
right-click on the file and click on "run as" to install your software
with admin privileges"

Well, these are just some ideas, of course I'm no authority nor guru,
I'm just a guy who enjoys learning.

\a