Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CentOS servers always have CVEs #153

Closed
sbraz opened this issue Sep 21, 2018 · 24 comments
Closed

CentOS servers always have CVEs #153

sbraz opened this issue Sep 21, 2018 · 24 comments

Comments

@sbraz
Copy link
Contributor

sbraz commented Sep 21, 2018

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
Copy link
Member

kouril commented Sep 21, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Sep 27, 2018

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

@kouril
Copy link
Member

kouril commented Sep 27, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Sep 27, 2018

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

@kouril
Copy link
Member

kouril commented Sep 27, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Sep 27, 2018 


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
Copy link
Member

kouril commented Sep 28, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Oct 9, 2018

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
Copy link
Member

kouril commented Oct 9, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Oct 9, 2018

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

@kouril
Copy link
Member

kouril commented Oct 9, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Oct 10, 2018

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:
image

@kouril
Copy link
Member

kouril commented Oct 16, 2018

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
Copy link
Contributor Author

sbraz commented Oct 16, 2018

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

@kouril
Copy link
Member

kouril commented Oct 16, 2018 via email

@sbraz
Copy link
Contributor Author

sbraz commented Oct 18, 2018

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
Copy link
Contributor

bluikko commented May 12, 2020 •
edited
Loading

@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
Copy link
Contributor Author

sbraz commented May 12, 2020

@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
Copy link
Contributor

bluikko commented May 12, 2020

@sbraz I do not have CentOS 8 machines.

@sbraz
Copy link
Contributor Author

sbraz commented Jul 16, 2020

@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
Copy link
Member

kouril commented Jul 16, 2020

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
Copy link
Contributor

bluikko commented Jul 17, 2020

@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
Copy link
Contributor Author

sbraz commented Jul 17, 2020

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

@HavrilaJ
Copy link
Contributor

Hi,
please if you are still having problem described in this issue, please reopen this or create new issue and i will look into it.
Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kouril @sbraz @bluikko @HavrilaJ