1

Background Information

As I developer I am running multiple (partly virtual-)machines with Debian GNU/Linux and on some of these machines I work with highly confidential documents or dangerous executables like malware. (research and analytics)

Two days ago, after several high severity security vulnerabilities (DSA-5191-1) have been discovered and patched in the latest kernel, I noticed that one of the machines I use to handle potentially malicious/dangerous executables (in virtual machines) was running the 5.10.0-13 kernel (at the time of writing, 5.10.0-16 is the latest) due to the fact that the linux-image-5.10.0-13-amd64 package was directly installed without the linux-image-amd64 meta-package. Upon investigating I found out that this was because of a mistake that happened while installing the system and that the system was running on 5.10.0-13 since its install. (A few months ago, at that time the 5.10.0-13 kernel was the latest)

I had unattended-upgrades running and additionally checked daily and before every use for (security-)updates. I'm using rkhunter and was running it before and after every update, as well as before every use of the machine. Therefore, the linux-image-5.10.0-13-amd64 was at least up to date at all times.

After discovering this issue I immediately installed the linux-image-amd64 package (therefore the latest kernel) and purged the old one after a reboot.

System Information

  • OS: Debian 11 Bullseye
  • Arch: AMD64 (x86_64)
  • CPU: Intel
  • Is virtualized itself: no
  • Virtualization used on the system: yes (KVM + QEMU; x86_64 too)

Questions

  • What are the exact differences between the "number after dash" versions? I don't mean that in a "changelog-way" but more like "what makes the number go up?" (e.g. 5.10.0-13 with -13, 5.10.0-16 with -16) Are these just something like different "flavours" or actually versions that deprecate one another? I have read about ABI Versioning but the exact meaning of different numbers after the dash was never explained.
  • Is the 5.10.0-13 kernel still to be considered as secure and was my system at any point in time vulnerable to known (and in the latest kernel fixed) security vulnerabilities because of it running on the 5.10.0-13 kernel instead of 5.10.0-16?
  • Is the 5.10.0-13 kernel affected by DSA-5191-1? (I looked at the CVEs and the DSA for myself but the 5.10.0-13 kernel-package wasn't even in the list of packages.)
  • I use virtual machines on this system to handle potentially malicious/dangerous files. (as mentioned above) Could using the "wrong" kernel have weakened the security of the virtualization?
  • Overall, should I be in any way concerned or think of my system as potentially compromised because of this? Was this misconfiguration in any way and at any time posing any risk?
Improve this question
8
  • I'll write a more detailed answer in a minute, but the tl;dr is technically yes you were vulnerable to some security issues, but no you probably shouldn't worry.
    – forest
    Jul 29, 2022 at 0:11
  • Actually, this is a lot of questions in one. Could you narrow it down a bit? E.g. are you looking for a list of security fixes between 5.10.0-13 and 5.10.0-16? The changelog is massive. Note that Debian kernel 5.10.0-16 is based on Linux kernel 5.10.127, with custom Debian backports.
    – forest
    Jul 29, 2022 at 0:13
  • 1
    Kernels prior to 5.10.127-2 are vulnerable. Note that that's different from 5.10.0-amd64, which is the package name. The version numbers with the dash are releases from Debian which contain changes to the upstream vanilla Linux. So yes, you were vulnerable, but only to local privilege escalation (i.e. non-root user may be able to gain root).
    – forest
    Jul 29, 2022 at 0:20
  • 1
    I don't know, I didn't look into it deeply enough. You should be doing defense in depth (e.g. disabling unprivileged userns which one of the severe CVEs makes use of). Fun fact: Even the latest Debian kernels are sometimes (often) vulnerable to bugs that are only fixed in upstream, and it can take weeks or months for them to roll out the fixes publicly. So it's not like you're 100% safe until a bug is discovered and then you're 0% safe until you upgrade. Just keep as up to date as you can and use defense in depth, and you should be fine.
    – forest
    Jul 29, 2022 at 0:36
  • 1
    If you want to use the latest kernel, I suggest to move from Debian-based distibutions and switch to distributions with rolling releases, such as Arch. Today the latest linux kernel on Arch is 5.18.14. Your version dates back to december 2020. Not all security fixes gets backported by the Debian team, as they are understaffed.
    – A. Hersean
    Jul 29, 2022 at 9:00

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .