pkgsrc Security

Adrian Portelli < adrianp@NetBSD.org >

TNF

Talk Overview

• pkgsrc security officer group
• Tracking and managing
• Getting stuff fixed
• Tools of the trade
• The future . . . ?
• Closing comments

pkgsrc security officer group

• Huh ? When did this happen - About mid Feb 2005
• Current membership is: adrianp@ salo@ reed@ tron@ and wiz@
• Why ?
  • Needed to be a more co-ordinated approach to monitoring for 3rd party security advisories
  • Making sure relevant commits make it to pullup requests for the last pkgsrc stable branch cut
  • Automated reporting so we know the status of issues in HEAD and the latest stable branch

pkgsrc security officer group

• Why ? (continued)
  • Keeping pkg-vulnerabilities up to date and accurate
  • Provide an avenue for users to inform us of security issues that are specific to pkgsrc
  • Current limitations
  • Future directions

pkgsrc security officer group

• Just starting off . . .
• Proper management of vulnerabilities by using RT (industrial strength ticketing system)
• Dedicated internal mailing list for pkgsrc s.o. related discussions
• Sell, sell, sell

Tracking and managing

• Monitoring of various 3rd party security mailing lists (e.g. secunia, [Vulnwatch] and mutt)
• Need to be careful to keep the noise down and the quality up
• Manually forwarding any appropriate advisories
• Manually adding issues
• How do you know you're catching all the vulnerability announcements that could relate to pkgsrc ?

Tracking and managing

• Every email that comes into our advisory subscription list gets an RT ticket
• We can also manually enter tickets and forward on emails which will become tickets as well
• pkgsrc s.o.'s then login to RT and deal with any issues
• Anything that's not related to pkgsrc gets rejected
• Anything that's a duplicate is marked as such and then immediately closed

Getting stuff fixed

• The tickets that are left have a defined workflow to be followed before then can be marked as closed:
  • Entry added to pkg-vulnerabilities file
  • Maintainer notified
  • Fixed in HEAD
  • Pullup requested for stable branch
  • Fixed in latest stable branch
• There can be many delays and exceptions along this path

Getting stuff fixed

• Why the hell isn't my fscking package fixed yet - Are you guys all on crack or something ?
• Why are there delays ?
  • Backporting fixes from CVS trees
  • Poor information from software authors
  • Software author delays
  • The old "We don't think it's that important" line
  • Testing new packages
  • Unmaintained software
  • Verification of the issue

Tools of the trade

• < pkgname >/distinfo contains SHA1 and RMD160 hashes of all package source files and NetBSD patches (i.e. patches/*)
• Recently updated to include RMD160 due to issues with SHA1 collisions (thanks agc@ !)
• If it's changed - you'll know about it
• etc/daily (including etc/security), etc/weekly and etc/monthly cron jobs (NetBSD specific)
• pkg-vulnerabilities is your friend

Tools of the trade

• audit-packages is your friend (security/audit-packages)
• It's just a shell script - it doesn't byte
• run download-vulnerability-list
• run audit-packages
• It will tell you what security issues there are with packages that are currently installed on your system
• Currently about 1173 active entries

Tools of the trade

• pkg-vulnerabilities file content
ethereal<0.10.11 remote-code-execution http://www.ethereal.com/appnotes/enpa-sa-00019.html

• Stored on ftp.netbsd.org
• If you try and install a package listed in pkg-vulnerabiltiies the make will fail
• You can override this and choose to install it
• Often the first thing that happens once we are aware of a security issue that effects pkgsrc

Tools of the trade

• Automated reports of current security issues and their status
• Script put together by he@ (with some help from hubertf@)
• Gets run periodically and tell us:
  • New issues
  • New issues not fixed in HEAD or stable
  • New issues fixed in HEAD but not pulled up into stable
  • New issues fixed in HEAD and stable

Tools of the trade

• Just-in-time su
• No longer need to build packages as root
• Build as an unprived user then su when doing the install
• Portable feature (e.g. uses sudo on OS X)
• This, in combination with the distinfo hashes, helps users protect their systems against trojaned package source files

Tools of the trade

• Digitally signing binary packages
• We have the capability
• Not a big uptake
• Why ?
• We should really be doing this

The future . . . ?

• Make users aware of our presence
• Make developers (more) aware of our presence
• Clearly define and document our role
• Better communication paths with users
• Active WWW presence
• Register packages installed via bootstrap
• Register bootstrap itself

The future . . . ?

• VuXML (http://www.vuxml.org/)
• Used by the FreeBSD project
• At its core - the same functionality as pkg-vulnerabilities and audit-packages
• Provide a central data store where vulnerability information on packages are kept
• Allow users to download this file and give them a means to check their local systems

The future . . . ?

• What's wrong with the pkg-vulnerabilities file ?
  • No dates (there's always 'cvs log')
  • Only one external link is allowed
  • Sometimes it's hard to describe an issue as just three hyphenated words
  • Version matching is sub-optimal
• We may just decide to take the best features of VuXML and roll them into pkg-vulnerabilities

The future . . . ?

• VuXML file content

< vuln vid="5f003a08-ba3c-11d9-837d-000e0c2e438a" >
    < topic > sharutils -- unshar insecure temporary file creation < /topic >
    < affects >
      < package >
	< name > sharutils < /name >
	< range > < lt > 4.3.80 < /lt > < /range >
      < /package >
    < /affects >
    < description >
      < body xmlns="http://www.w3.org/1999/xhtml" >
	< p > An Ubuntu Advisory reports: < /p >

Closing comments

• Questions
• Comments
• Discussion

Closing comments

• Thanks for using pkgsrc !