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]
Message-ID: <457f01c919c3$09765bb0$7a46a8c0@cc.w2k.vt.edu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