RE: Pidgin IM Client Password Disclosure Vulnerability.

[Memisyazici, Aras]

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@p6drad-teel.net>
Sent: Thursday, September 18, 2008 12:58 PM
To: bugtraq@securityfocus.com <bugtraq@securityfocus.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

[John Bailey]

On Thu, Sep 18, 2008 at 03:16:18PM -0400, Memisyazici, Aras wrote:
> 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 andadding another buffer they need to bypass :)
>
> Just a thought,
> Aras 'Russ' Memisyazici
> Systems Administrator
>
> Virginia Tech

Wow, security through obscurity. That's a good practice alright. So
you propose that I and my fellow Pidgin developers implement security
through obscurity, thus giving our users a false sense of security? No
chance. Note also that we store passwords on-disk without any form of
encryption or obfuscation, which has been debated to death on numerous
occasions--so much so, in fact, that we've written an FAQ entry dealing
specifically with this. Additionally, *any* form of encryption that we
were to use would have to be reversible, as storing protocol-specific
hashes is, as Siim pointed out, no better than storing the plain text.
Reversible encryption again makes it completely trivial to decrypt the
passwords (by using our own code against the user), to the point that
it really is no "improvement" at all.

I find it curious that the person disclosing this so-called
vulnerability made no effort to contact us before disclosing, let alone
do any research to find out where the affected area of code is (the code
being complained about here is in libpurple, not Pidgin). We have
enough visible methods of contact that there is no excuse for not
attempting to contact us directly.

John

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjSy6cACgkQBWJH/emdNtslLACbBjxLJRV5vv1JFs5+4fJnihB9
lOYAniMftPtH5iyR6dlr65RfW7s4ijc7
=frMv
-----END PGP SIGNATURE-----

[Steve Shockley]

Memisyazici, Aras wrote:
> 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 :)

Okay, let's pretend you somehow prevent a local Administrator from
reading the password out of memory... I'm already running code, so I
install a key logger, and then crash/exit the process so you have to log
in again. Once the attacker can run code on your system, it's game
over. All you do by storing the password encoded is to make the
attacker read the source to see how to decode it, and then write a k-rad
31337 script to automate it.

[Memisyazici, Aras]

John:

Thank you for your reply.

Indeed, as I tried to explain in my previous reply, my "suggestion" in obscurity as a means of securing things, was not meant as (encryption of encryption) ^ ?, rather building another barrier to make it "harder" for compromise.

IMO, a "real" solution would be to be able to deploy/install Pidgin in a fashion so that:

a) the accounts.xml file's location can be overriden (so that I can re-direct to a network shared TrueCrypt drive over an IPSEC protected pipe in a VLAN'd network :p)
b) to be able to disable the "Save Password" option and ensure it cannot be overridden by the user by default

In an institution where the authentication piece is tied into the universal PIM LDAP, as-is, the usage of your application puts us in awkward position, as it has been deemed against the policies to "store" such authentication information in the open in an easily accessible location.

Per your post on http://developer.pidgin.im/wiki/PlainTextPasswords here, AFAIK there still isn't any plugin that decrypts/encrypts the saved password file either :/

Such position your team is taking, pretty much ties our hands and cripples us on spreading the good word about Pidgin: IMO one of the best chat applications out there!

Anyways, please keep up the good work and I look forward to the development of Pidgin!

Sincerely,

Aras "Russ" Memisyazici
Systems Administrator

Virginia Tech
________________________________

From: John Bailey [mailto:rekkanoryo@rekkanoryo.org]
Sent: Thu 9/18/2008 5:44 PM
To: Memisyazici, Aras
Cc: bugtraq@securityfocus.com; Siim Põder
Subject: Re: Pidgin IM Client Password Disclosure Vulnerability.



On Thu, Sep 18, 2008 at 03:16:18PM -0400, Memisyazici, Aras wrote:
> 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

