Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Full Disclosure: Full-Disclosure

pidgin OTR information leakage

 

 

Full Disclosure full-disclosure RSS feed   Index | Next | Previous | View Threaded


dimitris at census-labs

Feb 25, 2012, 8:31 AM

Post #1 of 9 (570 views)
Permalink
pidgin OTR information leakage

Pidgin transmits OTR (off-the-record) conversations over DBUS in
plaintext. This makes it possible for attackers that have gained
user-level access on a host, to listen in on private conversations
associated with the victim account.

Pidgin is a popular Instant Messenger application that runs on a wide
variety of platforms including Windows and Linux. The pidgin-otr plugin
enables users to communicate securely over any Instant Messenger network
using the “Off-the-record” messaging protocol.

If Pidgin is compiled with DBUS support and there is a DBUS session
daemon running on the system, then all messages that are typed into
Pidgin and messages received through Pidgin are broadcasted on DBUS. The
reasoning behind this is to allow for third party applications, such as
desktop widgets to process these messages (e.g. create an animation when
a message arrives). However, among the messages transmitted over DBUS
one also finds OTR conversations in plaintext form. This is a security
problem, as the private OTR messages may leak to other (unrelated)
processes that are executing with the Pidgin user’s rights.

A more detailed advisory and proof-of-concept script can be found here:
http://census-labs.com/news/2012/02/25/pidgin-otr-info-leak/

The Pidgin and pidgin-otr development teams have been contacted about
this issue and we anticipate a fix in a coordinated future release.

The Common Vulnerabilities and Exposures (CVE) project has
assigned candidate name CVE-2012-1257 to this issue.

Disclosure Timeline
-------------------
Vendor Contact(s): December 20th, 2011
CVE assignment: February 21st, 2012
Public Disclosure: February 25th, 2012

Kind regards,

Dimitris Glynos
--
http://census-labs.com -- IT security research, development and services

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


dimitris at census

Feb 26, 2012, 3:44 AM

Post #2 of 9 (559 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On 02/25/2012 06:31 PM, Dimitris Glynos wrote:
> Pidgin transmits OTR (off-the-record) conversations over DBUS in
> plaintext. This makes it possible for attackers that have gained
> user-level access on a host, to listen in on private conversations
> associated with the victim account.

As noted by Peter Lawler this should really be referenced as
a libpurple issue and not a pidgin one. You may find the updated
advisory here:

http://census-labs.com/news/2012/02/25/libpurple-otr-info-leak/

(old URL is valid too)

Best regards,

Dimitris Glynos
--
http://census-labs.com -- IT security research, development and services

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


jannhorn at googlemail

Feb 27, 2012, 9:27 AM

Post #3 of 9 (537 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

2012/2/25 Dimitris Glynos <dimitris [at] census-labs>:
> Pidgin transmits OTR (off-the-record) conversations over DBUS in
> plaintext. This makes it possible for attackers that have gained
> user-level access on a host, to listen in on private conversations
> associated with the victim account.

Basically, you're saying that if I have the rights of a user on a
machine, I can access the private conversations of that user? Ooooh
no. Well, I can also copy his keyfiles, no? And I can alter his
settings. And spawn fake "Update didn't work, please enter root
password to proceed" windows. I could alter his ~/.bashrc so that
whenever he launches "sudo" or "su", a script is launched instead that
grabs his password. So, please, what's the point?

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


antisnatchor at gmail

Feb 27, 2012, 11:37 AM

Post #4 of 9 (539 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jann Horn wrote:
> 2012/2/25 Dimitris Glynos <dimitris [at] census-labs>:
>> Pidgin transmits OTR (off-the-record) conversations over DBUS in
>> plaintext. This makes it possible for attackers that have gained
>> user-level access on a host, to listen in on private conversations
>> associated with the victim account.
>
> Basically, you're saying that if I have the rights of a user on a
> machine, I can access the private conversations of that user? Ooooh
> no. Well, I can also copy his keyfiles, no? And I can alter his
> settings. And spawn fake "Update didn't work, please enter root
> password to proceed" windows. I could alter his ~/.bashrc so that
> whenever he launches "sudo" or "su", a script is launched instead
> that grabs his password. So, please, what's the point?

I think you didn't understood the content of the advisory.
If there are 10 non-root users in an Ubuntu machine for example,
if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10
can see what user 1 pidgin conversation.

