Open Source Security Updates Why it's Different; What you Should Know Josh Bressers Friday, 11 May 2007

Define: Open Source What is Open Source? ● A group of individuals across the world working together ● It's not uncommon for many of these individuals never to have met in person The source code is available The shipped binaries are built in house

Define: Distribution (vendor) Collection of software (mostly open source) ● Distributions typically do not write most of the software they ship Projects usually are not distributors ● This is not always true; many of the larger projects are also distributors ● This poses a unique challenge for keeping an Open Source distribution secure

Security Updates What is a security flaw? CVE NVD Severity Sources Embargoed Issues

Security Flaw A security bug is a software bug that benefits someone other than intended beneficiaries in the intended ways.

CVE

NVD

Severity Based on a technical assessment of the flaw, not the threat ● Unique to each Red Hat product ● Determines the priority through Engineering and QA Compatible withing rankings used by Microsoft and Apache

Sources Where does this information come from?

Embargoed Issues Sometimes a flaw needs to be kept a secret ● This is often for the good of the community ● Can help give vendors time to create a fix to help prevent the creation of a worm An extra challenge for Open Source projects ● CVS and mailing lists are usually public

Red Hat Security Response Team What is the Red Hat Security Response Team? ● Worldwide group of individuals responsible for fixing security bugs in Red Hat products What does the team do? ● Understands flaws ● This covers all shipped Red Hat products ● Assigns severity

Closed Source Security Updates One vendor ● Single-source accountability The customer must trust the vendor ● Not all vendors are always honest ● They've been caught before ● Open Source makes this very hard to do

Open Source Security Updates Community Involvement Backporting Multiple sources of information

Community Involvement Vendor Security Mailing list Public security mailing lists Public patches Public bugs

Backporting

Where do the patches come from? ● Vendors and projects often work together to produce the best possible patch Who verifies it? ● The Open Source nature of development helps keep quality high ● Once the flaw is public, the patch is available for anyone to analyze

Multiple Sources of Information ● Who can be trusted? ● Most security mailing lists have a terrible signal-to-noise ratio ● Who verifies the information? ● Sometimes there is a great deal of conflicting information ● Third party researchers ● Other vendors ● Other projects

Challenges Communication ● Upstream communication ● Vendor communication Leaks Lack of interest Backporting Binary only packages

Conclusion What can we make of all this? ● Hire a team of security professionals ● Find a third party you can trust

Questions?