Wow, security through obscurity. That's a good practice alright. So
you propose that I and my fellow Pidgin developers implement security
through obscurity, thus giving our users a false sense of security? No
chance. Note also that we store passwords on-disk without any form of
encryption or obfuscation, which has been debated to death on numerous
occasions--so much so, in fact, that we've written an FAQ entry dealing
specifically with this. Additionally, *any* form of encryption that we
were to use would have to be reversible, as storing protocol-specific
hashes is, as Siim pointed out, no better than storing the plain text.
Reversible encryption again makes it completely trivial to decrypt the
passwords (by using our own code against the user), to the point that
it really is no "improvement" at all.

I find it curious that the person disclosing this so-called
vulnerability made no effort to contact us before disclosing, let alone
do any research to find out where the affected area of code is (the code
being complained about here is in libpurple, not Pidgin). We have
enough visible methods of contact that there is no excuse for not
attempting to contact us directly.

John

[John Bailey]

Memisyazici, Aras wrote:
> John:
>
> Thank you for your reply.
>
> Indeed, as I tried to explain in my previous reply, my "suggestion" in obscurity as a means of securing things, was not meant as (encryption of encryption) ^ ?, rather building another barrier to make it "harder" for compromise.

Which we can't do, because we need to be able to generate the hash a given
server requires. Some protocols can ask for different types of hashes at
various times, and if we store the password in a non-reversible hash we lose the
ability to use these protocols. Not to mention the fact that it still does
nothing but provide a false sense of security, which we feel is worse than no
security at all.

> IMO, a "real" solution would be to be able to deploy/install Pidgin in a fashion so that:
>
> a) the accounts.xml file's location can be overriden (so that I can re-direct to a network shared TrueCrypt drive over an IPSEC protected pipe in a VLAN'd network :p)

This can already be done--on a Windows system, which this so-called
"vulnerability disclosure" obviously focused solely on, forcing the PURPLEHOME
environment variable to be set by a user's logon script will use the specified
path for not just accounts.xml but all configuration and data files for Pidgin.
The pidgin.exe binary can also be renamed and replaced with a script (or
executable stub) that calls the renamed binary with the -c option to specify a
different location for the configuration directory. We have no intentionof
allowing individual files to be relocated outside the configuration directory
through any measure other than symbolic links.

> b) to be able to disable the "Save Password" option and ensure it cannot be overridden by the user by default

I'm sure we'd accept a patch that allowed this in a portable fashion--i.e. one
not tied to any specific OS. As it is, however, I seriously doubt any ofus
care to implement this ourselves.

> In an institution where the authentication piece is tied into the universal PIM LDAP, as-is, the usage of your application puts us in awkward position, as it has been deemed against the policies to "store" such authentication information in the open in an easily accessible location.
>
> Per your post on http://developer.pidgin.im/wiki/PlainTextPasswords here, AFAIK there still isn't any plugin that decrypts/encrypts the saved password file either :/

There is no intent to ever provide encryption on the file itself or the
passwords stored in it (again, the false sense of security). If your file
system's permissions model is insufficient to protect the file, find a better
filesystem. If your understanding of the file system's permissions modelis
insufficient, learn about it. NTFS and all common UNIX file systems provide
adequate protection for the file; arguments about the disk falling into the
wrong hands don't really carry any weight, because if the disk is lost you're
screwed whether there's a hash or encryption or anything else. If your disk is
lost, you have much bigger problems than lost IM passwords. However, the
ability to use external keyrings for more "secure" storage of passwords has been
the focus of a Google Summer of Code project this year.

> Such position your team is taking, pretty much ties our hands and cripples us on spreading the good word about Pidgin: IMO one of the best chat applications out there!

If our position on any matter costs us a few users, we're willing to livewith
that. Being the most popular IM application has never been our goal--ourgoal
is to make Pidgin the best client it can be for ourselves and those who think
and act like we do.

John


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjTxgEACgkQBWJH/emdNtu+gwCfXd1a4rIV7gg9iEqAKMAsw8El
V88AoKVk/EbV0NM320xth6oNKwo/ifPL
=jNxT
-----END PGP SIGNATURE-----