Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx1.pub.mailpod2-cph3.one.com ([10.27.25.11])
	by mailstorage18.cst.mailpod2-cph3.one.com (Dovecot) with LMTP id 6OSsFuAey1riUgEAQS8vrQ
	for <filtered@awaresystems.be>; Mon, 09 Apr 2018 08:07:29 +0000
X-HalOne-ID: 0b2ab411-3bcd-11e8-8d9d-e0d848957041
Received: from mail-ot0-f169.google.com (unknown [74.125.82.169])
	by mx1.pub.mailpod2-cph3.one.com (Halon) with ESMTPS
	id 0b2ab411-3bcd-11e8-8d9d-e0d848957041;
	Mon, 09 Apr 2018 08:07:28 +0000 (UTC)
Received: by mail-ot0-f169.google.com with SMTP id h55-v6so7620291ote.9
        for <filtered@awaresystems.be>; Mon, 09 Apr 2018 01:07:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-original-authentication-results:x-gm-message-state:delivered-to
         :mime-version:in-reply-to:references:from:date:message-id:to:cc
         :subject:precedence:list-id:list-unsubscribe:list-archive:list-post
         :list-help:list-subscribe:mime-version:sender:errors-to;
        bh=6DkgRMhsfD8PUK90PmS5cgOXmo1Ivb2Ox5yLIdbydYY=;
        b=i/O/TBz5DVpXedpDdAADlsdkR6FY4J/eNmV/Ig/TmWymK3z7ls71eQYZB7YV1T2Vq2
         s9No2sjwCwyU5zOBycghcpX3dZ2Q5sbw2E1bmF1ntd8CAS9O0RUdkghtuczcpuiVVJvL
         AGLssKHx2qQGXzzHRDczp2a12RhnprGFeaRwQyHYKV1BY4dTo4m79t6AOHAwJrTXOn8J
         JVr1nJ/kFbTIkoq9yJpjWdUnaM8vMxOOXbSg01MFKe7ussdDtd+AbfqinuhT0KJH2MLm
         dKBrkTECCxawGwWyi29FQW5EgGqaZwq16BEDgukA5GY7TgTBv6weK+3QdpAGEnFxokDz
         pEbg==
X-Original-Authentication-Results: mx.google.com;       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;       dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
X-Gm-Message-State: ALQs6tAnJGCvFLCIqESzbYlhoYcgHf8RLL5XmYWxKdUTQn/8oEeZKzHU
	sFLx3QMbGrhBozcNpjxfGZmYPUD41fSbDQSr+wFbsS/GztrTfv0=
X-Received: by 2002:a9d:700a:: with SMTP id k10-v6mr24077158otj.194.1523261247284;
        Mon, 09 Apr 2018 01:07:27 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.74.210.156 with SMTP id h28csp2339568oos;
        Mon, 9 Apr 2018 01:07:26 -0700 (PDT)
