Re: pidgin OTR information leakage

[Ferenc Kovacs <tyra3l () gmail com>]

On Mon, Feb 27, 2012 at 10:27 PM, Jeffrey Walton <noloader () gmail com> wrote:

> On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri <ratinox () mit edu> 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

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