"Simple" as that, without impersonating user 1 or knowing his password.

Cheers
antisnatchor

>
> _______________________________________________ Full-Disclosure - We
> believe in it. Charter:
> http://lists.grok.org.uk/full-disclosure-charter.html Hosted and
> sponsored by Secunia - http://secunia.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPS9tfAAoJEBgl8Z+oSxe4fv8IAIHrER/TssgDxUmQrpcs11Ud
eYdxLG897aa7plBwi8bABSVR/0moO4cH0w3dvcgIYJ1kSlxiy6NLqlGi9SF6biAx
Yw4uDDeaQggO9CMS8FX/Dn8JNhZUxQ47C0M4hydd8Irg5FPPUBRDcXkcH5MjI35v
GcbSx2MEN5YrSvn4C6z2M3MJcuyhROlWfsa68cBc3EVIe4CjWTK1NLxCidXLrn8V
aXtGOpnrXZPoJeNjhCQGvhnAUMdn2W5PQjF24f6hzqb8vHkF7Y0ZunD9IxoWhnMU
sNGCcUNAEEDXfGUV6LtkwZOP1l6W7bZTRNqT7C8Jsp/K4Pfbit+ALXIhIlQZCds=
=zebT
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


ratinox at MIT

Feb 27, 2012, 12:21 PM

Post #5 of 9 (532 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On Feb 27, 2012, at 2:37 PM, Michele Orru wrote:
> I think you didn't understood the content of the advisory.
> If there are 10 non-root users in an Ubuntu machine for example,
> if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10
> can see what user 1 pidgin conversation.


This is not what the OP or CVE describe:

>> plaintext. This makes it possible for attackers that have gained
>> user-level access on a host, to listen in on private conversations
>> associated with the victim account.

Which I read as: if I compromise user1's account then I can snoop user1's DBUS sessions. It says nothing about me being able to snoop user2's sessions. The leading phrase about attackers gaining user-level access implies that legitimate users on a system are not a relevant issue.

I believe that clarification is in order.

--
Rich Pieri <ratinox [at] MIT>
MIT Laboratory for Nuclear Science


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


noloader at gmail

Feb 27, 2012, 1:27 PM

Post #6 of 9 (537 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri <ratinox [at] mit> wrote:
> On Feb 27, 2012, at 2:37 PM, Michele Orru wrote:
>> I think you didn't understood the content of the advisory.
>> If there are 10 non-root users in an Ubuntu machine for example,
>> if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10
>> can see what user 1 pidgin conversation.
>
>
> This is not what the OP or CVE describe:
>
>>> plaintext. This makes it possible for attackers that have gained
>>> user-level access on a host, to listen in on private conversations
>>> associated with the victim account.
>
> Which I read as: if I compromise user1's account then I can snoop user1's DBUS sessions.  It says nothing about me being able to snoop user2's sessions.  The leading phrase about attackers gaining user-level access implies that legitimate users on a system are not a relevant issue.
>
I tend to agree with you, and question if that is in fact true (it may
well be, my apologies in advance). DBUS is on my list of things to
probe, prod, and attatck due to data sharing.

But I'd be really surprised if data was available across distinct user
sessions. Unix/Linux are usually very good a separating processes and
sessions so that data does not comingle.

Jeff

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


dimitris at census-labs

Feb 27, 2012, 2:14 PM

Post #7 of 9 (530 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On 02/27/2012 11:23 PM, devnull [at] vonage wrote:
>
> I believe that clarification is in order.

Indeed it is. The original post mentions a same-user attack
vector which is very misleading as to what the real problem here is.

And it boils down to this:

