otron
otron copied to clipboard
osnr
Dependence on Facebook DOM
Please be careful — this project's dependence on the Facebook DOM causes it to have security that is very easily undoable by Facebook. I would not recommend injecting crypto into the Facebook DOM, this is an unsafe design.
We inject an iframe on a different origin (extension) specifically to avoid this problem. Please see the threat model page. On Jan 28, 2014 2:44 PM, "Nadim Kobeissi" [email protected] wrote:
Please be careful -- this project's dependence on the Facebook DOM causes it to have security that is very easily undoable by Facebook. I would not recommend injecting crypto into the Facebook DOM, this is an unsafe design.
Reply to this email directly or view it on GitHubhttps://github.com/osnr/otron/issues/21 .
Surely all Facebook has to do is rename a function to get around this?
Yeah, I acknowledge the brittleness problem. But then we're talking about denial of service, not security leaks. The user can see that encryption isn't on (tokens prevent a phishing of encrypted state).
If it's a global change, then it becomes a cat and mouse game. Thinking about things like DOM observation to step above this and also generalize to Gmail, etc. We could also use Jabber. If it's targeted, well -- targeted DoS is a problem for any system.
I think the overall calculation makes this extension a net plus, especially if we can make encryption a transparent default. On Jan 28, 2014 2:49 PM, "Nadim Kobeissi" [email protected] wrote:
Surely all Facebook has to do is rename a function to get around this?
Reply to this email directly or view it on GitHubhttps://github.com/osnr/otron/issues/21#issuecomment-33536670 .
It could also be possible to selectively disable OTR based on different users being served different pages. If a warrant is served for a particular user, they are served the alternate function which routes around the plugin in a way that makes the messenger interface not detectable by it.
Sure, that's what I mean by "targeted DoS".
The key point is that the user should never think she's chatting securely when her chat is compromised. If she can't chat securely at all in some case, because Facebook has served a weird page, that's bad, but it's not a security compromise. We could even think about ways to tip the user off that they've been subject to targeted surveillance this way.
As it stands, it's less of a targeted DoS and more of a targeted compromise of confidentiality. How can you implement, with high assurance, the detection of Facebook serving a "weird page" that can pretty much disable or modify the operation of your entire JavaScript infrastructure?
Chrome extension userscripts are sandboxed off from the page's JavaScript. Only the DOM is shared in common between Facebook and us, and all private information is displayed to the user through an iframe that Facebook can't look into. So Facebook can break the hooks we use to put stuff on the screen and send/receive messages, but they can't change the internal operation of the extension.
Facebook can not only break the hooks, they can do so while still misleading the extension into believing that the hooks are actually working.
Yeah, if you're not familiar with the Chrome extension script injection model, I can see how this might be confusing. See here: http://developer.chrome.com/extensions/content_scripts.html
I've been developing Chrome extensions for three years. I think you don't understand the danger I'm trying to outline here.
Even though the internal state of the Chrome extension may be (arguably) off-limits, the hooks into the Facebook page aren't. Facebook can exploit this to pacify the Chrome extension into thinking everything is alright while in fact disabling OTR.
What do you mean by "disabling OTR"?
Of course, Facebook can cut off all our hooks and remove us from the page, and force the user to use plaintext, maybe keep the icon on "lock", and we can't detect that from within the extension (well, we might be able to, but it would be a cat-and-mouse thing). But then it will be obvious to the user that they're not encrypted anymore, because FB can't replicate our interface cues (security tokens). They'll type in a chat message and the colors and icons will be all wrong. They'll receive a chat message and it won't be watermarked properly.
Facebook may not be able to replicate your interface cues, but they can trick your extension into replicating them even while nipping out its encryption functions.
Give me an example? If you're right, this is certainly a serious problem, but I still don't see it. Facebook has one means of input into the extension (besides DOM overlays / modification): the message receipt hook. The hook surface is quite small, and we could replace it entirely with Jabber other than the one iframe injection and button injection into the DOM. We display the security cues underneath decrypted messages and underneath the identity bar.
If Facebook wants a cue underneath a received message they faked, they need to convince the extension that we got an valid encrypted message at the same time.
If Facebook wants a cue that the user's typing in the right place, they need to send keypress and focus events to the input box in the iframe.
I don't see either of these as possible, but I may be missing something.
If I have time I'll create a testbed DOM page which activates the extension by making it detect a supposed Facebook chat interface. Then I'll demonstrate how by modifying the testbed DOM, you can make the extension behave unsafely.
I look forward to seeing it. If you have any further details about the attack you envision right now, I'm happy to look into it myself, but I don't have enough to go on right now. I don't see enough attack surface, as I said earlier.
I'm sorry if this conversation has gotten heated, by the way! I do appreciate the help, and I don't want to pursue OTRon further (Chrome store, etc) if I'm not comfortable with its soundness; that's why I reached out. Let me know about the attack when you get the chance.