Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

Tony Finch <dot@dotat.at> Thu, 02 March 2017 14:25 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D5129612 for <dnsop@ietfa.amsl.com>; Thu, 2 Mar 2017 06:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtB7r376-doP for <dnsop@ietfa.amsl.com>; Thu, 2 Mar 2017 06:25:07 -0800 (PST)
Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9B91295F2 for <dnsop@ietf.org>; Thu, 2 Mar 2017 06:25:07 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45114) by ppsw-43.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cjRfG-0002Pp-nS (Exim 4.89_RC7) (return-path <dot@dotat.at>); Thu, 02 Mar 2017 14:25:06 +0000
Date: Thu, 02 Mar 2017 14:25:05 +0000
From: Tony Finch <dot@dotat.at>
To: Roy Arends <roy@dnss.ec>
In-Reply-To: <76B12F6D-9D53-4FEB-974D-BB4D6DB02F0B@dnss.ec>
Message-ID: <alpine.DEB.2.11.1703021325290.3294@grey.csi.cam.ac.uk>
References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> <F40B69DF-6391-4008-A7CD-C85277952D8A@dnss.ec> <alpine.LRH.2.20.1702281627360.22841@bofh.nohats.ca> <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec> <alpine.LRH.2.20.1702282052220.28866@bofh.nohats.ca> <AC4C0368-1454-4718-95AF-BB4DDECEF17E@dnss.ec> <alpine.LRH.2.20.1703011221400.15273@bofh.nohats.ca> <76B12F6D-9D53-4FEB-974D-BB4D6DB02F0B@dnss.ec>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NNfQwRU7MIKaIvhFloNUZiHegj8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 14:25:11 -0000

Roy Arends <roy@dnss.ec> wrote:
>
> This is not true. The shattered.io pdf files contain an embedded jpeg.
> The difference between the files is in the jpeg comment. The size of the
> difference is 128 bytes. These are two consecutive 64 byte inputs. The
> two versions hash to the same output, given the prefix. The prefix is
> 192 bytes, and contains the PDF header and the start of the embedded
> JPEG.

AIUI it is slightly more complicated than that.

Both shattered.io PDFs contain both versions of the content as two JPEGs -
observe that both files contain two JFIF headers, and that the first JFIF
is after the colliding differences which are between octets 0x00c0 and
0x0140.

$ for i in 1 2; do echo $i; hd shattered-$i.pdf | grep -C1 JFI; done
1
00000230  00 00 ff fe 00 fc 00 00  00 00 00 00 00 00 ff e0  |................|
00000240  00 10 4a 46 49 46 00 01  01 01 00 48 00 48 00 00  |..JFIF.....H.H..|
00000250  ff db 00 43 00 01 01 01  01 01 01 01 01 01 01 01  |...C............|
--
0002da90  a8 87 d0 7f cc ba d0 1d  db 8d 23 a7 c3 89 1a 66  |..........#....f|
0002daa0  66 66 7f ff d9 41 4e 47  45 ff e0 00 10 4a 46 49  |ff...ANGE....JFI|
0002dab0  46 00 01 01 00 00 48 00  48 00 00 ff e1 00 40 45  |F.....H.H.....@E|
2
00000230  00 00 ff fe 00 fc 00 00  00 00 00 00 00 00 ff e0  |................|
00000240  00 10 4a 46 49 46 00 01  01 01 00 48 00 48 00 00  |..JFIF.....H.H..|
00000250  ff db 00 43 00 01 01 01  01 01 01 01 01 01 01 01  |...C............|
--
0002da90  a8 87 d0 7f cc ba d0 1d  db 8d 23 a7 c3 89 1a 66  |..........#....f|
0002daa0  66 66 7f ff d9 41 4e 47  45 ff e0 00 10 4a 46 49  |ff...ANGE....JFI|
0002dab0  46 00 01 01 00 00 48 00  48 00 00 ff e1 00 40 45  |F.....H.H.....@E|

The header before the collision is the start of a binary stream object
that contains the SHA-1 collision followed by both JPEGs. The first two
hunks below are the start and end of this stream object, and the third
hunk is in the PDF rubric towards the end of the file.

$ hd shattered-1.pdf | grep -C1 ream
00000080  43 6f 6d 70 6f 6e 65 6e  74 20 38 3e 3e 0a 73 74  |Component 8>>.st|
00000090  72 65 61 6d 0a ff d8 ff  fe 00 24 53 48 41 2d 31  |ream......$SHA-1|
000000a0  20 69 73 20 64 65 61 64  21 21 21 21 21 85 2f ec  | is dead!!!!!./.|
--
00066e90  a0 02 80 0a 00 28 00 a0  02 80 0a 00 ff d9 0a 65  |.....(.........e|
00066ea0  6e 64 73 74 72 65 61 6d  0a 65 6e 64 6f 62 6a 0a  |ndstream.endobj.|
00066eb0  0a 32 20 30 20 6f 62 6a  0a 31 30 32 34 0a 65 6e  |.2 0 obj.1024.en|
--
00067080  0a 0a 31 32 20 30 20 6f  62 6a 0a 3c 3c 2f 4c 65  |..12 0 obj.<</Le|
00067090  6e 67 74 68 20 33 35 3e  3e 0a 73 74 72 65 61 6d  |ngth 35>>.stream|
000670a0  0a 71 0a 20 20 31 30 32  34 20 30 20 30 20 37 34  |.q.  1024 0 0 74|
000670b0  30 20 30 20 30 20 63 6d  0a 20 20 2f 49 6d 30 20  |0 0 0 cm.  /Im0 |
000670c0  44 6f 0a 51 0a 65 6e 64  73 74 72 65 61 6d 0a 65  |Do.Q.endstream.e|
000670d0  6e 64 6f 62 6a 0a 0a 0a  0a 78 72 65 66 0a 30 20  |ndobj....xref.0 |

PDF files use indirect pointers to pull assets out of a binary stream. I
haven't picked out the details, but I believe the shattered.io PDFs
indirect via the SHA-1 collision garbage near the start of the binary
stream in order to select either the first or second embedded JPEG.

Now you might be able to use this existing collision to attack other file
formats which have PDF-style indirection, if you have Ange Albertini
levels of POC||GFTO polyglot construction skills :-) The main restriction
is that the colliding header must appear at the very start, so your target
has to be happy with files starting %PDF.

So I don't think you can use this particular collision to attack DNSSEC,
but if you can spend 6000 CPU-years of work, and if you can get a crafted
key into a DNSKEY record, then you could do some interesting things :-)
But you'll need to spend 6000 CPU-years per targeted attack, because the
RRset starts with the targeted domain name, and each collision depends on
a fixed prefix.

It's worth comparing with MD5 collisions. For SHA-1 they haven't yet got
to the point where they can construct a collision from two different
chosen prefixes, as they can for MD5, and which was necessary for creating
the rogue CA certificate.

https://www.iacr.org/conferences/eurocrypt2007/slides/s01t1.pdf
http://www.phreedom.org/research/rogue-ca/

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy, Sole: Southwest becoming cyclonic later 5 to 7, increasing gale 8 for
a time in southeast Fitzroy. Rough or very rough. Rain or thundery showers.
Good, occasionally poor.