Once a process sends private info over DBUS there is no way
to control where this ends up (which apps are the qualified receivers)
or what the receivers do with it. So, if for example the user
selects not to log OTR plaintext (so that this sensitive information
doesn't touch the hard drive) another application on the other end
of DBUS might choose to do something different (and not by malicious
intent). There is no way to enforce the same security policy on the
sender and the receivers.

How this could be exploited by attackers or what forensic evidence
DBUS snooping leaves are of much less importance than the above
privacy issue.

There is a very good discussion on the pidgin ticket page:
http://developer.pidgin.im/ticket/14830

Also, I've made some updates to our post, to make it clearer
as to what this issue is about:

http://census-labs.com/news/2012/02/25/libpurple-otr-info-leak/

If there are still questions, I'll be happy to answer them.

Hope this clarifies things a bit,

Dimitris

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


tyra3l at gmail

Feb 27, 2012, 3:35 PM

Post #8 of 9 (531 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On Mon, Feb 27, 2012 at 10:27 PM, Jeffrey Walton <noloader [at] gmail> wrote:

> On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri <ratinox [at] mit> wrote:
> > On Feb 27, 2012, at 2:37 PM, Michele Orru wrote:
> >> I think you didn't understood the content of the advisory.
> >> If there are 10 non-root users in an Ubuntu machine for example,
> >> if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10
> >> can see what user 1 pidgin conversation.
> >
> >
> > This is not what the OP or CVE describe:
> >
> >>> plaintext. This makes it possible for attackers that have gained
> >>> user-level access on a host, to listen in on private conversations
> >>> associated with the victim account.
> >
> > Which I read as: if I compromise user1's account then I can snoop
> user1's DBUS sessions. It says nothing about me being able to snoop
> user2's sessions. The leading phrase about attackers gaining user-level
> access implies that legitimate users on a system are not a relevant issue.
> >
> I tend to agree with you, and question if that is in fact true (it may
> well be, my apologies in advance). DBUS is on my list of things to
> probe, prod, and attatck due to data sharing.
>
> But I'd be really surprised if data was available across distinct user
> sessions. Unix/Linux are usually very good a separating processes and
> sessions so that data does not comingle.
>
> Jeff
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Exploitation Notes For the purpose of explaining the exploitation impact of
this bug we will focus on a popular libpurple-based application, Pidgin.

To snoop in on a Pidgin user’s conversation a remote attacker would need to
connect to the DBUS daemon that is responsible for the user’s session.
There are at least two ways to achieve this.

The first one is to exploit an application that runs within the same
desktop session as Pidgin. This application would have inherited the
necessary DBUS_SESSION_BUS_ADDRESS environmental variable and will thus be
able to connect to the DBUS daemon over a unix socket without a problem.

The second way is to compromise the user’s account in some way and steal
the DBUS_SESSION_BUS_ADDRESS value. There are multiple ways of acquiring
the value for this variable, one of them being through
/proc/<pid>/environ(which is accessible to processes of the same
owner), and another being
through a file in ~/.dbus/session-bus/. Using this value, the attacker will
now be able to connect to DBUS with applications that are not part of the
desktop session.

Please note that the above methods do not require any control over the
Pidgin process (ptrace or other).


so you either need to able to dump the environment variable from a process
run by the victim, or read files which AFAIK only the victim(and root ofc)
has access to.
did I miss anything?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu


dimitris at census-labs

Feb 27, 2012, 11:26 PM

Post #9 of 9 (532 views)
Permalink
Re: pidgin OTR information leakage [In reply to]

On 02/28/2012 12:14 AM, Dimitris Glynos wrote:
> On 02/27/2012 11:23 PM, devnull [at] vonage wrote:
>>
>> I believe that clarification is in order.
>
> Indeed it is. The original post mentions a same-user attack
> vector which is very misleading as to what the real problem here is.
>
> And it boils down to this:
>
> Once a process sends private info over DBUS there is no way
> to control where this ends up (which apps are the qualified receivers)
> or what the receivers do with it.

This should be:

Once a process *broadcasts* private info over DBUS there is no way
to control where this ends up (which apps are the qualified receivers)
or what the receivers do with it.

> So, if for example the user
> selects not to log OTR plaintext (so that this sensitive information
> doesn't touch the hard drive) another application on the other end
> of DBUS might choose to do something different (and not by malicious
> intent). There is no way to enforce the same security policy on the
> sender and the receivers.
>
> How this could be exploited by attackers or what forensic evidence
> DBUS snooping leaves are of much less importance than the above
> privacy issue.
>
> There is a very good discussion on the pidgin ticket page:
> http://developer.pidgin.im/ticket/14830
>
> Also, I've made some updates to our post, to make it clearer
> as to what this issue is about:
>
> http://census-labs.com/news/2012/02/25/libpurple-otr-info-leak/
>
> If there are still questions, I'll be happy to answer them.
>
> Hope this clarifies things a bit,
>
> Dimitris

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Full Disclosure full-disclosure RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.