GNOME Bugzilla – Bug 741828
currency conversion support: privacy, security and future proofing issues
Last modified: 2018-05-22 11:51:08 UTC
gnome-calculator downloads currency data via an insecure protocol with no user-visible warning: https://git.gnome.org/browse/gnome-calculator/tree/src/currency.vala#n395 There are various possible problems with that: Users do not have any say in when/if the data is downloaded. It is easy for network-based attackers to manipulate currency conversion results by giving incorrect conversion rates. It would be easier to exploit parsing/etc bugs for network-based attackers. The IMF/ECB and any network attackers are notified when users switch to Financial mode or do a currency conversion for the first time and when updates happen. If the data changes URL or format then the currency functionality will be broken. Please adjust the feature so that: All downloads of the currency data are explicitly initiated by the user by default. There is an option to auto-update the data and an indicator in the UI when data will be downloaded. Data is downloaded from a trusted server such as via a proxy on gnome.org. Data is downloaded over https and the certificate is pinned. Data is downloaded over Tor if it is available.
I forgot to mention the data downloaded should be in a format specified by gnome. Adding safety team tag: https://wiki.gnome.org/SafetyTeam
(In reply to comment #0) > All downloads of the currency data are explicitly initiated by the user by > default. > > There is an option to auto-update the data and an indicator in the UI when data > will be downloaded. It's not reasonable to give the user control over whether and when to download exchange rates; that should happen transparently. Think of this from the perspective of safety: the risk of performing a calculation with an old exchange rate is greater than the risk of a MITM manipulating the exchange rate. I'm also totally fine with leaking the fact that the user has switched Calculator to financial mode. Your threat model is way too strict. Even if we switch to HTTPS, a voyeur who is for some reason interested in when you are using financial mode will still be able to know just by assuming that every visit to the IMF or ECB web site is from Calculator, a reasonable assumption for the 99% of users who don't visit these web sites. The only real solution here is to use Tor, which you did suggest, but that does not seem reasonable to me. > Data is downloaded from a trusted server such as via a proxy on gnome.org. This is a reasonable request; once GNOME has a TLS proxy, which I think everyone wants, we'll certainly start using it. > Data is downloaded over https Also reasonable, but keep in mind that a TLS proxy is not going to protect the integrity of the data between the IMF or ECB and GNOME. That connection will necessarily remain insecure until either the IMF or ECB decides they care about security. > and the certificate is pinned. We don't want our app to break every two years when the cert changes. Now, if the host were to use HSTS (which a GNOME TLS proxy presumably would) to set *its own* time limit for how long the cert is to be pinned, then respecting that would be reasonable. This raises the question of where in the stack to put HSTS support. We've previously been trying to decide between WebKitGTK+ and libsoup, but Calculator just uses GFile. > Data is downloaded over Tor if it is available. Again, I'm totally fine with leaking the fact that the user has switched Calculator to financial mode.
(In reply to comment #2) > Even if we switch to HTTPS, a voyeur who is for some reason interested in when > you are using financial mode will still be able to know just by assuming that > every visit to the IMF or ECB web site is from Calculator, a reasonable > assumption for the 99% of users who don't visit these web sites. The only real > solution here is to use Tor, which you did suggest, but that does not seem > reasonable to me. Ah, but not if we use a TLS proxy; I see.
(In reply to comment #2) > the risk of performing a calculation with an old exchange rate is > greater than the risk of a MITM manipulating the exchange rate. I would say the results are exactly the same: you risk getting an incorrect result in both cases. The risk of an attacker directed incorrect result seems higher than the risks of a market directed incorrect result to me though. > I'm also totally fine with leaking the fact that the user has switched > Calculator to financial mode. Your threat model is way too strict. Hmm, that is disappointing, but ok. > use Tor ... but that does not seem reasonable to me. If Tor is available on the user's system it seems reasonable to use it. > This is a reasonable request; once GNOME has a TLS proxy, which I think > everyone wants, we'll certainly start using it. Excellent, have the infrastructure team been contacted about it? > Also reasonable, but keep in mind that a TLS proxy is not going to protect the > integrity of the data between the IMF or ECB and GNOME. That connection will > necessarily remain insecure until either the IMF or ECB decides they care > about security. Both the IMF and ECB already have https setup on the two URLs: https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml https://www.imf.org/external/np/fin/data/rms_five.aspx?tsvflag=Y Due to the nature of SSL it is impossible to pin the CA for their certs and unfortunately neither have DNSSEC or TLSA > We don't want our app to break every two years when the cert changes. That isn't necessary, I would advocate this approach: http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/ Essentially, create a private CA for SSL certs on data.gnome.org and have the calculator app pin that CA rather than pinning the service cert for data.gnome.org, this way you could have a well-protected CA cert that could last for 10 years and yearly-rotated service certs.
I forgot to mention that the requests appear to have Cookie headers in them but I can't find where these come from because there isn't any such cookies in the code. Please clear all cookies before making requests.
(In reply to comment #4) > (In reply to comment #2) > > the risk of performing a calculation with an old exchange rate is > > greater than the risk of a MITM manipulating the exchange rate. > > I would say the results are exactly the same: you risk getting an > incorrect result in both cases. The risk of an attacker directed > incorrect result seems higher than the risks of a market directed > incorrect result to me though. I think it's much more likely that someone will never update his exchange rate > > This is a reasonable request; once GNOME has a TLS proxy, which I think > > everyone wants, we'll certainly start using it. > > Excellent, have the infrastructure team been contacted about it? Not sure. > Both the IMF and ECB already have https setup on the two URLs: > > https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml > https://www.imf.org/external/np/fin/data/rms_five.aspx?tsvflag=Y > > Due to the nature of SSL it is impossible to pin the CA for their certs and > unfortunately neither have DNSSEC or TLSA Hm, that's really strange, since I'm pretty sure I tried both of those URLs yesterday. OK, well there's no reason not to start using these now; that gives the same level of security as HTTPS in our web browser, which admittedly isn't that great. When we have infrastructure in place for a TLS proxy and HSTS (or some other form of certificate pinning) or tor integration or whatnot, then we can do more. > That isn't necessary, I would advocate this approach: > > http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/ > > Essentially, create a private CA for SSL certs on data.gnome.org and > have the calculator app pin that CA rather than pinning the service cert > for data.gnome.org, this way you could have a well-protected CA cert > that could last for 10 years and yearly-rotated service certs. Seems reasonable. (In reply to comment #5) > I forgot to mention that the requests appear to have Cookie headers in them but > I can't find where these come from because there isn't any such cookies in the > code. Please clear all cookies before making requests. Hm, that's very interesting. We just call g_file_new_for_uri() and then g_file_copy_async() -- I don't think it's reasonable for a cookie header to be sent. Presumably it is empty? It seems incredible that gio could be storing cookies. Can you please open a separate bug for this against glib (component: gio) and CC me? (Certainly, Calculator is not storing cookies itself.) A snippet from the pcap you discovered this with would be good.
Created attachment 293187 [details] [review] Use HTTPS for downloading exchange rates Because it's available, and some security > no security
Comment on attachment 293187 [details] [review] Use HTTPS for downloading exchange rates Attachment 293187 [details] pushed as 41d04d1 - Use HTTPS for downloading exchange rates
The cookie sent after deleting the cache and restarting gnome-calculator isn't empty, I think it must have been stored somewhere after the first fetch ever. The cookies look like this: Cookie: NSC_xxx.jng.psh=...; citrix_ns_id_.imf.org_%2F_wat=...; citrix_ns_id=... Cookie: BIGipServerPOOL.www.ecb.europa.eu_HTTP=... If I run gnome-calculator with a different HOME environment variable, the cookies are still sent. Will file another bug tomorrow.
(In reply to comment #9) > The cookie sent after deleting the cache and restarting gnome-calculator isn't > empty, I think it must have been stored somewhere after the first fetch ever. > The cookies look like this: > > Cookie: NSC_xxx.jng.psh=...; citrix_ns_id_.imf.org_%2F_wat=...; > citrix_ns_id=... > Cookie: BIGipServerPOOL.www.ecb.europa.eu_HTTP=... > > If I run gnome-calculator with a different HOME environment variable, the > cookies are still sent. My first thought: You're sure that the cookie is being sent from Calculator to the server, and not vice-versa? My second thought: Try setting $XDG_DATA_HOME somewhere different as well.
Yes, these occur in the initial HEAD request, not in the reply. Setting XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME and XDG_RUNTIME_DIR didn't help either. With a freshly created user, the cookie headers are not set, so they definitely come from the initial request and persist across requests. With a freshly logged-in user, the cookie headers are not set, so the cookies are not remembered between user sessions, probably glib has them in RAM somewhere.
I'm not sure the glib devs will see this as a bug. I'll await your advice before sending a glib bug.
(In reply to comment #12) > I'm not sure the glib devs will see this as a bug. I'll await your advice > before sending a glib bug. Please do file a report (and CC me); the worst that can happen is the bug gets closed. I guess this seems like something that would be hard to do unintentionally, but let's at least find out what the rationale is. It's very unexpected from my POV.
Hey guys, I just noticed this bug from a twitter thread. Note that I recently moved away from GVFS to libsoup (to solve a problem with the xdg-app sandbox), so the cookies might not be set anymore, and if they are I might actually have some control over it. Could you please test with master or 3.19.90?
Oh, thanks. I won't be able to test this until the fix gets into Debian unstable or experimental sorry. I didn't get time to file a bug on glib either, sorry.
With the patch being committed, anything left to mark this as fixed?
Marking as needinfo, will close this after a 2 weeks in case no one (@Paul Wise, @Michael Catanzaro) responds to the question.
Looking at the patch and my original report, these possible problems remain: Users do not have any say in when/if the data is downloaded. Not sure how to solve this for normal users though. The IMF/ECB and any network attackers are notified when users switch to Financial mode or do a currency conversion for the first time and when updates happen. This could be fixed by using Tor or by GNOME hosting the data or a proxy for it. If the data changes URL or format then the currency functionality will be broken. This could be fixed by GNOME providing a service that converts the IMF/ECB data and delivers it to users.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-calculator/issues/34.