Gentoo Security Team: Scouting Tips

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. I wish I could say that this job is out-of-this-world-fantastic-fun. But that just isn’t always the case. At the same time I think that done right, it doesn’t have to be that bad.

So what does “done right” even mean? I am not sure. I can only tell you what “right” means for me, and some of the things I’ve done in recent months to learn of new issues quickly without being buried beneath an unactionable mound of email. I should mention too that I don’t think this is a conclusive list that will work wonders for everyone. Certainly not. So if you’re doing something similar that works well for you, please do let me know about it.

So all that said, let’s dive into it…

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 the ones that I follow, with my opinion about their utility in this context:

• 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.
• Secunia Advisories: The nice folks at Secunia publish free advisories for an enormous number of open source packages. The up-side to receiving these advisories is that they are concise, accurate and very consistent in their reporting of information. The downside is that you receive essentially duplicate information as Secunia publishes new advisories when each of the major Linux distributions updates an affected package. For example, a Secunia advisory for “Heap overflow in Package ABC” is very helpful; however, an advisory for “Red Hat updates Package ABC” is less so in this context.
• Watch security-response-team@redhat.com on http://bugzilla.redhat.com: Just recently I began watching the Red Hat Security Team on their bugzilla instance. This is accomplished using a similar process to following our own security team, and so far, I think doing so is very worthwhile. 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.
• Full-Disclosure: This mailing list is used by folks from around the word to shout vulnerability information to the world. And, to shout just about everything else that pleases them too. Membership on this list is required if you plan to ultimately become part of the team and send GLSAs, but day-to-day, this list is pretty noisy and can easily be replaced with the previous resources. That said, it is probably worth subscribing to this list and compensating for the noise with an active delete key.
• Bugtraq: Very much similar to Full-Disclosure, the Bugtraq list is used to publicly discuss vulnerabilities. Subscription is optional for scouting, but I would recommend lurking, again compensating by ignoring everything not relevant.

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 in my opinion, to minimize the number of emails you read without missing items that may affect Gentoo.

Here is how I set myself up to do exactly that.

• 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. Breaking sources into individual folders sounds great–trust me, I am very type A too–but in this case, it only leads 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.
• 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, btw.)
• 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.

Now that we have a shorter list of items that may affect Gentoo and may need bugs created, let’s continue the process. I use the following incredibly simple (read: borderline stupid) bash function to help me determine if a vulnerability report applies to a package in the tree:

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

With that function at the ready, I 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

I search using eixs hopeless, followed by eixs lamer. Seeing the welcome response of “No matches found” I can rest relatively assured that the Hopeless CMS from Lamer Systems is not in the tree and I do not need to carry this particular issue forward. Satisfied that this issue does not affect us, I return to my 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 the boys at Lamer Systems. Same result in the end, we can ignore the email without even opening it.

Now we have an even shorter list of potential issues in our “Unread and Flagged” email folder and we are pretty sure they apply to packages in the tree. We 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 I am unsure it applies to the package cat-foo/bar I browse to cat-foo/bar’s page on http://packages.gentoo.org and then follow the link to the package’s homepage. 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 we trudge on in the process; if it is not, mark the thread as read and don’t look back.

I do have one more small tip that I’ll share here. I have added a Firefox keyword of “pgo” for the search box on packages.gentoo.org. This lets me quickly open a tab in firefox and type…

…to determine if tor is in the tree or to verify which versions of tor are in the tree. Seems silly, but when you have too many emails, every few seconds saved is a good thing.

After you’ve done all that, and you have a reduced the number of potential issues even further, we 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.

If you’ve made it this far–both in the scouting process and through this post–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.

Like I said 1500+ words ago, I don’t believe these ideas will be perfect for everyone. So if you have something better, or perhaps you think that I am completely off-my-rocker, let me know!