X-Google-Smtp-Source: AIpwx493ak7HE8s3QKRbq5TVrFTpda0P/mHT6rw8t4hx3Q64AKs+qS6nX0/Vp/4/NuvBtjloyNlK
X-Received: by 10.28.125.194 with SMTP id y185mr22398997wmc.160.1523261246211;
        Mon, 09 Apr 2018 01:07:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1523261246; cv=none;
        d=google.com; s=arc-20160816;
        b=Piqv3//wJqE5VECLlVGlLeGLoCPQfURsseDdIKey04NvE5kerfT9K3c0AOdLLvE5er
         C+eFAtaYQ4YaJpcqOy/ozvc7pgsi69lNg6wC4JB7BTN3Uo/MMg3TQmIg7YlKmTBol6nP
         FN/ogcWPiupkLnHdPFBc5Zv8qcm9PjcreLmNZv98Op3i+e1KZEZWwMWIfNHtjbsqdGVG
         +XxQ4JfsPCXPMU+Xz7SSSThmmAbfTtYTUUJwcY69PIU5IyM9+ziBguUlQ7sMNPRAK2X5
         a1iTQ8pdwrKuHmOU4lk3WxF093ggOpseNeCH4nfn+pBOXniqR0/jgqm9JgQCQ1bSV/rP
         C4Sw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=errors-to:sender:mime-version:list-subscribe:list-help:list-post
         :list-archive:list-unsubscribe:list-id:precedence:subject:cc:to
         :message-id:date:from:references:in-reply-to:mime-version
         :arc-authentication-results;
        bh=6DkgRMhsfD8PUK90PmS5cgOXmo1Ivb2Ox5yLIdbydYY=;
        b=kSgSz7OIZhLTV60twtX2ejQ1RTzM/39DO/s0kJuzkHpsmRUFVJ6FNZl/ce1qEVS9s7
         tbvK2yOukplka7QPmh0zmzW3PYPuBV1Sg0PjxYyxcwwlTBA61tdCfVUpYTg466Ah59p0
         EkrO+m7F1EUXZVONbT79uUk4PAPeDZmSzmQR34Q+fVkocofxUKnnM0ducd1wHO35xRrR
         IArYF0GtHRXb+IvQLBbk4xoc58Zu2t51nW8K0PBRy1LR4EL3SOfdO3YMNB0wiki/YYUN
         qzhm+9qiiqtPOW9J+rkW4oKTB9WIvdMhLntn9sVq59oT6x1DmfBN2uHKhWpGoZ3c4ufU
         GnWA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;
       dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Return-Path: <tiff-bounces@lists.maptools.org>
Received: from lists.maptools.org (ks365428.kimsufi.com. [94.23.4.142])
        by mx.google.com with ESMTP id c17si8468779wrg.493.2018.04.09.01.07.25;
        Mon, 09 Apr 2018 01:07:26 -0700 (PDT)
Received-SPF: neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=94.23.4.142;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org;
       dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 8815035C031;
	Mon,  9 Apr 2018 03:06:34 -0500 (EST)
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
	by lists.maptools.org (Postfix) with ESMTPS id BC27635C02F
	for <tiff@lists.maptools.org>; Mon,  9 Apr 2018 03:06:16 -0500 (EST)
Received: by mail-wm0-f54.google.com with SMTP id 66so10578284wmd.3
	for <tiff@lists.maptools.org>; Mon, 09 Apr 2018 01:06:16 -0700 (PDT)
X-Received: by 10.28.8.143 with SMTP id 137mr18053253wmi.54.1523261175703;
	Mon, 09 Apr 2018 01:06:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.158.65 with HTTP; Mon, 9 Apr 2018 01:05:55 -0700 (PDT)
In-Reply-To: <CABj5TKTJeeQ+O37e7tyPaftUeV6Hemu3r0oZFjumYZisU9KJ1A@mail.gmail.com>
References: <CABj5TKTJeeQ+O37e7tyPaftUeV6Hemu3r0oZFjumYZisU9KJ1A@mail.gmail.com>
From: Nicolas RUFF <nicolas.ruff@gmail.com>
Date: Mon, 9 Apr 2018 10:05:55 +0200
Message-ID: <CABoQFUBBAfbqMBFpeGEqWDA2OfONZKhxXo-ntjKkgSEm9mfEzA@mail.gmail.com>
To: Paul Kehrer <paul.l.kehrer@gmail.com>
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] fuzzing libtiff with google's oss-fuzz
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1438079581=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============1438079581==
Content-Type: multipart/alternative; boundary="001a11444e08472d0f056965e133"

--001a11444e08472d0f056965e133
Content-Type: text/plain; charset="UTF-8"

libtiff would definitely benefit from an oss-fuzz integration. Please also
note that Google offers up to $20,000 for successful integrations:
https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html

I worked on this last year, and hit the same memory allocation issue. You
can read the full thread here:
https://www.asmail.be/msg0055569571.html

I don't think we reached a definitive conclusion at that time. The thread
ended with those famous last words:

"And yes, these are the customers having 20 GB TIFF files (has happened)
and 10 GB strips (will happen soon). There is no "sane" limit."

I kind of disagree (libtiff would crash on 32-bit systems while trying to
malloc(10GB)), but I ended up fuzzing libtiff privately.

