On Mon, Feb 27, 2012 at 10:27 PM, Jeffrey Walton <[email protected]> wrote:
> On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri <[email protected]> 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/
