GSoC 2019 Project Idea: Add new checkers to the CVE Binary Tool

[terriko]

The CVE Binary tool team is hoping to participate in Google Summer of Code (GSoC) under the Python Software Foundation umbrella. You can read all about what this means at http://python-gsoc.org/. This issue, and any others tagged 'gsoc' are not generally available bugs, but related to project ideas for GSoC.

Project Idea : Add new checkers to the CVE Binary Tool

Project description: The CVE Binary Tool, at launch, only has checkers for 10 different open source libraries. We have a list of over 50 that are being added to our issues list (search for new checkers) that we'd like to have in our next few releases. For this project, you'll implement as many of those as you can, including producing tests.

(Don't worry that we're going to run out of checkers -- if we exhaust the current list, we can definitely find more to add.)

Skills: Python, git, experience reading source code for other languages a bonus

Difficulty level: Easy

Related Readings/Links: How to add new checkers

Potential mentors: @terriko @pdxjohnny @WhataTiberius

Getting Started: Python requires that all students submit a code sample as part of your application. For your first pull request, we recommend you write a new test case for an existing checker. The easiest one to do as a first pull request is a scanner test for a new version of a library we can already detect.

• Existing tests are in test/
• You can see the scanner tests in 'tests/test_scanner.py'
• To add a new one, make a new test case that detects a few CVEs known to occur in this version, and a few that are known not to occur in that version. For example, here's what the current openssl test looks like:

    def test_openssl_1_0_2g(self):
        """Scanning test-openssl-1.0.2g.out"""
        self._binary_test(
            'test-openssl-1.0.2g.out',
            'openssl',
            '1.0.2g',
            [
                # Check for known cves in this version
                "CVE-2016-2107",
                "CVE-2016-2105",
                "CVE-2016-2106",
                "CVE-2016-2109",
                "CVE-2016-2176",
            ],
            [
                # Check to make sure an older CVE isn't included
                "CVE-2016-0800",
            ])

• Not sure what CVEs apply to a version? The checkers themselves often have links, and have the vendor/product pair so you can find them in the national vulnerability database as well. Here's a link to the openssl checker for you to look at and the rest are in cve-bin-tool/checkers/
• You'll also need to make a fake file designed to trick the checker into thinking it has found that version of the library. You can see these files in test/binaries/
• Please note that sometimes the database we're using doesn't have perfect mapping between CVEs and product versions -- if you try to write a test that doesn't work because of that mapping but the description in the CVE says that version should be vulnerable, don't discard it! Instead, make a note of it in a comment here so we can investigate and maybe report it upstream.

Extra credit: Got your test working and want to try something more? You can also try adding a checker before the project starts. See the related readings above for instructions.

[bksahu]

@terriko Hi. I'm interested to work on this.

[PrajwalM2212]

@bksahu As a initial PR you have to create a test . Follow the Getting Started section. Also introduction comments can be made in #23

[terriko]

I've started to add a few new checker requests into our github issues list, so if you're looking for some more advanced work, here's the search that will find them as they get added

[arnav-t]

I'm interested in this. Is this available to work on @terriko ?

[terriko]

@arnav-t All GSoC ideas are open to all until Google's application system closes and we have to choose students.

[terriko]

We're looking for "real file" tests of the scanners, if anyone's interested in working on those, details on how to add one are are available in #107. Short version, your test will look like this:

    @unittest.skipUnless(os.getenv('LONG_TESTS') == '1', 'Skipping long tests')
    def test_rpm_curl_7_32_0(self):
        """
        test to see if we detect a real copy of curl 7.32.0
        """
        self._file_test(
            'https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/20/Everything/x86_64/os/Packages/c/',
            'curl-7.32.0-3.fc20.x86_64.rpm',
            'curl',
            '7.32.0')

And when you test it locally, you'll need to make sure you have LONG_TESTS enabled, so this one would have to be run as follows:

LONG_TESTS=1 python -m unittest test.test_scanner.TestScanner.test_rpm_curl_7_32_0

[terriko]

I added a batch of new checker requests to github issues today that could be relevant to this gsoc idea.
Search for "new checker" to see the full list.

[terriko]

I also made a new tag "signature needs work" to flag the ones where we know there's no easy version string we can use as a signature, so people know those aren't the best ones to start on. I'm open to better ideas of what to call the tag, too.

[terriko]

Closing this since GSoC 2019 is drawing to a close, but this will probably be an idea again in GSoC 2020 because we can always use new checkers!