Retrospectively, I think it might make sense to leverage
FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION to fail gracefully on excessively
large allocations, only while being fuzzed.
https://llvm.org/docs/LibFuzzer.html#fuzzer-friendly-build-mode

Let me know if I can be of any help.

Regards,
Nicolas RUFF

2018-04-09 9:29 GMT+02:00 Paul Kehrer <paul.l.kehrer@gmail.com>:

> I've been experimenting with fuzzing libtiff recently and was wondering if
> there is interest in integrating libtiff into Google's OSS-Fuzz (
> https://github.com/google/oss-fuzz)? OSS-Fuzz is a public infrastructure
> for running continuous fuzzing. The system will automatically fuzz the
> targets you define, aggregate duplicate bug reports, and file issues with
> minimal reproducers and stack traces so that project developers can easily
> verify and fix issues. libtiff appears to be getting some fuzzing by proxy
> via other projects, but I'd be happy to manage the process of integration
> and submit PRs so that you can directly receive reports and get better
> coverage.
>
> The primary challenge at the moment is controlling libtiff's memory
> allocations (it looks like several previous OSS fuzz related fixes have
> attempted to address that in various code paths?). It is very easy to craft
> files that will cause extremely large malloc and I've been unable to find a
> library level way to constrain that. However, I've modified my existing
> fuzzer a bit to throw out most test cases that would trigger OOMs for now
> (at least all the ones I was able to generate locally). Ideally in the
> longer term those would be removed as libtiff gets better at avoiding large
> allocations on invalid files.  Additionally, at the moment the fuzzer I
> wrote only uses TIFFReadRGBAImage -- do people have suggestions for other
> functions that might be worthwhile to fuzz? You can see the current diff
> adding libtiff to the oss-fuzz repo (this includes building libz and
> libjpeg-turbo as well as compiling the fuzzer) here:
> https://github.com/google/oss-fuzz/compare/master...
> reaperhulk:libtiff?expand=1
>
> If there's interest I just need to know who to put as the primary project
> email contact and any other people you want to grant access. Those email
> addresses will need to be associated with a Google account so that you can
> log into oss-fuzz.com to view the reports.
>
> -Paul Kehrer (reaperhulk)
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
>

--001a11444e08472d0f056965e133
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">libtiff would definitely benefit from an oss-fuzz integrat=
ion. Please also note that Google offers up to $20,000 for successful integ=
rations:=C2=A0<a href=3D"https://opensource.googleblog.com/2017/05/oss-fuzz=
-five-months-later-and.html">https://opensource.googleblog.com/2017/05/oss-=
fuzz-five-months-later-and.html</a><div><br></div><div>I worked on this las=
t year, and hit the same memory allocation issue. You can read the full thr=
ead here:</div><div><a href=3D"https://www.asmail.be/msg0055569571.html">ht=
tps://www.asmail.be/msg0055569571.html</a><br></div><div><br></div>I don&#3=
9;t think we reached a definitive conclusion at that time. The thread ended=
 with those famous last words:<br><br>&quot;And yes, these are the customer=
s having 20 GB TIFF files (has happened) and 10 GB strips (will happen soon=
). There is no &quot;sane&quot; limit.&quot;<div><br></div><div>I kind of d=
isagree (libtiff would crash on 32-bit systems while trying to malloc(10GB)=
), but I ended up fuzzing libtiff privately.<div><br></div><div>Retrospecti=
vely, I think it might make sense to leverage=C2=A0<span style=3D"font-size=
:13px;font-family:sans-serif">FUZZING_BUILD_MODE_UNSAFE_FOR_</span><wbr sty=
le=3D"font-size:13px;font-family:sans-serif"><span style=3D"font-size:13px;=
font-family:sans-serif">PRODUCTION to fail gracefully on excessively large =
allocations, only while being fuzzed.=C2=A0</span><a href=3D"https://llvm.o=
rg/docs/LibFuzzer.html#fuzzer-friendly-build-mode" style=3D"font-family:san=
s-serif">https://llvm.org/docs/LibFuzzer.html#fuzzer-friendly-build-mode</a=
></div></div><div><br></div><div>Let me know if I can be of any help.</div>=
<div><br></div><div>Regards,</div><div>Nicolas RUFF</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2018-04-09 9:29 GMT+02:00 P=
aul Kehrer <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.l.kehrer@gmail.com"=
 target=3D"_blank">paul.l.kehrer@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white=
-space"><div id=3D"m_7920617959279741678bloop_customfont" style=3D"font-fam=
ily:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-he=
ight:auto"><div id=3D"m_7920617959279741678bloop_customfont" style=3D"margi=
n:0px">I&#39;ve been experimenting with fuzzing libtiff recently and was wo=
ndering if there is interest in integrating libtiff into Google&#39;s OSS-F=
uzz (<a href=3D"https://github.com/google/oss-fuzz" target=3D"_blank">https=
://github.com/google/<wbr>oss-fuzz</a>)? OSS-Fuzz is a public infrastructur=
e for running continuous fuzzing. The system will automatically fuzz the ta=
rgets you define, aggregate duplicate bug reports, and file issues with min=
imal reproducers and stack traces so that project developers can easily ver=
ify and fix issues. libtiff appears to be getting some fuzzing by proxy via=
 other projects, but I&#39;d be happy to manage the process of integration =
and submit PRs so that you can directly receive reports and get better cove=
rage.</div><div id=3D"m_7920617959279741678bloop_customfont" style=3D"margi=
n:0px"><br></div><div id=3D"m_7920617959279741678bloop_customfont" style=3D=
"margin:0px">The primary challenge at the moment is controlling libtiff&#39=
;s memory allocations (it looks like several previous OSS fuzz related fixe=
s have attempted to address that in various code paths?). It is very easy t=
o craft files that will cause extremely large malloc and I&#39;ve been unab=
le to find a library level way to constrain that. However, I&#39;ve modifie=
d my existing fuzzer a bit to throw out most test cases that would trigger =
OOMs for now (at least all the ones I was able to generate locally). Ideall=
y in the longer term those would be removed as libtiff gets better at avoid=
ing large allocations on invalid files.=C2=A0 Additionally, at the moment t=
he fuzzer I wrote only uses TIFFReadRGBAImage -- do people have suggestions=
 for other functions that might be worthwhile to fuzz? You can see the curr=
ent diff adding libtiff to the oss-fuzz repo (this includes building libz a=
nd libjpeg-turbo as well as compiling the fuzzer) here: <a href=3D"https://=
github.com/google/oss-fuzz/compare/master...reaperhulk:libtiff?expand=3D1" =
target=3D"_blank">https://github.com/google/oss-<wbr>fuzz/compare/master...=
<wbr>reaperhulk:libtiff?expand=3D1</a></div><div id=3D"m_792061795927974167=
8bloop_customfont" style=3D"margin:0px"><br></div><div id=3D"m_792061795927=
9741678bloop_customfont" style=3D"margin:0px">If there&#39;s interest I jus=
t need to know who to put as the primary project email contact and any othe=
r people you want to grant access. Those email addresses will need to be as=
sociated with a Google account so that you can log into <a href=3D"http://o=
ss-fuzz.com" target=3D"_blank">oss-fuzz.com</a> to view the reports.</div><=
div id=3D"m_7920617959279741678bloop_customfont" style=3D"margin:0px"><br><=
/div><div id=3D"m_7920617959279741678bloop_customfont" style=3D"margin:0px"=
>-Paul Kehrer (reaperhulk)</div></div></div>
<br>______________________________<wbr>_________________<br>
Tiff mailing list: <a href=3D"mailto:Tiff@lists.maptools.org">Tiff@lists.ma=
ptools.org</a><br>
<a href=3D"http://lists.maptools.org/mailman/listinfo/tiff" rel=3D"noreferr=
er" target=3D"_blank">http://lists.maptools.org/<wbr>mailman/listinfo/tiff<=
/a><br>
<a href=3D"http://www.remotesensing.org/libtiff/" rel=3D"noreferrer" target=
=3D"_blank">http://www.remotesensing.org/<wbr>libtiff/</a><br></blockquote>=
</div><br></div>

--001a11444e08472d0f056965e133--

--===============1438079581==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
--===============1438079581==--
