summaryrefslogtreecommitdiffstats
path: root/wiki/src/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks.mdwn
blob: 74535781cb7e1e2a92fed54d3654712622119e3c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
[[!meta title="FireGPG susceptible to devastating attacks"]]

**FireGPG is no more shipped in Tails.**

You should instead use our custom GPG applet to:

  - [[Encrypt text with a passphrase|encryption_and_privacy/gpgapplet/passphrase_encryption]]
  - [[Encrypt and sign text using public-key encryption|encryption_and_privacy/gpgapplet/public-key_encryption]]
  - [[Decrypt and verify text|encryption_and_privacy/gpgapplet/decrypt_verify]]

[[!toc levels=2]]

Advisory
========

[FireGPG](http://getfirefox.com) 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,
`extensions.firegpg.result_always_in_new_window`, called "Always
display encryption and signature results in a separate window" in the
FireGPG options window, 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 the `result_always_in_new_window` option 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 the
   `result_always_in_new_window` option 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. The `result_always_in_new_window` option 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.
Per a discussion on #tor-dev and later #tails with rransom and katmagic it came
to light that FireGPG may have a few serious security and anonymity issues
(katmagic even claimed with "85%" certainty that these issues were among the
main reasons FireGPG was discontinued):

Sample attack
=============

    <html>
    	<head>
    		<script type="text/javascript">
    			function decrypt() {
    				var elem = document.getElementById("pgp_msg");
    
    				if (elem.innerHTML != elem.value) {
    					elem.innerHTML = elem.value;
    					alert(elem.value);
    				}
    			}
    			window.setInterval(decrypt, 1000);
    		</script>
    	</head>
    
    	<body>
    <textarea id="pgp_msg" style="height: 600px; width: 600px">
    -----BEGIN PGP MESSAGE-----
    <snip>
    -----END PGP MESSAGE-----
    </textarea>
    	</body>
    </html>

A similar approach should also work for stealing a plaintext written in a text
box before it's encrypted.

Other ressources
================

- [[tor-talk] Tor Browser Bundle: PGP encryption
  built-in?](http://www.mail-archive.com/tor-talk@lists.torproject.org/msg02105.html)<br/>
  A thread on the [tor-talk] list adressing the issues of supporting GPG inside a browser.

- [Spoofing OpenPGP signatures against
  FireGPG](http://lair.fifthhorseman.net/~dkg/firegpg-audit/spoof/)<br/>
  Another possible attack on FireGPG.

Other possible issues
=====================

If it is possible to use JavaScript to check signatures, an attacker could
potentially learn the user's whole key chain by replaying messages and their
signatures made by those key holders. This would give the attacker an awful lot
of identifying bits of the user.