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.
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
Azure Confidential Virtual Machines - implements FDE so that contents is
protected from VM host
5.4 kernel
3 high priority vulns that allow a local unpriv user to privesc - first
covered back in USN-5557-1 in Episode 172 - all in netfilter / network packet
scheduler subsystems
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
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/gnuplotbinwidth =60*60*24*365# ~30days in secondsbin(x,width)=width*floor(x/width) + width/2.0set xdata time
set datafile missing NaN
set boxwidth binwidth
set xtics format "%Y" time rotate
set style fill solid 0.5# fill styleset 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)
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?