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
This week in Ubuntu Security Updates
[USN-5474-2] Varnish Cache regression [00:43]
1 CVEs addressed in Focal (20.04 LTS)CVE-2020-11653 USN-5474-1 from Episode 164incomplete fix in original update - required additional patches fromupstream - 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]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)CVE-2022-33741 CVE-2022-33740 CVE-2022-26365 4.4 AWS 14.04 ESM + 4.4 generic etc 16.04 ESM + 14.04 ESM3 issues in Xen PV drivers - all memory management issuesSee USN-5572-1 from Episode 174[USN-5580-1] Linux kernel (AWS) vulnerabilities [01:54]
4 CVEs addressed in Xenial ESM (16.04 ESM)CVE-2022-36946 CVE-2022-20368 CVE-2021-33656 CVE-2021-33655 4.4 AWS 16.04 ESMOne of these is an OOB write in the framebuffer driver - covered previously inUSN-5577-1 in Episode 174
Others:OOB write in virtual terminal driver when changing VGA console fontsOOB read in Packet network protocol -> info leakAssertion failure (-> kernel panic) in netfilter when handling rules whichtruncate packets below their header size -> remote DoS
[USN-5582-1] Linux kernel (Azure CVM) vulnerabilities [02:42]
11 CVEs addressed in Focal (20.04 LTS)CVE-2022-28893 CVE-2022-1975 CVE-2022-1974 CVE-2022-1734 CVE-2022-1679 CVE-2022-1652 CVE-2022-1048 CVE-2022-0494 CVE-2022-2586 CVE-2022-2588 CVE-2022-34918 Azure Confidential Virtual Machines - implements FDE so that contents isprotected from VM host
5.4 kernel3 high priority vulns that allow a local unpriv user to privesc - firstcovered back in USN-5557-1 in Episode 172 - all in netfilter / network packet
scheduler subsystems
[USN-5588-1] Linux kernel vulnerability [03:43]
1 CVEs addressed in Trusty ESM (14.04 ESM)CVE-2022-2588 3.13 GA[USN-5589-1] Linux kernel vulnerabilities [03:56]
2 CVEs addressed in Focal (20.04 LTS)CVE-2021-33656 CVE-2021-33061 5.4 GA/OEM/Raspi/lowlatencyOOB write in virtual terminal driver mentioned earlierImproper 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)CVE-2022-36946 5.14 OEMAssertion failure on netfilter rules that truncate packets below their headersize mentioned earlier
[USN-5578-2] Open VM Tools vulnerability [04:34]
1 CVEs addressed in Xenial ESM (16.04 ESM)CVE-2022-31676 Privesc within guest - USN-5578-1 from Episode 174[USN-5581-1] Firefox vulnerabilities [04:57]
5 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)CVE-2022-38478 CVE-2022-38477 CVE-2022-38475 CVE-2022-38473 CVE-2022-38472 104.0 - usual mix of browser security issues - DoS, chrome UI spoofing, bypasssecurity restrictions, RCE via malicious web content
[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)CVE-2022-2787 Not a tool that is normally used by most users / customers - BUT is used bymany Ubuntu developers - interesting avenue for a supply chain attack perhaps?
DoS via crafted schroot names - one user could launch a schroot with a craftedname 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)CVE-2022-34568 UAF in handling of crafted video content on X11[USN-5583-1] systemd vulnerability [07:14]
1 CVEs addressed in Bionic (18.04 LTS)CVE-2022-2526 Possible UAF when handling crafted DNS requests -> crash / RCEAsk me about this one next week 😉[USN-5585-1] Jupyter Notebook vulnerabilities [07:44]
8 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)CVE-2022-29238 CVE-2022-24758 CVE-2020-26215 CVE-2019-9644 CVE-2019-10856 CVE-2019-10255 CVE-2018-21030 CVE-2018-19351 Another community contributed update - fixes various issues such as XSS, openredirect, info leak etc
Goings on in Ubuntu Security Community
Increased CVE activity in curl [08:09]
https://daniel.haxx.se/blog/2022/08/22/increased-cve-activity-in-curl/Daniel Stenberg (curl maintainer) put a poll on twitter asking if folks hadnoticed an increased rate in CVEs for curl in the last year
~45% - yes - and it’s good~2% - yes - and it’s bad~40% - no~12% - I don’t understand the questionThis can be seen easily on the curl dashboard https://curl.se/dashboard.htmlin particular on https://curl.se/dashboard1.html#vulns-per-year
We can see the same results from the Ubuntu CVE Tracker via jq and gnuplot(plus curl itself to fetch the data in the first place):
#!/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 yearshowever is still less than what it was back in 2016Daniel explains how for each CVE wounds his pride that he didn’t find it inthe 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 incentivehas paid out over $40kUSD since it startedThis year though the 15 reports came from just 4 peopleand 60% came from a single individualshows that to do this kind of work you need to have a deep, intimateknowledge 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 findsecurity issues
long lived codebase that has been well studied and improved over the yearsSpeaking of being long-lived - Daniel also then looks at the average lifetimeof 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 monthsFor those in the past 12 months - 3,245 days - almost 9 yearsI mentioned the Linux kernel - Kees Cook (ex Ubuntu Security) has done similaranalysis 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 commitsper year since 2007
So on average the same amount of code churn is happening still (although thisdoesn’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 timenumber of CI jobs - also growing linearly over timeboth indicate an increase in tooling to improve quality over timeFinal thought: whilst on the surface the idea that curl has got more CVEsrecently 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 timeShows vulns get introduced linearly but they are getting fixedexponentially - 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 getfound and fixed you need to create an environment that encourages that - and
what is more motivating than cold hard cash?
Get in contact
[email protected]#ubuntu-security on the Libera.Chat IRC networkubuntu-hardened mailing listSecurity section on discourse.ubuntu.com@ubuntu_sec on twitter
