RE: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-19 Thread Quark IT - Hilton Travis
Hi Aditya,

> -Original Message-
> From: Aditya K Sood [mailto:[EMAIL PROTECTED]
> Sent: Friday, 19 September 2008 1:04 AM
> 
> Quark IT - Hilton Travis wrote:
> > The latest version of Pidgin - 2.5.1 - was released on 2008-08-31.
> > This must be an ancient version you've got here!
> >
> > --
> >
> > http://blog.hiltontravis.com/
> >
> > Regards,
> >
> > Hilton Travis   Phone: +61 (0)7 3105 9101
> > (Brisbane, Australia)   Phone: +61 (0)419 792 394
> > Manager, Quark IT   http://www.quarkit.com.au
> >  Quark Grouphttp://www.quarkgroup.com.au
> >
> >  Microsoft SBSC PAL (Australia) http://www.sbscpal.com/
> >
> > War doesn't determine who is right.  War determines who is left.
> >
> > This document and any attachments are for the intended recipient
> >   only.  It may contain confidential, privileged or copyright
> >  material which must not be disclosed or distributed.
> >
> > Quark Group Pty. Ltd.
> >   T/A Quark Automation, Quark AudioVisual, Quark IT
> >
> >
> >> -----Original Message-----
> >> From: Aditya K Sood [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, 17 September 2008 10:41 PM
> >> To: bugtraq@securityfocus.com
> >> Subject: Pidgin IM Client Password Disclosure Vulnerability.
> >>
> >> Pidgin IM Client Password Disclosure Vulnerability.
> >>
> >> *Version Affected:*
> >> 0.7.10 Unicode / Previous version can be affected.
> >>
> >> *Release Date:*
> >> 11 September 2008
> >>
> >> *About:*
> >> Pidgin is a graphical modular messaging client based on libpurple
> >>
> > which
> >
> >> is capable
> >> of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC,
SIP/SIMPLE,
> >> Novell GroupWise,
> >> Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all
at
> >> once. It is written using GTK+.
> >>
> >> *Description:*
> >> 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
> >> 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.
> >> 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"..
> >>
> >> *Proof of Concept:*
> >> http://evilfingers.com/advisory/pidgin_password_disc_vuln.pdf
> >> http://secniche/advisory/pidgin_vul.pdf
> >> * *
> >> *Links: *
> >> http://secniche.org/advisory.html
> >> http://evilfingers.com/advisory/index.php
> >> *
> >> Credit:*
> >> Aditya K Sood
> >>
> >> *Disclaimer*
> >> The information in the advisory is believed to be accurate at the
> time
> >> of publishing based on currently
> >> available information. Use of the information constitutes
acceptance
> >> for
> >> use in an AS IS condition. There is
> >> no representation or warranties, either express or implied by or
> with
> >> respect to anything in this document,
> >> and shall not be liable for a ny implied warranties of
> merchantability
> >> or fitness for a particular purpose or for
> >> any indirect special or consequential damages.
> >>
> >
> >
> Hi
> 
> I have tested the 2.5.1 version. The template was wrongly constructed
> in
> version number.
> 
> Any ways I have changed the things.
> 
> Thanks for mentioning the construct.
> 
> I appreciate that.
> 
> Regards

This is also nothing new.  Have a look at
http://www.elcomsoft.com/aimpr.html which has been around for ages.  :)

--

http://blog.hiltontravis.com/

Regards,

Hilton Travis   Phone: +61 (0)7 3105 9101
(Brisbane, Australia)   Phone: +61 (0)419 792 394
Manager, Quark IT   http://www.quarkit.com.au
 Quark Grouphttp://www.quarkgroup.com.au

 Microsoft SBSC PAL (Australia) http://www.sbscpal.com/

War doesn't determine who is right.  War determines who is left.

This document and any attachments are for the intended recipient 
  only.  It may contain confidential, privileged or copyright 
 material which must not be disclosed or distributed.

Quark Group Pty. Ltd.
  T/A Quark Automation, Quark AudioVisual, Quark IT



Re: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-19 Thread 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 intention of
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 of us
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 model is
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 live with
that.  Being the most popular IM application has never been our goal--our goal
is to make Pidgin the best client it can be for ourselves and those who think
and act like we do.

John



signature.asc
Description: OpenPGP digital signature


RE: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-19 Thread 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:[EMAIL PROTECTED]
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




Re: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-19 Thread 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.


Re: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-19 Thread 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 
> 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


signature.asc
Description: Digital signature


RE: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-18 Thread 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 <[EMAIL PROTECTED]>
Sent: Thursday, September 18, 2008 12:58 PM
To: 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


Re: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-18 Thread Siim Põder
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


RE: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-18 Thread Quark IT - Hilton Travis
The latest version of Pidgin - 2.5.1 - was released on 2008-08-31.  This
must be an ancient version you've got here!

--

http://blog.hiltontravis.com/

Regards,

Hilton Travis   Phone: +61 (0)7 3105 9101
(Brisbane, Australia)   Phone: +61 (0)419 792 394
Manager, Quark IT   http://www.quarkit.com.au
 Quark Grouphttp://www.quarkgroup.com.au

 Microsoft SBSC PAL (Australia) http://www.sbscpal.com/

War doesn't determine who is right.  War determines who is left.

This document and any attachments are for the intended recipient 
  only.  It may contain confidential, privileged or copyright 
 material which must not be disclosed or distributed.

Quark Group Pty. Ltd.
  T/A Quark Automation, Quark AudioVisual, Quark IT

> -Original Message-
> From: Aditya K Sood [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 17 September 2008 10:41 PM
> To: bugtraq@securityfocus.com
> Subject: Pidgin IM Client Password Disclosure Vulnerability.
> 
> Pidgin IM Client Password Disclosure Vulnerability.
> 
> *Version Affected:*
> 0.7.10 Unicode / Previous version can be affected.
> 
> *Release Date:*
> 11 September 2008
> 
> *About:*
> Pidgin is a graphical modular messaging client based on libpurple
which
> is capable
> of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE,
> Novell GroupWise,
> Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at
> once. It is written using GTK+.
> 
> *Description:*
> 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
> 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.
> 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"..
> 
> *Proof of Concept:*
> http://evilfingers.com/advisory/pidgin_password_disc_vuln.pdf
> http://secniche/advisory/pidgin_vul.pdf
> * *
> *Links: *
> http://secniche.org/advisory.html
> http://evilfingers.com/advisory/index.php
> *
> Credit:*
> Aditya K Sood
> 
> *Disclaimer*
> The information in the advisory is believed to be accurate at the time
> of publishing based on currently
> available information. Use of the information constitutes acceptance
> for
> use in an AS IS condition. There is
> no representation or warranties, either express or implied by or with
> respect to anything in this document,
> and shall not be liable for a ny implied warranties of merchantability
> or fitness for a particular purpose or for
> any indirect special or consequential damages.


Re: Pidgin IM Client Password Disclosure Vulnerability.

2008-09-18 Thread Aditya K Sood

Quark IT - Hilton Travis wrote:

The latest version of Pidgin - 2.5.1 - was released on 2008-08-31.  This
must be an ancient version you've got here!

--

http://blog.hiltontravis.com/

Regards,

Hilton Travis   Phone: +61 (0)7 3105 9101
(Brisbane, Australia)   Phone: +61 (0)419 792 394
Manager, Quark IT   http://www.quarkit.com.au
 Quark Grouphttp://www.quarkgroup.com.au

 Microsoft SBSC PAL (Australia) http://www.sbscpal.com/

War doesn't determine who is right.  War determines who is left.

This document and any attachments are for the intended recipient 
  only.  It may contain confidential, privileged or copyright 
 material which must not be disclosed or distributed.


Quark Group Pty. Ltd.
  T/A Quark Automation, Quark AudioVisual, Quark IT

  

-Original Message-
From: Aditya K Sood [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 17 September 2008 10:41 PM
To: bugtraq@securityfocus.com
Subject: Pidgin IM Client Password Disclosure Vulnerability.

Pidgin IM Client Password Disclosure Vulnerability.

*Version Affected:*
0.7.10 Unicode / Previous version can be affected.

*Release Date:*
11 September 2008

*About:*
Pidgin is a graphical modular messaging client based on libpurple


which
  

is capable
of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE,
Novell GroupWise,
Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at
once. It is written using GTK+.

*Description:*
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
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.
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"..

*Proof of Concept:*
http://evilfingers.com/advisory/pidgin_password_disc_vuln.pdf
http://secniche/advisory/pidgin_vul.pdf
* *
*Links: *
http://secniche.org/advisory.html
http://evilfingers.com/advisory/index.php
*
Credit:*
Aditya K Sood

*Disclaimer*
The information in the advisory is believed to be accurate at the time
of publishing based on currently
available information. Use of the information constitutes acceptance
for
use in an AS IS condition. There is
no representation or warranties, either express or implied by or with
respect to anything in this document,
and shall not be liable for a ny implied warranties of merchantability
or fitness for a particular purpose or for
any indirect special or consequential damages.



  

Hi

I have tested the 2.5.1 version. The template was wrongly constructed in 
version number.


Any ways I have changed the things.

Thanks for mentioning the construct.

I appreciate that.

Regards



Pidgin IM Client Password Disclosure Vulnerability.

2008-09-17 Thread Aditya K Sood

Pidgin IM Client Password Disclosure Vulnerability.

*Version Affected:*
0.7.10 Unicode / Previous version can be affected.

*Release Date:*
11 September 2008

*About:*
Pidgin is a graphical modular messaging client based on libpurple which 
is capable
of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, 
Novell GroupWise,
Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at 
once. It is written using GTK+.


*Description:*
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
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.
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"..

*Proof of Concept:*
http://evilfingers.com/advisory/pidgin_password_disc_vuln.pdf
http://secniche/advisory/pidgin_vul.pdf
* *
*Links: *
http://secniche.org/advisory.html
http://evilfingers.com/advisory/index.php
*
Credit:*
Aditya K Sood

*Disclaimer*
The information in the advisory is believed to be accurate at the time 
of publishing based on currently
available information. Use of the information constitutes acceptance for 
use in an AS IS condition. There is
no representation or warranties, either express or implied by or with 
respect to anything in this document,
and shall not be liable for a ny implied warranties of merchantability 
or fitness for a particular purpose or for

any indirect special or consequential damages.