Are Ubuntu packages security audited?

I'm unsure what the current procedure for package security for Ubuntu is.

When something ends up in the Ubuntu package repositories, are the package audited by a central, trusted team and if so what level of auditing takes place?

I'm interested on whether packages are checked for:

• Regular matching against known vulnerabilities/CVEs (as in, package maintainers are notified in realtime of CVE releases, and packages with unpatched (by vendors) CVEs removed).
• Obvious malicious code (eg reverse shells, random shell code, trojans)
• Poor code quality (eg unintended command injection vulnerabilities)
• Full security audit of all code for vulnerabilities

There's several 'pockets' in the Ubuntu Archives that represent different types of support: packages in main are supported by Canonical while packages in universe are supported by the community.

Packages must be in main to be in the default installs of Ubuntu.

During the development cycle developers can propose packages to include in main. Part of this process determines if a package may be security relevant (eg run with privileges but interact with untrusted users, parse complicated formats, etc) and if so, asks the Ubuntu Security Team to perform a quick security review. I do many of these reviews.

I can't give each proposed package a full in-depth audit. I'm looking to quickly learn if a package appears to have been developed in a professional manner with modern safe programming standards.

We inspect the binary outputs to make sure that compiled programs and libraries have been compiled with standard security mitigations like Position Independent Execution support for better Address Space Layout Randomization, Stack Canaries, Fortify Source (catches a handful of common C problems), and Bind Now and RELRO (mitigates exploits that abuse symbol linking). (We have a mitigation for the Stack Clash flaw turned on, as well as support for Intel's Control Flow Integrity checks in some newer processors, but hardening-check doesn't yet know how to check for those.) We also verify any sudo rules, udev rules, setuid or setgid bits, packaging scripts, startup scripts, etc., to make sure the package doesn't have unexpected sources of privilege.

We inspect the source code with automated scanners such as Coverity, cppcheck, and shellcheck. We wrote simple tools to help us spot common programming flaws (these tools aren't intended to detect flaws but provide a very quick way to inspect eg all memory allocation routines, all networking routines, all use of privileged operating system functions, etc) that allow us to quickly browse lines of code in the package that are likely to have flaws.

We may find flaws but more importantly we'll learn if the developers were properly defensive when writing code. We'll get a feeling for how the software works, how it was developed, and what threat model the authors have in mind.

We occasionally run fuzzing. (Running the fuzzing is the easy (and fun) part -- to get any value out of this, the crashes also need to be investigated far enough to fix them. This is the expensive part. I'd like to do more of this in the future but far more valuable is for people to contribute fuzz testing to the project that can be run in the oss-fuzz infrastructure, and provide results directly to the authors. Same goes for Coverity -- running Coverity directly on every commit and getting emails when new issues are added is more valuable than a single "here's a list of issues Coverity found".)

Depending on what we find in the audit, we may accept the package as-is, or we may ask for changes, or we may not accept the package into main. Some project authors have been fantastic to work with and go above and beyond to address feedback. (Nearly all project authors are happy someone is reading their code and providing feedback.)

All these steps are one-time tasks that determine which packages go into main.

The Ubuntu Security Team performs daily CVE Triage tasks. We have a database of CVEs that we use to track which packages are affected by which flaws, in which releases of Ubuntu, which versions are fixed, where fixes can be found, supporting documentation, mitigations that may help reduce the importance or impact of problems, and the priority we'll use when determining which packages to fix next. We collect data from MITRE, NVD, Debian, mail lists (public and private), etc.

Security researchers and users report issues to us; we investigate as we can, and forward issues to upstream developers when appropriate.

Packages in main get full security support: we backport patches from upstream authors, write patches, and test the packages to reduce the risks of introducing regressions. We can't catch all regressions but our wider perspective allows us to catch some regressions that upstream developers can miss. As limitations or regressions or incomplete patches are found we work with upstream developers and the wider community as needed to improve fixes.

Packages in universe are community supported: members of the community will prepare fixes for issues, build the packages, test the packages, and give us patches to build and distribute. We verify the authenticity of the changes, verify the packaging changes, build the new packages, and distribute them. This does unfortunately make it harder to know what is well-supported and what is not. (We're working on this.) Some of our enterprise users will use only packages from main to make sure they are getting security support for their environments.

Anyone can submit debdiffs for us to sponsor: open a bug on Launchpad's page for the source package, mark it Public Security, attach a debdiff, describe your testing, and subscribe ubuntu-security-sponsors. Preparing the changes may look overwhelming at first but there's a large community around working with Debian packages that can help.

We don't have a project in place for comprehensive re-auditing packages that are already in main. We read a lot of patches and look for similar flaws in packages as well as look at surrounding code but do not re-review packages from the ground up very often.

We submit our LTS releases for FIPS, CC, STIG, and CIS certifications. These provide regulatory frameworks for auditing cryptographic and security-sensitive packages with different standards. The certifications are important for certain industries. This work influences and feeds back into the distribution. The auditors aren't necessarily looking for flaws so much as adherence to process, minimum security standards and configurations, etc. However, the double-checks of correctness on particularly important packages is vital reassurance to some users.

Outside of the Ubuntu Security Team, we also enjoy the combined benefits of two wonderful communities: both Debian and Ubuntu developer communities have built relationships with upstream developers and downstream users and fellow developers elsewhere in the FOSS ecosystem. Everyone works together to provide oversight, feedback, cooperation, communication. No software is perfect but the combined efforts of our communities gives great results.