From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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----- --=-=-=--