On Tue, 2011-10-11 at 13:37 -0700, Mike Perry wrote:
> Thus spake Moritz Bartl (moritz@xxxxxxxxxxxxxx):
>
> > On 11.10.2011 04:07, Mike Perry wrote:
> > >> At the moment, I cannot think of any attack vectors once you combine it
> > >> with enabled Torbutton (or a stripped down Tor Browser) where active
> > >> scripting/access to the DOM is disabled completely.
> > > Actually, these attacks are generally prohibited by strong isolation
> > > between the content script and the XUL script. In XUL, you can read
> > > the ciphertext, extract it, decrypt it, and display it in a protected
> > > XUL window without introducing risk, IF all steps are done properly.
> >
> > I was thinking of the obvious interaction a user expects for encryption
> > of plaintext data: I type data into a web form, when I am done I execute
> > the encrypt command.
> > I don't see how you can isolate web forms in the DOM in a way that it
> > cannot be read in between typing and encrypting the data.
>
> Yes, good to clarify. I was assuming that all encryption and
> decryption UI would be 100% independent of the normal content window,
> aside from perhaps a context menu (though even that is prone to
> deception issues and clickjacking).
>
> The UI should not provide a way to encrypt text that has already been
> typed into a form. Even non-malicious JS can screw you for that user
> model. For example, Gmail will save plaintext drafts of your email
> periodically "just in case", which will defeat the purpose of the
> addon entirely.
>
> The UI should open an alternate XUL window for user input using a
> context menu or toolbar button, and should instruct users not to type
> sensitive plaintext into existing form boxes prior to use of the XUL
> window.
>
> Lots of tough UI issues to solve on the encryption side, it seems.
> Perhaps almost as tricky as safely handling the potential hostile
> input and safely displaying the output for the decryption side.
In theory, it should be possible to prevent JavaScript from reading the
content of decrypted or not-yet-encrypted messages. There are a few
barriers to this approach, but they should be surmountable:
- The user would need to indicate that they were going to
encrypt the contents of a text field *before* they did so.
- JavaScript on the page mustn't be able to interact with the
data in any way. This would, for example, prevent things like
editing buttons, GMail's auto-saving, and auto-resizing of text
areas.
- When decrypting data, the size of the text in the decrypted
area will change. Since JavaScript can query positions and such,
it may
be difficult to prevent the length of the message from leaking.
Of course, it might be possible to do everything in a new window, which
would prevent all of these things, but that would be detrimental to the
user experience. Also, does anyone know if Firefox even has the
necessary APIs to prevent malicious pages from doing these things?
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk