{"id":19351,"date":"2022-07-01T09:02:46","date_gmt":"2022-07-01T07:02:46","guid":{"rendered":"https:\/\/daniel.haxx.se\/blog\/?p=19351"},"modified":"2022-07-01T09:04:14","modified_gmt":"2022-07-01T07:04:14","slug":"5-years-on-oss-fuzz","status":"publish","type":"post","link":"https:\/\/daniel.haxx.se\/blog\/2022\/07\/01\/5-years-on-oss-fuzz\/","title":{"rendered":"5 years on OSS-Fuzz"},"content":{"rendered":"\n<p>On July 1st 2017, exactly five years ago today, the <a href=\"https:\/\/google.github.io\/oss-fuzz\/\">OSS-Fuzz project<\/a> &#8220;adopted&#8221; curl into their program and started running fuzz tests against it.<\/p>\n\n\n\n<p>OSS-Fuzz is a project run by Google and they do <a href=\"https:\/\/en.wikipedia.org\/wiki\/Fuzzing\">fuzzing<\/a> on a large amount of open source projects: <em>OSS-Fuzz aims to make common open source software more secure and stable by combining modern fuzzing techniques with scalable, distributed execution<\/em>.<\/p>\n\n\n\n<p>That initial adoption of curl into OSS-Fuzz was done entirely by Google themselves and its fuzzing integration was rough and not ideal but it certainly got the ball rolling.<\/p>\n\n\n\n<p>Later in in the fall of 2017, Max Dymond stepped up and seriously improved the <a href=\"https:\/\/github.com\/curl\/curl-fuzzer\">curl-fuzzer<\/a> so that it would better test protocols and libcurl options deeper and to a higher degree. (<a href=\"https:\/\/opensource.googleblog.com\/2020\/01\/\">Max subsequently got a grant<\/a> from Google for his work.)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fuzzing curl<\/h2>\n\n\n\n<p>Fuzzing is really the next-level thing all projects should have a go at when there is no compiler warning left to fix and the static code analyzers all report zero defects, because fuzzing has a way to find silly mistakes, off-by-ones etc in a way no analyzers can and that is very hard for human reviewers to match.<\/p>\n\n\n\n<p>curl is a network tool and library written in C, it is meant to handle non-trusted data properly and doing it wrongly can have serious repercussions.<\/p>\n\n\n\n<p>For the curl project, OSS-Fuzz has found several silly things and bad code paths especially after that rework Max put in. We have no less than <strong>6<\/strong> curl CVEs registered in 2017 and 2018 giving OSS-Fuzz (at least partial) credit for their findings.<\/p>\n\n\n\n<p>In the first year or two, OSS-Fuzz truly kept us on our toes and we fixed numerous other flaws as well that weren&#8217;t CVE worthy but still bugs. <em>At least<\/em> 36 separate ones to date.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The beauty of OSS-Fuzz<\/h2>\n\n\n\n<p>For a little Open Source project such as curl, this service is great and in case you never worked with it let me elaborate what makes me enjoy it so much.<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Google runs all the servers and keeps the service running. We don&#8217;t have to admin it, spend energy on maintaining etc.<\/li><li>They automatically pull the latest curl code from our master branch and keep fuzzing it. All day, every day, non-stop.<\/li><li>When they find a problem, we get a bug submitted and an email sent. The bug report they create contains stack traces and a <em>minimized<\/em> and reproducible test case. In most cases, that means I can download a small file that is often less than a hundred bytes, and run my locally built fuzzer code with this input and see the same issue happen in my end.<\/li><li>The bug they submit is initially closed for the public and only accessible to select team of curl developers.<\/li><li>90 days after the initial bug was filed, it is made public automatically.<\/li><\/ol>\n\n\n\n<p>The number of false positives are remarkably low, meaning that almost every time the system emails me, it spotted a genuine problem.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fuzzing per commit<\/h2>\n\n\n\n<p>In 2020, the OSS-Fuzz team introduced <a href=\"https:\/\/google.github.io\/oss-fuzz\/getting-started\/continuous-integration\/\">CIFuzz<\/a>, which allows us to run a little bit of fuzzing &#8211; for a limited time &#8211; on a PR as part of the CI pipeline. Using this, we catch the most obvious mistakes even before we merge the code into our master branch!<\/p>\n\n\n\n<p>After the first few years of us fixing bad code paths, and with the introduction of CIFuzz, we nowadays rarely get reports from OSS-Fuzz anymore. And when we do, we have it complain on code that hasn&#8217;t been released yet. The number of <a href=\"https:\/\/curl.se\/docs\/security.html\">CVEs detected in curl<\/a> by OSS-Fuzz has therefore seemingly stopped at 6.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Taking fuzzing further<\/h2>\n\n\n\n<p>After five years of fuzzing, we would benefit from extending and improving the &#8220;hooks&#8221; where and how the fuzzing is made so that we can help it find and reach code paths with junk that it so far hasn&#8217;t reached. There are of course still potentially many undetected flaws in curl remaining because of the limited set of entry point we have for the fuzzer.<\/p>\n\n\n\n<p>I hope OSS-Fuzz continues and lives on for a long time. It certainly helps curl a lot!<\/p>\n\n\n\n<p>Thanks!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>On July 1st 2017, exactly five years ago today, the OSS-Fuzz project &#8220;adopted&#8221; curl into their program and started running fuzz tests against it. OSS-Fuzz is a project run by Google and they do fuzzing on a large amount of open source projects: OSS-Fuzz aims to make common open source software more secure and stable &hellip; <a href=\"https:\/\/daniel.haxx.se\/blog\/2022\/07\/01\/5-years-on-oss-fuzz\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">5 years on OSS-Fuzz<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":15652,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[123,33,428],"class_list":["post-19351","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-curl","tag-bugfixes","tag-curl-and-libcurl","tag-security"],"_links":{"self":[{"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/posts\/19351","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/comments?post=19351"}],"version-history":[{"count":26,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/posts\/19351\/revisions"}],"predecessor-version":[{"id":19534,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/posts\/19351\/revisions\/19534"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/media\/15652"}],"wp:attachment":[{"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/media?parent=19351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/categories?post=19351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/daniel.haxx.se\/blog\/wp-json\/wp\/v2\/tags?post=19351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}