Episode 175

Posted on Friday, Sep 2, 2022
An increased rate of CVEs in curl is a good thing, and we’ll tell you why, plus we cover security updates for the Linux kernel, Firefox, Schroot, systemd and more.

Show Notes

Overview

An increased rate of CVEs in curl is a good thing, and we’ll tell you why, plus we cover security updates for the Linux kernel, Firefox, Schroot, systemd and more.

This week in Ubuntu Security Updates

37 unique CVEs addressed

[USN-5474-2] Varnish Cache regression [00:43]

  • 1 CVEs addressed in Focal (20.04 LTS)
  • USN-5474-1 from Episode 164
  • incomplete fix in original update - required additional patches from upstream - thanks to community member who reported this and provided the associated debdiff to fix it

[USN-5572-2, USN-5579-1] Linux kernel vulnerabilities [01:27]

[USN-5580-1] Linux kernel (AWS) vulnerabilities [01:54]

  • 4 CVEs addressed in Xenial ESM (16.04 ESM)
  • 4.4 AWS 16.04 ESM
  • One of these is an OOB write in the framebuffer driver - covered previously in USN-5577-1 in Episode 174
  • Others:
    • OOB write in virtual terminal driver when changing VGA console fonts
    • OOB read in Packet network protocol -> info leak
    • Assertion failure (-> kernel panic) in netfilter when handling rules which truncate packets below their header size -> remote DoS

[USN-5582-1] Linux kernel (Azure CVM) vulnerabilities [02:42]

[USN-5588-1] Linux kernel vulnerability [03:43]

  • 1 CVEs addressed in Trusty ESM (14.04 ESM)
  • 3.13 GA

[USN-5589-1] Linux kernel vulnerabilities [03:56]

  • 2 CVEs addressed in Focal (20.04 LTS)
  • 5.4 GA/OEM/Raspi/lowlatency
  • OOB write in virtual terminal driver mentioned earlier
  • Improper control flow mgmt in Intel 10GbE PCIe driver - local DoS

[USN-5590-1] Linux kernel (OEM) vulnerability [04:24]

  • 1 CVEs addressed in Focal (20.04 LTS)
  • 5.14 OEM
  • Assertion failure on netfilter rules that truncate packets below their header size mentioned earlier

[USN-5578-2] Open VM Tools vulnerability [04:34]

[USN-5581-1] Firefox vulnerabilities [04:57]

[USN-5584-1] Schroot vulnerability [05:25]

  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
  • Not a tool that is normally used by most users / customers - BUT is used by many Ubuntu developers - interesting avenue for a supply chain attack perhaps?
  • DoS via crafted schroot names - one user could launch a schroot with a crafted name that would then result in schroot corrupting its internal state and then stopping it from launching any more schroot sessions for any other users on the machine

[USN-5586-1] SDL vulnerability [07:05]

  • 1 CVEs addressed in Xenial ESM (16.04 ESM)
  • UAF in handling of crafted video content on X11

[USN-5583-1] systemd vulnerability [07:14]

  • 1 CVEs addressed in Bionic (18.04 LTS)
  • Possible UAF when handling crafted DNS requests -> crash / RCE
  • Ask me about this one next week 😉

[USN-5585-1] Jupyter Notebook vulnerabilities [07:44]

Goings on in Ubuntu Security Community

Increased CVE activity in curl [08:09]

#!/bin/bash
for d in $(curl -s "https://ubuntu.com/security/cves.json?order=newest&package=curl&limit=100" | jq -r ".cves[].published"); do
  date +%s -d "$d";
done > curlhist

#!/usr/bin/gnuplot
binwidth = 60*60*24*365 # ~30days in seconds
bin(x,width)=width*floor(x/width) + width/2.0
set xdata time
set datafile missing NaN
set boxwidth binwidth
set xtics format "%Y" time rotate
set style fill solid 0.5 # fill style
set title 'Frequency of curl CVEs in the Ubuntu CVE Tracker by year'
plot 'curlhist' using (bin($1,binwidth)):(1.0) \
    smooth freq with boxes notitle
  • curl CVE frequency has increased in recent years
  • however is still less than what it was back in 2016
  • Daniel explains how for each CVE wounds his pride that he didn’t find it in the first place (or actually not introduce it) - but overall it is good they are being looked for and found and fixed
  • curl has a bug bounty - and this works as a good incentive
    • has paid out over $40kUSD since it started
  • This year though the 15 reports came from just 4 people
    • and 60% came from a single individual
    • shows that to do this kind of work you need to have a deep, intimate knowledge of the code - can’t just drive by and find bugs - need to spend a lot of time getting to know the code and protocols etc well to be able to find these sorts of issues
    • indicates that curl is a high quality project since it is hard to find security issues
    • long lived codebase that has been well studied and improved over the years
  • Speaking of being long-lived - Daniel also then looks at the average lifetime of each CVE in curl - like the Linux kernel, curl developers go back and try find out what commit introduced a particular vulnerability - they can then compare the time from when that original commit was introduced to when the commit which fixes the bug was made
  • On average, for all CVEs - 2,867 days - 7 years 10 months
    • For those in the past 12 months - 3,245 days - almost 9 years
  • I mentioned the Linux kernel - Kees Cook (ex Ubuntu Security) has done similar analysis using the data we collect in the Ubuntu CVE Tracker over the years and found that for kernel vulnerabilities the average lifetime is 5.5 years
  • In general, curl has had a steady rate of development of around 1300 commits per year since 2007
  • So on average the same amount of code churn is happening still (although this doesn’t tell us if say the same amount of new code is being written each year - perhaps this is more refactoring / cleanups over time?)
    • but if we assume it is the same amount of new code being written each year, but since the CVE lifetime is growing over time, then more CVEs are being found in the older code than newer code - and as such the quality of the code seems to be improving over time
    • we can clean a bunch of info from the dashboard:
      • test cases - these are growing linearly over time
      • number of CI jobs - also growing linearly over time
      • both indicate an increase in tooling to improve quality over time
  • Final thought: whilst on the surface the idea that curl has got more CVEs recently sounds bad, this is actually a good thing - it means these long lived vulnerabilties are being found and fixed - this is a good thing - and the bug bounty provides a good incentive to first encourage vulns to be looked for and found and then to make sure they get reported and hence fixed (and not say hoarded or sold to third parties etc)
  • Great graph showing the rate of vulns introduced over time and vulns being fixed over time
    • Shows vulns get introduced linearly but they are getting fixed exponentially - so over time the number of latent vulns in the curl codebase is decreasing - and this is definitely a good thing
    • Also shows the benefit of having a bug bounty - if you want vulns to get found and fixed you need to create an environment that encourages that - and what is more motivating than cold hard cash?

Get in contact