Re: [Full-disclosure] pidgin OTR information leakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jann Horn wrote: > 2012/2/25 Dimitris Glynos : >> 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-
Re: [Full-disclosure] pidgin OTR information leakage
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 MIT Laboratory for Nuclear Science
Re: [Full-disclosure] pidgin OTR information leakage
On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri 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
Re: [Full-disclosure] pidgin OTR information leakage
On 02/27/2012 11:23 PM, devn...@vonage.com 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
Re: [Full-disclosure] pidgin OTR information leakage
On 02/28/2012 12:14 AM, Dimitris Glynos wrote: > On 02/27/2012 11:23 PM, devn...@vonage.com 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