| ebarretto | mainek00n, hi! kernel packages are checked in different ways depending on the type of OVAL. Which one are you using? | 06:55 |
|---|---|---|
| mainek00n | ebarretto, Thanks for the mention. I use the OVAL for CVE units. | 09:45 |
| ebarretto | mainek00n, so that OVAL specifically is checking for the running kernel, by that I mean it checks against the return value of uname -r ... and uname doesn't have the .208 to it like the binary package version has | 09:54 |
| mainek00n | ebarretto, Typically, the check is done by the package name and version of Source in dpkg-query, right? | 10:12 |
| ebarretto | mainek00n, for other packages or for OCI OVAL yes | 10:12 |
| mainek00n | ebarretto, I think the Ubuntu Security Tracker Repository and the web display can bind the version to the source package, but why can't OVAL do this? | 10:15 |
| ebarretto | mainek00n, not sure I understand your question | 10:15 |
| ebarretto | mainek00n, what exactly are you trying to achieve? | 10:18 |
| mainek00n | ebarretto, I have asked this question before: https://irclogs.ubuntu.com/2022/11/27/%23ubuntu-security.html | 10:19 |
| mainek00n | ebarretto, I work on detecting vulnerable packages from package information collected by dpkg-query and OVAL. | 10:21 |
| ebarretto | mainek00n, the normal OVAL is about checking the running system and we made a decision that for kernel CVEs/USNs that means you should be checking for the running kernel instead of installed binaries, hence the uname comparison | 10:22 |
| ebarretto | mainek00n, if you still want to check against installed kernel binaries, then you need to default to the OCI-based OVAL | 10:22 |
| ebarretto | mainek00n, but that can give you false positives, as you can have multiple kernels installed | 10:23 |
| mainek00n | ebarretto, I know that false positives occur when multiple kernels are installed. | 10:27 |
| ebarretto | mainek00n, cool, is there any other doubt that I can help with? | 10:35 |
| mainek00n | ebarretto, I understand that the result of uname -r is in the form 5.15.0-53-generic, which has no information about the .208 part of 4.15.0-197.208. | 10:38 |
| mainek00n | ebarretto, I am very sorry, but could you please tell me how I should read tests, objects and states from the criteria in the Kernel Package and in which cases I can evaluate them as vulnerable? | 10:39 |
| ebarretto | mainek00n, sure, let me try to summarize it in a simpler way | 10:43 |
| mainek00n | ebarretto, Thank you so much, I compare OCI OVAL with the OVAL I always use. | 10:44 |
| ebarretto | mainek00n, so I created an OVAL with just that specific CVE, just to make things easier to read. You can see it here: https://paste.ubuntu.com/p/r6QX5RGwQD/ ... Specifically for the linux source package, we have two criterias (two tests): line 239 and line 240 and for it to result in vulnerable (true) both need to return true. The test on line 239 can be seen in line 402 and it is a uname_test, where we have an object and a state. The | 10:55 |
| ebarretto | object you can see on line 701 which is a uname_object as expected and what this object will do is actually run uname in the machine and hold this value in what they call an item. This object is what is going to be compared against what we have in the state. The state is a uname_state declared on line 936, where we say please look at the uname_object specifically the os_release field (which is the same as uname -r) and compare the | 10:55 |
| ebarretto | os_release value to 4.15.0-\d{3}-generic ... By that we are just trying to match that the kernel major version and family is the same. | 10:55 |
| ebarretto | before I move into the second test, I will give you some minutes so you can read and ask any questions about the first test | 10:55 |
| ebarretto | just as an example, this is what an uname item looks like when you evaluate your system: https://pastebin.ubuntu.com/p/JcSBSzKHkR/ | 10:59 |
| mainek00n | If the result of uname -r is 4.14.0.\d{3}-generic, does that mean this vulnerability is not covered? | 11:03 |
| mainek00n | OCI OVAL says 4.15.0-197.208 as the fixed version, even though all versions smaller than that are considered vulnerable. | 11:05 |
| ebarretto | it means your running kernel is not the same as the fixed version, so it would continue to try and match it in the other tests we have. But since 4.14 is not a listed in fixed versions, than it won't be checked | 11:05 |
| ebarretto | hmm not exactly, because OCI OVAL will try to match the binary kernel name, and the kernel name has the version on its name. For example: https://paste.ubuntu.com/p/F7qp9bnb78/ check line 1199, those are the packages it will try to match | 11:07 |
| ebarretto | if you have a 4.14, then it won't match as well | 11:07 |
| ebarretto | the OCI OVAL even has a problem that we are trying to fix, that you can get false negatives for the same major version. In this specific test a kernel linux-image-4.15.0-111-generic for example, won't match | 11:08 |
| ebarretto | we need to do some regex there to guarantee that it compares package names correctly | 11:09 |
| mainek00n | Is it because the Description only says linux-image-4.15.0-197-generic? | 11:10 |
| mainek00n | Sorry, I missed the variables section. | 11:11 |
| ebarretto | a 4.14 kernel would be another source package name entirely, as we don't tend to do major version upgrades, only minor | 11:13 |
| ebarretto | so far so good? | 11:14 |
| mainek00n | Sure, several kernel versions are defined in different source packages. | 11:15 |
| mainek00n | Thanks, I now know how to read OVAL in the kernel package, which was vague. | 11:16 |
| mainek00n | Please continue. | 11:16 |
| ebarretto | the second test is a variable test, which is defined in line 406, as usual it has an object and a state. The object on line 702 has a reference to a variable that you can see defined in line 1078, which its value is 0:4.15.0-197 (this is the patched kernel version, without the .XXX number). This object/value will be compared to the state defined in line 939, where we can see that we will do a greater than comparison between our object | 11:25 |
| ebarretto | and another variable defined in 1070. This variable is just looking again at the uname object os_release value and extracting just the version from it. So to recap the uname_object os_release will be something like "4.15.0-111-generic" and we will get only the number part, which means "4.15.0-111". With it the comparison greater than will look like: Is "4.15.0-197" > "4.15.0-111"? If true means you are vulnerable, if false means you | 11:25 |
| ebarretto | have that kernel with the fix. | 11:25 |
| mainek00n | Even though it is not written in os_release, is there any case where the .208 part would be needed? | 11:29 |
| ebarretto | mainek00n, not really. I know the kernel team uses it for something specific (maybe related to their workflow) and maybe sbeattie can answer your question on that. But whenever there's a newer minor kernel version it increases all the values after the '-'. As you can see the latest is 4.15.0-198.209 | 11:34 |
| ebarretto | mainek00n, if for any reason you still need to check installed kernels, then hoefully you could go if the OCI OVAL and use it as your base. Just remember of the issue I said above (about false negatives) that we hope to fix it soon | 11:38 |
| mainek00n | ebarretto, Thanks for your kind attention. What is the best way to know which Kernel Package is running? | 11:39 |
| mainek00n | To avoid false positives, it is necessary to identify the exact kernel package that is running. | 11:42 |
| ebarretto | mainek00n, the most common is uname (-r or -a depending on how much information you need). You could also read /proc/version or dmesg/journal but that requires some parsing | 11:42 |
| ebarretto | hope it helps :) | 11:44 |
| ebarretto | and for sure feel free to tag me if you have questions or see issues in our data | 11:44 |
| === ChanServ changed the topic of #ubuntu-security to: Twitter: @ubuntu_sec || https://usn.ubuntu.com || https://wiki.ubuntu.com/SecurityTeam || https://wiki.ubuntu.com/Security/Features || Community: pfsmorigo | ||
| sdeziel | `/proc/version_signature` is also useful because it shows all the numbers including the .XXX one (4.15.0-198.209) | 13:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!