From 4f2817de81f8243321c228fb1990b8125fad2418 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Thu, 22 Jan 2015 16:14:07 +1900 Subject: [PATCH] Re: privacy problem: text/html parts pull in network resources --- 5f/9c5c7859cd0cf511c145e8b92687dd78c0dc29 | 97 +++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 5f/9c5c7859cd0cf511c145e8b92687dd78c0dc29 diff --git a/5f/9c5c7859cd0cf511c145e8b92687dd78c0dc29 b/5f/9c5c7859cd0cf511c145e8b92687dd78c0dc29 new file mode 100644 index 000000000..b117d27be --- /dev/null +++ b/5f/9c5c7859cd0cf511c145e8b92687dd78c0dc29 @@ -0,0 +1,97 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id A0E78431FC9 + for ; Wed, 21 Jan 2015 13:14:15 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.138 +X-Spam-Level: +X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 + tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_MED=-2.3] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id RaOTj7P383G7 for ; + Wed, 21 Jan 2015 13:14:13 -0800 (PST) +Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) + by olra.theworths.org (Postfix) with ESMTP id EE39B431FBC + for ; Wed, 21 Jan 2015 13:14:12 -0800 (PST) +Received: from [104.131.20.129] (helo=awakeningjr) + by outgoing.csail.mit.edu with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) + (Exim 4.72) (envelope-from ) + id 1YE2bH-0007IS-T3; Wed, 21 Jan 2015 16:14:07 -0500 +Received: from amthrax by awakeningjr with local (Exim 4.84) + (envelope-from ) + id 1YE2bH-0001Oc-Eu; Wed, 21 Jan 2015 16:14:07 -0500 +Date: Wed, 21 Jan 2015 16:14:07 -0500 +From: Austin Clements +To: Daniel Kahn Gillmor +Subject: Re: privacy problem: text/html parts pull in network resources +Message-ID: <20150121211407.GK22599@csail.mit.edu> +References: <87ppa7q25w.fsf@alice.fifthhorseman.net> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <87ppa7q25w.fsf@alice.fifthhorseman.net> +User-Agent: Mutt/1.5.23 (2014-03-12) +Cc: notmuch mailing list +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 21 Jan 2015 21:14:15 -0000 + +I have a fix for this on shr buried deep in an old patch series that I +never got back to: id:1398105468-14317-12-git-send-email-amdragon@mit.edu + +For shr, the key is to set shr-blocked-images to ".". However, IIRC, +in the current notmuch message rendering pipeline, mm overrides this +variable with something computed from gnus-blocked-images. That said, +I'm not sure why gnus-blocked-images isn't *already* taking care of +this, but that's probably the place to start digging. + +Quoth Daniel Kahn Gillmor on Jan 21 at 4:00 pm: +> If i send a message with a text/html part (either it's only text/html, +> or all parts are rendered, or it's multipart/alternative with only a +> text/html subpart) and that HTML has src="http://example.org/test.png"/> in it, then notmuch will make a +> network request for that image. +> +> This is a privacy disaster, because it enables an e-mail sender to use +> "web bugs" to tell when a given notmuch user has opened their e-mail. +> +> It's also a bit of a consistency/storage/indexing disaster because it +> means that what you see when you open a given message will change +> depending on the network environment you're in when you open it. +> +> It's also potentially a security problem because it means that anyone in +> control of the remote server (or the network between you and the remote +> server if the image isn't sourced over https) can feed arbitrary data +> into whatever emacs image rendering library is being used. (granted, +> this is not a unique problem because this can already be done by the +> original message sender with a multipart/mixed message, but it's an +> additional exposure of attack surface) +> +> I just raised this on #notmuch, and i don't have the time or the +> knowledge to look into it now, but i think the defaults here need to be +> to avoid network access entirely unless the user explicitly requests it. +> +> --dkg + + + +> _______________________________________________ +> notmuch mailing list +> notmuch@notmuchmail.org +> http://notmuchmail.org/mailman/listinfo/notmuch + -- 2.26.2