CentOS servers always have CVEs

[sbraz]

Hi, Is it normal that CentOS servers always have CVEs after a system update? I unfortunately don't have any Red Hat server to compare the results. I'm aware that the way CentOS and Red Hat versions are matched isn't perfect, I'd just like to know if I can reliably use Pakiti to check whether my CentOS servers need updates.

[kouril]

On Fri, Sep 21, 2018 at 08:45:59AM -0700, Louis Sautier wrote:

Is it normal that CentOS servers always have CVEs after a system update? I unfortunately don't have any Red Hat server to compare the results. I'm aware that the way CentOS and Red Hat versions are matched isn't perfect, I'd just like to know if I can reliably use Pakiti to check whether my CentOS servers need updates.

it's not normal but can be result of some mismatches in the versioning (as you mention). I suggest to take a look which packages are marked as vulnerable to see if it may be caused by the versioning. (for that please check the #138 issue).

[sbraz]

For instance, openssh version 0:7.4p1-16.el7 is marked as vulnerable toCVE-2017-15906.

[kouril]

On Thu, Sep 27, 2018 at 07:18:12AM -0700, Louis Sautier wrote:

For instance, openssh version 0:7.4p1-16.el7 is marked as vulnerable toCVE-2017-15906.

This is strange, I checked our production instance and found a machine that seems similar to yours (CentOS Linux release 7.5.1804 (Core), openssh v.0:7.4p1-16.el7, amd64) but it doesn't have the openssh package marked with the CVE.

What exactly are you using on the server side?

[sbraz]

I'm not sure what you mean by that. I'm using the latest git master of Pakiti.

[kouril]

On Thu, Sep 27, 2018 at 02:41:31PM +0000, Louis Sautier wrote:

I'm not sure what you mean by that. I'm using the latest git master of Pakiti.

that's what I meant, thanks.

What you see on

/egi/protected/cve.php?cveName=CVE-2017-15906 ? Daniel

[sbraz]

Name | Version | Architecture | OsGroup
-- | -- | -- | --
openssh | < 0:7.4p1-16.el7 | all | CentOS 7
openssh | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh | < 1:7.5p1-10ubuntu0.1 | all | Ubuntu 17.10
openssh | < 1:7.6p1-4 | all | Ubuntu 18.04 LTS
openssh | < 1:6.6p1-2ubuntu2.10 | all | Ubuntu 14.04 LTS
openssh | < 1:7.2p2-4ubuntu2.4 | all | Ubuntu 16.04 LTS
openssh | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-askpass | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-askpass | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-askpass | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-cavs | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-cavs | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-cavs | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-clients | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-clients | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-clients | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-keycat | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-keycat | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-keycat | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-ldap | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-ldap | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-ldap | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-server | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-server | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-server | < 0:7.4p1-16.el7.centos | all | CentOS 7
openssh-server-sysvinit | < 0:7.4p1-16.el7 | all | Red Hat Enterprise Linux 7
openssh-server-sysvinit | < 0:7.4p1-16.el7 | all | CentOS 7
openssh-server-sysvinit | < 0:7.4p1-16.el7.centos | all | CentOS 7
pam_ssh_agent_auth | < 0:0.10.3-2.16.el7 | all | Red Hat Enterprise Linux 7
pam_ssh_agent_auth | < 0:0.10.3-2.16.el7 | all | CentOS 7
pam_ssh_agent_auth | < 0:0.10.3-2.16.el7.centos | all | CentOS 7

[kouril]

I believe the problem is caused by the Centos VDS module, I'm affraid it's broken and we have to come up with a better way how to cope with packages that Centos decides to re-package.

I suggest you to remove the Centos module, the easiest way will be to start from a clean database. I'm sorry if it causes any troubles to you.

[sbraz]

I'm a bit confused, what will happen If I remove all "CentOS OVAL" sources? Will Pakiti be able to tell me anything about my CentOS servers?

[kouril]

On Tue, Oct 09, 2018 at 02:19:02AM -0700, Louis Sautier wrote:

I'm a bit confused, what will happen If I remove all "CentOS OVAL" sources? Will Pakiti be able to tell me anything about my CentOS servers?

yes, most CentOS and pristine RHEL packages are exactly the same (in terms of versioning and naming), therefore vulnerability information published by RH (the oval XML's) will just work. There'll be a small fraction of packages that will not covered well, though (those tha CentOS decides to rebuild and change the versioning a bit).

Daniel

[sbraz]

I currently use the RedHat URIs for CentOS, is it correct?

[kouril]

On Tue, Oct 09, 2018 at 02:52:46AM -0700, Louis Sautier wrote:

I currently use the RedHat URIs for CentOS, is it correct?

the URL's are correct, however the Subsources need to be of the RedHat OVAL type.

Daniel

[sbraz]

I have changed the vdsSubSourceId column to make all these sources Red Hat and re-ran the synchronize and compute scripts but I still have issues with CVE-2017-15906 amongst others. How can I debug this, do you need additional info? Here is another screenshot of the VDS page:

[kouril]

I'm affraid you need to purge the whole database. The synchronization and compute scripts don't remove definitons of vulnerabilities introduced by VDS that are being removed. Sorry,

Daniel

[sbraz]

What is the proper way to do this? Drop all tables and then re-add VDSs?

[kouril]

On Tue, Oct 16, 2018 at 04:25:25AM -0700, Louis Sautier wrote:

What is the proper way to do this? Drop all tables and then re-add VDSs?

you can drop the whole database, then you need to populate the schema and populate the basic configuration (including the VDS specs). YOu can use the install/initDB.php script to create the database.

[sbraz]

I've done that and it seems to work better. I still see vulnerabilities for packages which have centos in the version like dhclient 12:4.2.5-68.el7.centos.1 but I guess there's no way around it until #138 is closed?

However, I'm confused because I see stuff like CVE-2017-16994 which Red Hat marks as fixed in version 0:4.11.0-44.6.1.el7a of the kernel. My CentOS has a 3.x kernel, do RH and CentOS differ in terms of how they patch the kernel?

[bluikko]

@sbraz I know this is an old issue but I wanted to chime in that using the RHEL OVALs seem to work quite well on my CentOS machines. The amount of vulnerabilities seem to depend as expected on the last update time and fully updated machines show zero vulnerabilities.

Edit: this is with the latest release or git MASTER.

[sbraz]

@bluikko thanks, I might take a look at some point. I'm not on the latest release and I currently see quite a few CVEs on my servers. Maybe it has to do with you running CentOS 8 instead of 7?

[bluikko]

@sbraz I do not have CentOS 8 machines.

[sbraz]

@kouril although things seem to have improved, I still see vulnerabilities for Kernel-related stuff, for instance CVE-2018-6927 for which kernel < 0:3.10.0-862.el7 is vulnerable.

I have 0:3.10.0-1127.13.1.el7 installed and it is still marked as vulnerable. Is it a lexicographical sorting issue? ("1127" < "862")?

[kouril]

I've verified that versions compare correctly by the code and I couldn't find a similar case in our servers. Do you use the latest code in your installation? I'd be interested to see if you can replicate the problem with a brand-new installation (upon a clean DB).

[bluikko]

@sbraz My machines with 3.10.0-1127.13.1.el7 do not show vulnerabilities. All the CentOS6 and CentOS7 servers CVEs look right in there. Maybe this problem is specific to your system. I use the development version and I believe everyone should do so, the version 3.1.1 is very old. Are you using the Master branch?

[sbraz]

I am using the master branch at commit 2346447292184ebb26f1cfaa01eb25e1a1ede0b8. I will attempt a clean install when I have time.