bugtraq - RE: Pidgin IM Client Password Disclosure Vulnerability.

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-next>] [day] [month] [year] [list]

Date: Thu, 18 Sep 2008 15:16:18 -0400
From: "Memisyazici, Aras" <arasm@...edu>
To: <bugtraq@...urityfocus.com>
Cc: Siim Põder <siim@...rad-teel.net>
Subject: RE: Pidgin IM Client Password Disclosure Vulnerability.

Siim:

While I agree with your comments, I cannot help but suggest that maybe the method of choice could be 'security through obscurity' whereby they take a hash of the password, with a non-std. hashing mechanism. The idea being that in today's world where there are so many scr1pt-kiddi3 toolz out there allowing the avg. Joe Schmoe the capability of analyzing one's memory processes i.e. Tsearch, memhack etc... It only makes it non-trivial for them to extract the info needed. This way you are making it a tad more annoying and adding another buffer they need to bypass :)

Just a thought,
Aras 'Russ' Memisyazici
Systems Administrator

Virginia Tech
-----Original Message-----
From: Siim Põder <siim@...rad-teel.net>
Sent: Thursday, September 18, 2008 12:58 PM
To: bugtraq@...urityfocus.com <bugtraq@...urityfocus.com>
Subject: Re: Pidgin IM Client Password Disclosure Vulnerability.

Hi.

Aditya K Sood wrote:
> The pidgin client inherits client side password disclosure
> vulnerability. The credentials used to
> connect to the required service i.e. username and password is not
> encrypted properly. The credentials

what do you propose? encrypt the password and store the encryption key
in memory? encrypt the password and the encryption key and store the
encryption key of the encryption key in memory?

if your program needs to use a password for pretty much anything, it
needs to be in.... you guessed it - memory.

a seemingly nice way out is to store the hash of the password in memory
and design the service so that you can log in with hash. but once you
think about it and realise that in that case password =
hash(original_password) you can go straight back to the first paragraph.

> can be extracted in clear text by dumping process memory of the live
> pidgin process when a connection
> is set. The vulnerability allows anyone with access to the client system
> to obtain the username and password.

not anyone. anyone with sufficient permissions. have you tried dumping
the memory of a process owned by another user? basically, you either
need to have access as the user running pidgin, or administrator access.

> Additionally, this vulnerability could also be exploited by fooling the
> user to execute malicious code which
> would dump the memory of the process "pidgin.exe"..

are you kidding?

Siim