GNOME Bugzilla – Bug 747953
Information leak via plain text HTTP connection
Last modified: 2016-05-24 10:24:31 UTC
According to https://mail.gnome.org/archives/safety-list/2015-January/msg00000.html <mid:CAN0s7yT92JOXSv7Pyt6D=tebzLREnmr1FxUa=OYo9FS205nw0A@mail.gmail.com> GNOME music leaks information although it can prevent most of it by using the HTTPS API.
(In reply to Tobias Mueller from comment #0) > According to > https://mail.gnome.org/archives/safety-list/2015-January/msg00000.html > <mid:CAN0s7yT92JOXSv7Pyt6D=tebzLREnmr1FxUa=OYo9FS205nw0A@mail.gmail.com> > GNOME music leaks information although it can prevent most of it by using > the HTTPS API. Ressigning to grilo, since we request it via a grilo plugin
What changes are we supposed to make to the last.fm plugin exactly? And really, we shouldn't have to go fish out that information from a mailing-list archive, please put the relevant details in Bugzilla in the future.
We can't do anything on our end, it's all in bug 743449 comment 0 - last.fm's CDN does not support HTTPS for everything.
In one hand, grilo's plugin is using 1.0 API which, most probably is already deprecated. In the other hand, consider: https://ws.audioscrobbler.com/1.0/album/enya/The%20Celts/info.xml The albumart URLs are: <coverart> <small>http://userserve-ak.last.fm/serve/34s/85450891.png</small> <medium>http://userserve-ak.last.fm/serve/64s/85450891.png</medium> <large>http://userserve-ak.last.fm/serve/126/85450891.png</large> </coverart> As Elad comments, the certificate for https://userserve-ak.last.fm is invalid but the HTTPS method is not working even if we accept the invalid cert. Hence, the only way is to asume using HTTP. In addition, there is no personal ID in that URL so, even though there is no reason to leak which albumart are you browsing, the leaking information is not that compromising, IMHO. I would propose WONTFIX.
Consider also bug 700276 for WONTFIXing.
(In reply to Andres Gomez from comment #4) > In addition, there is no personal ID in that URL so, even though there is no > reason to leak which albumart are you browsing, the leaking information is > not that compromising, IMHO. > That's slightly misleading, because if you look at the big picture (and not just one individual request) you can fetch a list of all albums in the user's library - which is pretty much uniquely identifying (most people would have different sets of albums on their machines). However, I do agree that this should be closed, either as WONTFIX or NOTGNOME, because there's nothing we can do.
Am I correct assuming that this information leak only occurs when using the last.fm plugin? Such that not installing (or uninstalling) that plugin will make GNOME Music stop leaking your identity.
(In reply to Tobias Mueller from comment #7) > Am I correct assuming that this information leak only occurs when using the > last.fm plugin? Such that not installing (or uninstalling) that plugin will > make GNOME Music stop leaking your identity. I think that's correct. If the lastfm-albumart plugin is not installed, there is no leak of identity.
Yo Andres, can we remove the lastfm-albumart plugin until this is resolved? It's important that our applications respect users, and that includes keeping personal info like music preferences private by default. One possible resolution, if HTTPS is not possible, would be an opt-in that explains the risk without any technical details, something like: "Displaying album arts allows other people on the internet to see the music you listen to. [Cancel] [Enable album art]"
(In reply to Michael Catanzaro from comment #9) > One possible resolution, if HTTPS is not possible, would be an opt-in that > explains the risk without any technical details, something like: "Displaying > album arts allows other people on the internet to see the music you listen > to. [Cancel] [Enable album art]" I think that kind of opt-in has to come from the apps using this plugin through grilo. About removing the plugin, I will let someone with more "authority" to say ...
This very same concern could be applied for any kind of plugin that uses a public REST API (i.e., that doesn't allow encrypting the parameters). For instance, if I provide a plugin that, let's say, gets the lyrics from a webpage, the same can be said: it is leaking the data. Is it a problem? It depends on the application. In the case of Music , it can be seen as a problems. In others maybe not. If for Music is a problem, Music should black-list it: if the plugin is loaded, then unload it.
Ok, I need to say something else: yes, using HTTPS would fix the problem. Probably the right approach is either Music unloading that plugin, or asking packagers to remove the plugin.
Related with bug #700276
BTW, the 2.0 API wouldn't fix the problem: the final jpg cover is obtained through http, not https.
(In reply to Elad Alfassa from comment #6) > (In reply to Andres Gomez from comment #4) > > In addition, there is no personal ID in that URL so, even though there is no > > reason to leak which albumart are you browsing, the leaking information is > > not that compromising, IMHO. > > > > That's slightly misleading, because if you look at the big picture (and not > just one individual request) you can fetch a list of all albums in the > user's library - which is pretty much uniquely identifying (most people > would have different sets of albums on their machines). Not that much misleading, IMHO. It is true that you can "re-construct" a finger print of your musical taste but you will need first to be able to match an album from its cover art. Maybe you can do this if you have available a similar album art DB like LastFm's (Spotify, Amazon, etc.), but, although not impossible, this is not so trivial, IMHO.
Just a list of all pictures fetched is enough to construct a fingerprint and thus identifying your device across networks. Regardless, Music can't disable this plugin... Music's UX relies on having album art. And since there's no HTTPS possible here, there's nothing we can do about it and this bug should really be closed.
(In reply to Elad Alfassa from comment #16) > Just a list of all pictures fetched is enough to construct a fingerprint and > thus identifying your device across networks. > Maybe caching those covers on disk would minimize the problem (not remove it). At least, you wouldn't be identified in next connections. > Regardless, Music can't disable this plugin... Music's UX relies on having > album art. And since there's no HTTPS possible here, there's nothing we can > do about it and this bug should really be closed. Yep. We would need an alternative plugin.
Yeah, caching would be useful... but should it be implemented in the plugin or in Music itself?
It depends. If you implement in Music, you have more flexibility regarding how to store the images, and how to recover them. If you do through the plugin itself, then probably the best approach would be saving the images following the MediaArt spec. Later, the covers could be recovered directly by Music (computing the expected image value) or through Tracker. In case of doing through plugin,this should be an optional parameter.
Created attachment 306594 [details] [review] source: Add "net:plaintext" source tag doc This will make it easier for applications to avoid using plaintext channels, such as HTTP-only connections, when doing requests. Adding a tag allows applications to avoid hard-coding sources which might leak private information.
Created attachment 306595 [details] [review] lua-factory: Block plain text queries when source doesn't advertise it To avoid sources from doing plain text queries without advertising them, verify the schemes used by the URLs passed to grl.fetch.
Those 2 above are my way of "fixing" this. We still need patches to the various sources that make plain text HTTP queries, like the last.fm one, but at least, now, applications can make informed decisions on which sources to use.
Am I going to get any feedback on this?
FWIW: I like the approach.
Comment on attachment 306594 [details] [review] source: Add "net:plaintext" source tag doc Attachment 306594 [details] pushed as 7e87137 - source: Add "net:plaintext" source tag doc
Attachment 306595 [details] pushed as 975a810 - lua-factory: Block plain text queries when source doesn't advertise it
Does this mean the connections are blocked unless the application opts-in?
(In reply to Michael Catanzaro from comment #27) > Does this mean the connections are blocked unless the application opts-in? No, the application will have to destroy the sources it doesn't want, such as the ones advertising themselves as "net:plaintext" in the tags.
Ping-pong back to GNOME Music, since it sounds like changes are required in Music. Maybe someone who is familiar with grilo could take a stab at a patch?
Created attachment 327736 [details] [review] grilo: Don't leak information over http Grilo can use sources that use insecure http connections, leaking information about the users behaviour while doing so. Disable all Grilo sources that use insecure connections by checking for the net:plaintext tag.
The patch in #30 should fix this issue. I think this should be the default behaviour. However, this currently disables music's main albumart source (lastfm). There are other sources, but in my opinion they aren't as extensive. So, we should probably allow users a choice if they want to use the unsafe sources as well. Is this possibly something to be integrated in the cc privacy options?
(In reply to Marinus Schraal from comment #31) > So, we should probably allow users a choice if they want to use the unsafe > sources as well. Is this possibly something to be integrated in the cc > privacy options? No, I don't think we should add application-specific settings under Privacy, nor do I want to make users some generic functionality vs. privacy switch.
Review of attachment 327736 [details] [review]: I think it's totally acceptable to lose some album art for the time being, until the LastFM provider can be improved to use their new secure API. ::: gnomemusic/grilo.py @@ +174,3 @@ def _on_source_added(self, pluginRegistry, mediaSource): + if "net:plaintext" in mediaSource.get_tags(): + return Bastien, I think it's a bad idea that we are required to have this non-obvious code in GNOME Music to make it secure. Preferably grilo would just not return any plaintext sources unless the application specifies otherwise. It should be secure by default, else tons of applications will get this wrong.
(In reply to Michael Catanzaro from comment #33) > I think it's totally acceptable to lose some album art for the time being, > until the LastFM provider can be improved to use their new secure API. The secure API is already used, only all the image links provided by the api go over http. But I just noticed that it actually works now to get them over https, only the certificate is untrusted.
(In reply to Marinus Schraal from comment #34) > But I just noticed that it actually works now to get them over https, only > the certificate is untrusted. Incredible. I don't think it's a good idea to pin this certificate, as we can't expect them to give us advance notice when changing it to avoid breaking GNOME Music. Maybe they'll fix this if we ask nicely.
(In reply to Michael Catanzaro from comment #33) <snip> > Bastien, I think it's a bad idea that we are required to have this > non-obvious code in GNOME Music to make it secure. Preferably grilo would > just not return any plaintext sources unless the application specifies > otherwise. It should be secure by default, else tons of applications will > get this wrong. We give you all the information we have. It's up to the application to filter them out. Totem filters out "adult" tagged sources for example.
Comment on attachment 327736 [details] [review] grilo: Don't leak information over http Committed this as it solves the problem now. As for the discussion, I do agree that we should strive for a secure by default approach in this day and age. I opened a bug about this for grilo: bug #766788 .
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
(In reply to Marinus Schraal from comment #37) > Comment on attachment 327736 [details] [review] [review] > grilo: Don't leak information over http > > Committed this as it solves the problem now. Pretty sure this patch is broken. It doesn't unregister the source. > As for the discussion, I do agree that we should strive for a secure by > default approach in this day and age. > > I opened a bug about this for grilo: bug #766788 .
(In reply to Bastien Nocera from comment #39) > > Pretty sure this patch is broken. It doesn't unregister the source. I'm pretty sure music is broken, it never unregistered a source ever afaics. Please do file a bug, let's fix it in one go.
(In reply to Marinus Schraal from comment #40) > (In reply to Bastien Nocera from comment #39) > > > > Pretty sure this patch is broken. It doesn't unregister the source. > > I'm pretty sure music is broken, it never unregistered a source ever afaics. > Please do file a bug, let's fix it in one go. Your patch doesn't do what you thought it did. Your fix is broken, and will still call those sources that are marked as insecure.
Fair enough, should be fixed now. Thanks for the heads-up.