Project:Security/Scouting Tips

This is a document based on the original blog post from Tim (underling) Sammut and revised to be a more generic Wiki article for Gentoo Security recruits.

Disclaimer

When someone volunteers on the security team, the first role they are asked to fill is that of a “Scout.” In this role, they primarily work to learn of newly disclosed vulnerabilities, determine if it applies to Gentoo, verify that a bug does not already exist, and then open bugs as appropriate. This is not necessarily an out-of-this-world-fantastic-fun job.

This is not a conclusive list of actions that will work wonders for everyone.

Vulnerability Feeds

The first step is to figure out which sources of vulnerability information are the best to track. There are many sources available–some better than others–and you will want to track these in some combination. Here are a few popular vulnerability feeds:

• Watch security@gentoo.org on http://bugs.gentoo.org: This is recommended in the Security Padawans process document and will help you see security bugs as they are created. Being familiar with current activity will help you recognize if a bug has already been created for an issue, saving you the effort of further research.

• oss-security: Following this mailing list is an absolute must. It will not help you learn of every new issue, but you will see CVE requests for issues not otherwise announced as well as CVE assignments which can make your security bugs more complete. Upstream developers as well as Linux distribution security teams actively post to this list about new issues and previously-announced issues.

• Watch security-response-team@redhat.com on http://bugzilla.redhat.com: This is accomplished using a similar process to following our own security team. The folks at Red Hat do a great job of documenting issues and receiving updates as they make them has proven to be a good source of information. If you are only looking for new vulnerabilities, you can set your preferences in the Red Hat bugzilla to only receive notifications of new security bugs to help control your inbox.

• Bugtraq: The Bugtraq list is used to publicly discuss vulnerabilities. Subscription is optional for scouting, but it is recommend to lurk and compensate by ignoring everything not relevant.

Processing Vulnerability Information

You now need to figure out how to deal with lots of email. If you are – borrowing the vocabulary of our Moms and Dads – a “tech person,” you probably receive a fair amount of email already. The best thing about these particular emails is that they can wait. There is no need to read them in the first five minutes after they arrive; and there may very well be no need to read them at all. This is part of the trick: to minimize the number of emails you read without missing items that may affect Gentoo.

Here is a common set up to do just that:

Email Handling

Use email rules or filters on incoming mail. Understand the characteristics of the emails arriving from each source you’ve signed up for, and move them all into one folder, or keep them in the inbox. Breaking sources into individual folders sounds great but may lead to duplication of efforts. If you must, use something like “Saved Searches” in Thunderbird to automatically filter the one giant inbound folder into something that appeases your organizational needs. Some email providers now have the ability to "tag" emails based on rules or filters. This can be a great way to separate emails by source, while keeping them all in one place.

View the one folder using a threaded view and learn your MUA’s hotkey for “collapse threads” and “expand threads” and “mark as read.” (These are ‘\’, ‘*’ and ‘m’ respectively in Thunderbird.)

Create a filter or saved search for the one folder that only displays unread or flagged items. “Flagged” may very well be a Thunderbird-only term, but certainly other clients will have something similar.

Now that we have laid the foundation for dealing with untold quantities of useless email, this is how I go about it:

1. Start viewing email in the “Unread and Flagged Items” folder.
2. Collapse all threads.
3. Start at the bottom, and use ‘m’ to mark obviously irrelevant threads as read. Also mark duplicates as read; for instance, many announcements are sent to more than one mailing list, we only need to keep one.
4. Refresh the folder and remove everything that was irrelevant. This was just our first pass, but we removed a bunch of email we didn’t need.
5. Now that we have a shorter list of items that may affect Gentoo and may need bugs created, let’s continue the process. You can use the following incredibly simple bash function to help determine if a vulnerability report applies to a package in the tree:
   

CODE Simple BASH function to search Portage

function eixs (){
    eix $1;
    eix -S $1;
}

1. With that function at the ready, take apart the subject of a report and search using the keywords. For example, faced with the email subject of CSRF in Hopeless CMS from Lamer Systems, search using eixs hopeless, followed by eixs lamer. Seeing the welcome response of “No matches found” you can rest relatively assured that the Hopeless CMS from Lamer Systems is not in the tree and you do not need to carry this particular issue forward. Satisfied that this issue does not affect us, return to your mail client and mark the email thread for this issue as read. (If you happen to be following along, you will have noticed that eixs lamer would in fact return dev-db/flamerobin which is described as “A database administration tool for Firebird DBMS.” This clearly is not the content management system from Lamer Systems. Same result in the end, you can ignore the email without even opening it.)
2. Now you have an even shorter list of potential issues in the “Unread and Flagged” email folder and you are pretty sure they apply to packages in the tree. You can verify that by reading the vulnerability reports, expanding the threads and reading any follow-up emails, and referencing either our local portage tree or http://packages.gentoo.org. If after reading the report you are unsure if it applies to the package cat-foo/bar, follow the homepage link in the eix output. After doing so, it should be clear whether or not the package in the report is the same as the package in the tree. If it is the same, continue the process; if it is not, mark the thread as read and don’t look back.
3. After you’ve done all that, and you have a reduced the number of potential issues even further, you need to make sure there isn’t an existing Gentoo bug. Again, this isn’t hard, but here are a few tips that may save you time:
   • Modify your default search parameters to include resolved bugs as well as open bugs. Without this, you may miss bugs that have already been opened and dealt with.
   • If the vulnerability report contains a CVE, search using that CVE ID, and do so without the second hyphen. Many bugs include multiple CVE IDs and the convention used on the team is to include, for example, CVE-2011-1234 and CVE-2011-4321 as CVE-2011-{1234,4321}. This means that searching for CVE-2011-1234 would miss an existing bug, while ‘CVE-2011 1234′ would not.
   • If searching by CVE is not possible or helpful, search ALL bugs with the correct category/package-name in the bug Summary field. This may uncover an existing bug titled “category/package-name security bump” or the like.
4. If you’ve made it this far–both in the scouting process and through this article–well done! You may have a legitimate issue and you should go ahead and open the bug using the guidance from the Padawans doc.

All of the ideas above will not prevent you from opening a duplicate bug once in a while. It will however reduce them to a rare occurrence. But, if it so happens that you open a bug that is ultimately marked as a duplicate, take a look at the first bug and try to identify why it didn’t turn up when you searched. It will help you the next time around.