Short version: FireGPG has menu options for directly doing crypto operations (verify, sign, encrypt, decrypt) on website content. Content JavaScript can easily steal plaintext before encryption or after decryption, and forge signatures etc.
Long version: See attached file.
The fix is simple: we remove all crypto related operations from the
FireGPG menu and force users to do them in the (safe) FireGPG Text
Editor instead. We also disable inline PGP block detection since that
essentially enables the same things (although FireGPG apparently has
some protections against it -- let's stay on the safe side and encourage
usage of the FireGPG Text Editor for everything).
The fix is available over git via:
git clone git://git.immerda.ch/tails/firegpg.git
The relevant commits are:
6c9ea7f Remove irrelewant "Check for PGP blocks in pages" option.
0d1a8aa Fore disable inline PGP block detection.
c4e6d90 Remove irrelevant "Always display...results in a new window"
option.
0cbf55a Remove all crypto-related menu items.
(the "Fore" above should obviously be "Force"...)
Please review them :)
Cheers!
FireGPG [1] is a Firefox addon that allows users to easily perform cryptographic actions on the contents of HTML pages, e.g. to verify signatures appearing as HTML text, or encrypt texts written inside HTML text boxes (i.e. <textarea>). Webmail interfaces commonly use text boxes for email composition, so FireGPG is a natural fit for this use case: the user writes his or her email plaintext in the text box, selects the plaintext and uses one of the "Encrypt" or "Sign and encrypt" actions available from the FireGPG menu to transform the selection to its encrypted counterpart. The FireGPG design incorrectly assumes that this is safe, but it is not, since JavaScript running on the page can still control and observe much of what is happening on the page. For instance, a simple script can set up a timer that silently submits the contents of the text box back to the server every second, thereby leaking the plaintext as it is written, effectively bypassing any subsequent encryption. In fact, many non-malicious webmail services do just that at longer intervals, to save a draft of a message in case the user's browser crashes. The only way that a user can block this type of attack is by completely disabling JavaScript, which is often not desirable. In any case, FireGPG currently does nothing to make users aware of this issue. To the contrary, by making encryption commands easily accessible in the FireGPG context menu, it actively promotes this insecure usage. The situation is exactly the same if a user decrypts an OpenPGP block inside a text box: the OpenPGP block is replaced with the plaintext within the text box, so the same script can leak the plaintext when the timer fires less than a second later. Luckily, webmail systems rarely present messages in text boxes (although 'pastebins' often do). It is more common for received email to be displayed as HTML text, and when the user decrypts it, FireGPG will display the plaintext in a separate window that is safely out of reach of JavaScript. FireGPG has an option [2] that forces this behaviour when decrypting OpenPGP blocks in text boxes as well, but it is disabled by default. This option, however, does not in any way prevent leaking of plaintext while the user is writing it as described in the previous paragraph. FireGPG also has three commands to sign (but not encrypt) messages: "Sign", "Wrapped sign" and "Clearsign". Simple JavaScript can replace the contents of the text box when the user selects it, so if the user does not re-read the text after selecting one of the 'sign' commands, the attacker will be able to obtain the user's signature on an arbitrary message. Enabling option [2] does not prevent this attack; only user acuity *may* be able to detect and block it. It should be clear that the current FireGPG design of performing cryptographic actions on the contents of text boxes is fundamentally flawed and unsecurable. FireGPG's current design and interface is training users to act as if the contents of text boxes are private until they are explicitly submitted by the user (e.g. by pressing a "Submit"/"Send" button). Hence: 1. It is critical that all actions related to encryption and signing be removed from the FireGPG menu. The only way to perform these actions should be through the FireGPG Text editor, which is located in a separate window and thus safely out of the reach of content JavaScript. The FireGPG Text editor is already available through the FireGPG menu and makes all actions easily accessible. 2. FireGPG should explicitly state that the FireGPG Text editor is the only safe place to write plaintext that are to be encrypted and/or signed, or to decrypt messages unless [2] is enabled. Hopefully this will save users that have been misled by FireGPG for years from risking their data again, and make them understand why this new, less convenient, mode of operation is necessary. Otherwise, they may continue writing their plaintext in JavaScript-accessible text boxes, and then copy-and-paste it into the FireGPG Text editor just to encrypt it, instead of writing it there from the start. 3. Option [2] should be removed -- its behaviour should be forcibly enabled instead. 4. The "Verify" command should display the contents of the signed message in the FireGPG Text editor. Otherwise, it may be possible to present to the user a different message from that seen by FireGPG. After these changes, the only remaining actions in the FireGPG menu will be "Decrypt" and "Verify". "Decrypt" is made safe by change 3, and "Verify" is made safe by change 4. It may still be a good idea to remove these actions as well to further promote the use of the FireGPG Text editor for all cryptographic actions. If they are removed, points 3 and 4 above become irrelevant and may be ignored. [1] http://getfiregpg.org/ [2] extensions.firegpg.result_always_in_new_window, called "Always display encryption and signature results in a separate window" in the FireGPG options window.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
