From a5d70215494784a96b366f7304ae606397723051 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 11 Oct 2013 18:51:09 +2000 Subject: [PATCH] possible infinite recursion in notmuch-cli --- bb/b095848a2b2c2e6d840e813287a74b41d2ef66 | 122 ++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 bb/b095848a2b2c2e6d840e813287a74b41d2ef66 diff --git a/bb/b095848a2b2c2e6d840e813287a74b41d2ef66 b/bb/b095848a2b2c2e6d840e813287a74b41d2ef66 new file mode 100644 index 000000000..68221b907 --- /dev/null +++ b/bb/b095848a2b2c2e6d840e813287a74b41d2ef66 @@ -0,0 +1,122 @@ +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 2A3E2431FAF + for ; Thu, 10 Oct 2013 15:51:23 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + 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 iG9wR6QISDhj for ; + Thu, 10 Oct 2013 15:51:18 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) + by olra.theworths.org (Postfix) with ESMTP id 33CFC431FAE + for ; Thu, 10 Oct 2013 15:51:18 -0700 (PDT) +Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) + by che.mayfirst.org (Postfix) with ESMTPSA id CBCB6F984 + for ; Thu, 10 Oct 2013 18:51:11 -0400 (EDT) +Received: by fifthhorseman.net (Postfix, from userid 1000) + id 83B85204C5; Thu, 10 Oct 2013 18:51:12 -0400 (EDT) +From: Daniel Kahn Gillmor +To: notmuch mailing list +Subject: possible infinite recursion in notmuch-cli +User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Thu, 10 Oct 2013 18:51:09 -0400 +Message-ID: <874n8ospsy.fsf@alice.fifthhorseman.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha512; protocol="application/pgp-signature" +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: Thu, 10 Oct 2013 22:51:23 -0000 + +--=-=-= +Content-Type: text/plain +Content-Transfer-Encoding: quoted-printable + +Hi notmuch folks-- + +On oss-security recently, there was a discussion about recursive +compression and the ability to create infinite loops. + + id:20131010013106.GA29693@openwall.com + +After some discussion with amdragon on IRC, i believe that this is only +relevant to notmuch when actively decrypting a message -- OpenPGP's +ability to embed compression makes it possible to write a PGP/MIME +message that is a quine: that is, when decompressed, it would expand to +itself, which would send our parser into an infinite loop. + +Since we're not decrypting during indexing, only notmuch-show and +notmuch-reply are probably affected by this problem. (but if someone +implements indexing of encrypted messages, then we'd have to worry about +this in the indexer as well) + +The simple and generalized solution would be to limit the recursive +depth of our walk of the MIME tree; probably a large limit of something +like 30 or 50 would not trigger any real-world problems, and would halt +a runaway recursion well before most modern machines ran out of +resources. + +A more targeted fix might be to just limit the number of recursive +decryptions that happen, since the MIME spec does not appear to be +capable of permitting other parts to provide both compression and +nesting, which is the root of the problem. However, it's possible that +our MIME parsing ends up being more permissive than the specs, and is +willing to try to interpret (for example) a gzip-compressed multipart/* +or message/* part.=20=20 + +So the simple/generalized solution is probably the right way to go. + +Sorry i don't have time to implement the fix myself right now, but i +wanted to make sure the active coders in the project are aware of the +issue. + +Regards, + + --dkg + +references: + + http://mumble.net/~campbell/blag.txt (see 2013-10-08) + http://www.openwall.com/lists/oss-security/2013/10/10/2 + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.14 (GNU/Linux) + +iQJ8BAEBCgBmBQJSVy9dXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB +NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcfRsQAIFmyQdi41nImeLcXj++Uv37 +A70y14mCeosYEt18WkGmWutb/13ZSPgtMqyF+mUNjxjVCdPeYDoBR0KQyLmz5R2K +TGUwtVUppsvtRHQJhct2vZOf5m9024Yy01eFqs75Iy2DqTmktW9HjeZUXLoBYx/L +mkO+QDx5sLGizWCKa8Cc8/fs67lScQe3mP/7eV1TopwEJxhVmZ2GymczDdmdvwhI +PCmo+iSR5dK2r2NRYycyZBLVYUftvPCRk0J0jxHBgi8aN7FUWRWm9eFh6+xJ610N +LCTaYhrZ7ba6a6KHYtRWk3ZMWb710uxsIwS7Tc/vvzHnWL5GpvnXzQ8H3V1NDnty +1gfy3puA1OWFdiOwbxLX2jbPxGBz1ywwKXtzq3WmZfmo3JAhlpVdiMX8mc1b8RwD +kghVoyhhwlRLa+ZzJFkgxUcu0uxepYBxK4BYb4F1PFBZl5UoU3GJoHYbq5CpsOXi ++gJbE19Q1kvRoKmKZqpl3DOQecDGSypJtZFkU4tvvIW5ZO0DK0G7xwA4JsnzHiMp +zWJtlhq1+kcqDPg/rdW3exltdqWB8UiGyBk3Rw9U5EcrLqL4yeuMmiXpZPb3o8BR +sqltEi8FStFJcXDrTscBo+U0kQelKGviLMRElex6WAxqabiecQxiQrkmL+Q18D2A +O0iXvvJ3LuAzUGGmrSYv +=48MT +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2