Colin Hamilton coming at you again from the SUSE team. In this post, I want to discuss security vulnerability scanners and their role in an Enterprise Linux environment like SUSE. This role is a common pitfall I’ve seen that leads customers to our support team.

So what’s the problem? Well, vulnerability scanners are kinda dumb. I don’t mean in the childish “I don’t like this tool so it’s dumb” kind of way. I mean that its functionality is very simple and also very error prone. Why? These scanners don’t actually check for vulnerabilities.

Yup, you heard me right. These aren’t tools that will try to exploit the vulnerability to verify if it’s there or not. That kind of testing would put stress on systems not desired in a production environment and wouldn’t be cost-effective. So what does it actually do? It goes off of package versions. To clarify though, not OS distribution specific package versions. It checks upstream version numbers. So, unless the OS you have happens to be the upstream source of the vulnerability, chances are very high that the package version is going to be different than what the scanner is looking for. If the difference is a lower version number than the one the scanner has listed as fixing the exploitation, it’s going to flag it as vulnerable.

This is a problem for many Linux distributions but this ends up being a particular problem for enterprise distributions like SUSE. The reason for that is that in order to maintain enterprise level stability, versions are not upgraded too quickly. SUSE wants to make sure that the version has shown a history of stability first, that it’s been tested, and that it meets SUSE’s enterprise level criteria.

So what does SUSE do when there is a security vulnerability patch in a later version? We back-patch. This means that we’ll take the particular section of code in the patch that fixes the vulnerability and apply it to the older version of the package that is already in our enterprise distribution. That way we can continue to maintain enterprise level stability while also patching security vulnerabilities. However, this means that there’s a lot of potential for false-positives with those vulnerability scanners.

Now that you know why this is a common pitfall, here’s what I recommend to help you most quickly identify if we’ve actually patched the vulnerability or not. First off, any real established security vulnerability will be given a CVE number. Find this number and then head on over to this URL.

From there you can run a search on the page for the CVE in question and click on the link associated with that CVE. After that, you’ll see SUSE’s current public information on that vulnerability. If we’ve patched it, the page will list package versions specific to the various versions of supported SUSE Linux Enterprise with the patch. You can compare those versions to your system to see if the vulnerability is fixed.

Also, if there is a compliance company you’re working through, you can provide them with these CVE link(s) to show them that the scanner is incorrect and that your system is patched to that vulnerability.

Lastly, if the compliance company is being picky and the web page is not enough, you can run the following  rpm command on the relevant package (after being patched to the necessary or later version) in order to grab the changelog that will also confirm the CVE is fixed:

 # rpm -q –changelog package > package-changelog.txt 

Replace “package” in the above command with the name of the package in question. That command will place the text of the changelog for that package into the txt file. The txt file will be saved into the directory you ran the command. You can run a pwd command if you aren’t sure which directory you are in. In our changelogs, it is listed if we have back-patched a particular CVE vulnerability. Give the compliance company that txt file for specific evidence of the patch.

Thanks for reading and, as always, I hope I’ve changed your lives forever and that this paradigm shift in your lives will mean less work for me.