Sign up to save your podcasts
Or
Share Episode 219
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Episode 219
Overview
This week the Linux kernel project announced they will be assigning their own
CVEs so we discuss the possible implications and fallout from such a shift, plus
we cover vulnerabilities in the kernel, Glance_store, WebKitGTK, Bind and more.
This week in Ubuntu Security Updates
64 unique CVEs addressed
[LSN-0100-1] Linux kernel vulnerability (00:56)
application to request that the kernel do TLS by providing it the key etc -
internally the kernel then takes the data to be sent from userspace and frames
it into a scatter list (describes the regions in memory containing the data to
be sent) - uses the kernel crypto API which is asynchronous
kernel to enter a code path where the network packet is freed before it has
finished being processed by the crypto API -> UAF
Kernel type
22.04
20.04
18.04
16.04
14.04
aws
100.1
100.1
100.1
100.1
—
aws-5.15
—
100.1
—
—
—
aws-5.4
—
—
100.1
—
—
aws-6.2
100.1
—
—
—
—
aws-hwe
—
—
—
100.1
—
azure
100.1
100.1
—
100.1
—
azure-4.15
—
—
100.1
—
—
azure-5.4
—
—
100.1
—
—
azure-6.2
100.1
—
—
—
—
gcp
100.1
100.1
—
100.1
—
gcp-4.15
—
—
100.1
—
—
gcp-5.15
—
100.1
—
—
—
gcp-5.4
—
—
100.1
—
—
gcp-6.2
100.1
—
—
—
—
generic-4.15
—
—
100.1
100.1
—
generic-4.4
—
—
—
100.1
100.1
generic-5.15
—
100.1
—
—
—
generic-5.4
—
100.1
100.1
—
—
gke
100.1
100.1
—
—
—
gke-5.15
—
100.1
—
—
—
gkeop
—
100.1
—
—
—
hwe-6.2
100.1
—
—
—
—
ibm
100.1
100.1
—
—
—
ibm-5.15
—
100.1
—
—
—
linux
100.1
—
—
—
—
lowlatency-4.15
—
—
100.1
100.1
—
lowlatency-4.4
—
—
—
100.1
100.1
lowlatency-5.15
—
100.1
—
—
—
lowlatency-5.4
—
100.1
100.1
—
—
To check your kernel type and Livepatch version, enter this command:
canonical-livepatch status
[USN-6624-1] Linux kernel vulnerabilities
[USN-6625-1] Linux kernel vulnerabilities
[USN-6626-1] Linux kernel vulnerabilities
[USN-6625-2] Linux kernel (GCP) vulnerabilities
[USN-6628-1] Linux kernel (Intel IoTG) vulnerabilities
[USN-6626-2] Linux kernel vulnerabilities
[USN-6608-2] Linux kernel (NVIDIA) vulnerabilities
[USN-6635-1] Linux kernel (GCP) vulnerabilities
[USN-6627-1] libde265 vulnerabilities (04:10)
(totem) in particular
couple different researchers fuzzing - assertion failure, NULL ptr derefs, OOB
reads, UAF, OOB writes etc - impact then ranging from DoS to possible code
execution
[USN-6630-1] Glance_store vulnerability (05:26)
(images) via different storage technologies (local file-system, HTTP, RBD,
Swift, S3 and others)
user then able to read the logs could see the access key and hence potentially
get access to the S3 bucket (would also need the secret key too and this was
never logged so impact minimal)
[USN-6631-1] WebKitGTK vulnerabilities (06:26)
crafted web content - possibly exploited in the wild”
[USN-6632-1] OpenSSL vulnerabilities (07:13)
[USN-6633-1] Bind vulnerabilities (07:33)
regular DNS queries / responses, the other in DNSSEC - “KeyTrap” - also
affects resolvers not just servers (so any client system as well that is doing
lookups) - affects the DNSSEC standard itself and hence affects various other
implementations as well
DNSKEY records - these contain a cryptographic signature and public key
respectively - so when trying to validate the DNSSEC record need both - and so
will end up trying every possible RRSIG with every possible DNSKEY to find a
match - with no bound on the computation time (and if implemented in a single
threaded manner) - can completely DoS the server / client etc.
[USN-6634-1] .NET vulnerabilities (09:47)
and a DoS in the SignalR library (allows a server to send asynchronous
notifications to client-side web applications) able to be triggered by a
malicious client
[USN-6629-1, USN-6629-2] UltraJSON vulnerabilities (10:34)
memory corruption, stack buffer overflow
Goings on in Ubuntu Security Community
Linux kernel becomes a CNA (11:25)
Earlier this week, Greg Kroah-Hartman (one of the more famous Linux kernel
developers - responsible for the various stable kernel trees / releases plus
various subsystems within the kernel - also wrote one of the most popular
books on Linux Kernel Driver development - even if it is woefully outdated
nowadays) announced that the Linux kernel project itself has been accepted as
a CNA by MITRE and would start issues CVEs for the vulnerabilities found
within the kernel itself
Historically the upstream kernel developers and Greg himself have been quite
disparaging of the CVE process / ecosystem and essentially saying that CVEs
for the kernel are meaningless since that all bugs are potentially security
issues and there are so many fixes that go into the kernel of which the
security impact is not clear, that the only way to stay secure is to track one
of the supported upstream stable kernel trees - otherwise CVEs would be issued
for basically every commit that goes into one of the stable trees
to use the stable trees (and hence the Ubuntu Kernel team continuously
incorporates all the fixes from the upstream stable kernel trees into the
different Ubuntu kernels) we still see a lot of value in the CVE ecosystem -
and also we do not agree that all fix commits warrant a CVE
It was not then surprising to see that in the initial announcement there was a
statement that:
Note, due to the layer at which the Linux kernel is in a system, almost any
bug might be exploitable to compromise the security of the kernel, but the
possibility of exploitation is often not evident when the bug is
fixed. Because of this, the CVE assignment team is overly cautious and assign
CVE numbers to any bugfix that they identify.
This led many (including us) to fear that the kernel CNA would be issuing an
extremely high volume of CVEs which would effectively overwhelm the CVE
process and make it unworkable - for instance, LWN calculated that for the 6.1
stable kernel has had over 12,000 fixes applied to it over the past year. So
this leaves a huge scope for many CVEs to be possibly assigned - and as a
comparison in total across all software / hardware devices etc in 2023 there
was 29,000 CVEs assigned. So that could mean the kernel itself would possibly
become responsible for at least a quarter of all CVEs in the future.
Greg has some prior form in this space as well since in 2019 he gave a talk
where he suggested one way the kernel community could help fix the issue of
CVEs being erroneously assigned against the kernel would be to start doing
exactly this and assigning a CVE for every fix applied to the kernel and hence
overwhelm the CVE ecosystem to (in his words) “burn it down”.
Also the GSD project (Global Security Database - set up as an alternate /
competitor to CVE) was doing exactly this - tracking a huge number of fixes
for the stable trees and assigning them GSD IDs - as per
https://osv.dev/list?ecosystem=Linux it tracks 13573 issues
Thankfully though, this plan seems to have moderated over the past few days -
after Greg posted a patch set to the LKML documenting the process, he
clarified in a follow-up email that this would not be the case, and instead
that CVEs will only be assigned for commits which appear to have a security
relevant impact. How they actually do that remains to be seen, and his comment
that “we (will) know it when we see it” doesn’t exactly put me at ease (since
it is very easy to miss the security implications of any particular commit) at
least this helps allay the fears that there would be a tidal wave of CVEs
being assigned.
One outstanding issue which I directly asked Greg about is how they are
actually tracking fixes for CVEs - since in their model, a CVE is equivalent
to the commit which fixes the issue - however for lots of existing kernel CVEs
that get assigned by other CNAs like Canonical or Red Hat etc, the fix
comprises multiple commits
Greg says the whole process is quite complex and whilst their existing scripts
want a one-to-one mapping from CVEs to commits they do plan to fix this in the
future.
So will be interesting to see what things they will end up assigning
CVEs. Also will be interesting to see how the interaction with security
researchers plays out. Since their process is heavily skewed to the CVE
corresponding to the fix commit AND they state that this must be in one of the
stable trees for a CVE to be assigned, it doesn’t leave a lot of room for
responsible disclosure. They do say they can assign a CVE for an issue before
it is resolved with a commit to one of the stable trees, but ideally these
details would get disclosed to distros and others ahead of the CVE details
being released to the public. I also asked Greg about this but am awaiting a
response.
Get in contact
View all episodes
By Ubuntu Security Team
4.8
1010 ratings
Overview
This week the Linux kernel project announced they will be assigning their own
CVEs so we discuss the possible implications and fallout from such a shift, plus
we cover vulnerabilities in the kernel, Glance_store, WebKitGTK, Bind and more.
This week in Ubuntu Security Updates
64 unique CVEs addressed
[LSN-0100-1] Linux kernel vulnerability (00:56)
application to request that the kernel do TLS by providing it the key etc -
internally the kernel then takes the data to be sent from userspace and frames
it into a scatter list (describes the regions in memory containing the data to
be sent) - uses the kernel crypto API which is asynchronous
kernel to enter a code path where the network packet is freed before it has
finished being processed by the crypto API -> UAF
Kernel type
22.04
20.04
18.04
16.04
14.04
aws
100.1
100.1
100.1
100.1
—
aws-5.15
—
100.1
—
—
—
aws-5.4
—
—
100.1
—
—
aws-6.2
100.1
—
—
—
—
aws-hwe
—
—
—
100.1
—
azure
100.1
100.1
—
100.1
—
azure-4.15
—
—
100.1
—
—
azure-5.4
—
—
100.1
—
—
azure-6.2
100.1
—
—
—
—
gcp
100.1
100.1
—
100.1
—
gcp-4.15
—
—
100.1
—
—
gcp-5.15
—
100.1
—
—
—
gcp-5.4
—
—
100.1
—
—
gcp-6.2
100.1
—
—
—
—
generic-4.15
—
—
100.1
100.1
—
generic-4.4
—
—
—
100.1
100.1
generic-5.15
—
100.1
—
—
—
generic-5.4
—
100.1
100.1
—
—
gke
100.1
100.1
—
—
—
gke-5.15
—
100.1
—
—
—
gkeop
—
100.1
—
—
—
hwe-6.2
100.1
—
—
—
—
ibm
100.1
100.1
—
—
—
ibm-5.15
—
100.1
—
—
—
linux
100.1
—
—
—
—
lowlatency-4.15
—
—
100.1
100.1
—
lowlatency-4.4
—
—
—
100.1
100.1
lowlatency-5.15
—
100.1
—
—
—
lowlatency-5.4
—
100.1
100.1
—
—
To check your kernel type and Livepatch version, enter this command:
canonical-livepatch status
[USN-6624-1] Linux kernel vulnerabilities
[USN-6625-1] Linux kernel vulnerabilities
[USN-6626-1] Linux kernel vulnerabilities
[USN-6625-2] Linux kernel (GCP) vulnerabilities
[USN-6628-1] Linux kernel (Intel IoTG) vulnerabilities
[USN-6626-2] Linux kernel vulnerabilities
[USN-6608-2] Linux kernel (NVIDIA) vulnerabilities
[USN-6635-1] Linux kernel (GCP) vulnerabilities
[USN-6627-1] libde265 vulnerabilities (04:10)
(totem) in particular
couple different researchers fuzzing - assertion failure, NULL ptr derefs, OOB
reads, UAF, OOB writes etc - impact then ranging from DoS to possible code
execution
[USN-6630-1] Glance_store vulnerability (05:26)
(images) via different storage technologies (local file-system, HTTP, RBD,
Swift, S3 and others)
user then able to read the logs could see the access key and hence potentially
get access to the S3 bucket (would also need the secret key too and this was
never logged so impact minimal)
[USN-6631-1] WebKitGTK vulnerabilities (06:26)
crafted web content - possibly exploited in the wild”
[USN-6632-1] OpenSSL vulnerabilities (07:13)
[USN-6633-1] Bind vulnerabilities (07:33)
regular DNS queries / responses, the other in DNSSEC - “KeyTrap” - also
affects resolvers not just servers (so any client system as well that is doing
lookups) - affects the DNSSEC standard itself and hence affects various other
implementations as well
DNSKEY records - these contain a cryptographic signature and public key
respectively - so when trying to validate the DNSSEC record need both - and so
will end up trying every possible RRSIG with every possible DNSKEY to find a
match - with no bound on the computation time (and if implemented in a single
threaded manner) - can completely DoS the server / client etc.
[USN-6634-1] .NET vulnerabilities (09:47)
and a DoS in the SignalR library (allows a server to send asynchronous
notifications to client-side web applications) able to be triggered by a
malicious client
[USN-6629-1, USN-6629-2] UltraJSON vulnerabilities (10:34)
memory corruption, stack buffer overflow
Goings on in Ubuntu Security Community
Linux kernel becomes a CNA (11:25)
Earlier this week, Greg Kroah-Hartman (one of the more famous Linux kernel
developers - responsible for the various stable kernel trees / releases plus
various subsystems within the kernel - also wrote one of the most popular
books on Linux Kernel Driver development - even if it is woefully outdated
nowadays) announced that the Linux kernel project itself has been accepted as
a CNA by MITRE and would start issues CVEs for the vulnerabilities found
within the kernel itself
Historically the upstream kernel developers and Greg himself have been quite
disparaging of the CVE process / ecosystem and essentially saying that CVEs
for the kernel are meaningless since that all bugs are potentially security
issues and there are so many fixes that go into the kernel of which the
security impact is not clear, that the only way to stay secure is to track one
of the supported upstream stable kernel trees - otherwise CVEs would be issued
for basically every commit that goes into one of the stable trees
to use the stable trees (and hence the Ubuntu Kernel team continuously
incorporates all the fixes from the upstream stable kernel trees into the
different Ubuntu kernels) we still see a lot of value in the CVE ecosystem -
and also we do not agree that all fix commits warrant a CVE
It was not then surprising to see that in the initial announcement there was a
statement that:
Note, due to the layer at which the Linux kernel is in a system, almost any
bug might be exploitable to compromise the security of the kernel, but the
possibility of exploitation is often not evident when the bug is
fixed. Because of this, the CVE assignment team is overly cautious and assign
CVE numbers to any bugfix that they identify.
This led many (including us) to fear that the kernel CNA would be issuing an
extremely high volume of CVEs which would effectively overwhelm the CVE
process and make it unworkable - for instance, LWN calculated that for the 6.1
stable kernel has had over 12,000 fixes applied to it over the past year. So
this leaves a huge scope for many CVEs to be possibly assigned - and as a
comparison in total across all software / hardware devices etc in 2023 there
was 29,000 CVEs assigned. So that could mean the kernel itself would possibly
become responsible for at least a quarter of all CVEs in the future.
Greg has some prior form in this space as well since in 2019 he gave a talk
where he suggested one way the kernel community could help fix the issue of
CVEs being erroneously assigned against the kernel would be to start doing
exactly this and assigning a CVE for every fix applied to the kernel and hence
overwhelm the CVE ecosystem to (in his words) “burn it down”.
Also the GSD project (Global Security Database - set up as an alternate /
competitor to CVE) was doing exactly this - tracking a huge number of fixes
for the stable trees and assigning them GSD IDs - as per
https://osv.dev/list?ecosystem=Linux it tracks 13573 issues
Thankfully though, this plan seems to have moderated over the past few days -
after Greg posted a patch set to the LKML documenting the process, he
clarified in a follow-up email that this would not be the case, and instead
that CVEs will only be assigned for commits which appear to have a security
relevant impact. How they actually do that remains to be seen, and his comment
that “we (will) know it when we see it” doesn’t exactly put me at ease (since
it is very easy to miss the security implications of any particular commit) at
least this helps allay the fears that there would be a tidal wave of CVEs
being assigned.
One outstanding issue which I directly asked Greg about is how they are
actually tracking fixes for CVEs - since in their model, a CVE is equivalent
to the commit which fixes the issue - however for lots of existing kernel CVEs
that get assigned by other CNAs like Canonical or Red Hat etc, the fix
comprises multiple commits
Greg says the whole process is quite complex and whilst their existing scripts
want a one-to-one mapping from CVEs to commits they do plan to fix this in the
future.
So will be interesting to see what things they will end up assigning
CVEs. Also will be interesting to see how the interaction with security
researchers plays out. Since their process is heavily skewed to the CVE
corresponding to the fix commit AND they state that this must be in one of the
stable trees for a CVE to be assigned, it doesn’t leave a lot of room for
responsible disclosure. They do say they can assign a CVE for an issue before
it is resolved with a commit to one of the stable trees, but ideally these
details would get disclosed to distros and others ahead of the CVE details
being released to the public. I also asked Greg about this but am awaiting a
response.
Get in contact