May 11, 2023

Patching CentOS: What You Need to Know

Operating Systems
Security

By

CentOS patches are in high demand — with CentOS 6 and CentOS 8 end-of-life and no longer supported by the community, many systems are vulnerable to attacks. But it's not enough to just install a security patch and call it day. Knowing when to patch CentOS vs. up/downgrade to a supported version (or migrate to a CentOS alternative) can be tricky to determine, but it's an essential part of CentOS security. 

In this blog, our expert offers tips on how and when to patch CentOS and patch management best practices to keep CentOS protected from vulnerabilities.

Why Patching CentOS Is Important

Software updates, which often come in the form of patches, provide improved features and functionality, while repairing defects and eliminating exploitable security problems. For operating systems like CentOS, updates are essential to keeping organizational infrastructure available, stable, and safe. At the same time, updates increase end-user satisfaction by improving performance and fixing other known productivity problems that have been discovered since the original software release.

Ongoing maintenance of software like CentOS can also reduce costs by avoiding the heavy burden of accumulated technical debt and avoiding the productivity consequences and reputation damage that can result from unplanned outages and/or data leaks.

When to Update vs. When to Upgrade CentOS

Updates should be driven primarily by external forces to avoid immediate negative consequences. Upgrades should be driven primarily by internal forces to leverage emerging improvements.

Updates protect systems from attacks by applying security patches that minimize or eliminate an attack vector, and they help keep a system stable and performant by fixing defects in existing features or functionality. Upgrades, on the other hand, lay a new foundation that consolidates all previous fixes into a new install and adds new features and functionality to improve the overall system performance and user experience.

Updates guarantee backward compatibility, which introduces less risk to applications. Upgrades do not always guarantee backward compatibility, so they are released to make more dramatic underlying changes (sometimes compatibility breaking changes) that require more rigorous testing and changes to downstream applications before adopting.

With CentOS and any business-critical software, it is advisable to diligently keep up with both updates and upgrades; however, that doesn't mean apply all updates, much less upgrades, immediately. 

Updating and upgrading are equally important activities, but they differ in motivation and procedure. Updates require a patch management strategy that is tuned toward a reactionary posture, whereas upgrades follow a roadmap with proactive horizon planning in stages.

You should continuously patch as protection from bad actors and to stay closer to mainline changes coming in future upgrades or, in the case of CentOS, behaviorally compatible alternatives (i.e. Rocky Linux, AlmaLinux). To be clear, continuously doesn't equate to immediately. A solid CentOS patch management strategy will categorize and prioritize patches based on the risks and needs of your systems. 

It is desirable to defer patches for a short period of time to allow any negative consequences or side effects of a patch to surface; however, this is not always an option due to the immediate threat of the defect outweighing the risk of potential side effects. This is especially true for security patches, as malware authors monitor security defects and actively seek out un-patched systems.

You should upgrade CentOS on a planned timeline that fits best with your roadmap for new feature additions and your staff's capacity to handle the change with the professional rigor required. However, it is also essential to be aware of the planned software end-of-life (EOL) timeline. Once a CentOS version reaches EOL, CVEs may go unpatched. Therefore, organizations should have a plan that ensures that upgrades occur before the software reaches EOL or secure a source of patches from a reputable commercial LTS vendor. 

Which Versions of CentOS Are End-of-Life?

CentOS 6 and CentOS 8 are both EOL. Currently, CentOS 7 is the only version that is still supported by the community, but it will become end-of-life in June 2024. 

Known CentOS Vulnerabilities

As a testament to the ongoing sense of urgency, here are some current and/or recent CVEs that impact various CentOS versions. These are top of mind, as they are recent; however, keep in mind, malware authors never stop patrolling for systems that are vulnerable to patched defects. They are only deterred by systems that have actually been patched. 

CentOS 8.x

CVE-2022-37434 is a critical vulnerability in the zlib and rsync packages on CentOS8. Successful exploitation could lead to things like disclosure of sensitive information, addition or modification of data, or Denial of Service (DoS).

CentOS 7.x

CVE-2022-41903 is a critical vulnerability in the git package on CentOS7 that was recently patched. Failing to apply this patch can ultimately open the door to arbitrary code execution via misaligned heap writes due to an integer overflow.

CentOS 6.x

CVE-2023-22809 is a high vulnerability in the sudo package on both CentOS6 and CentOS8. Successful exploitation can allow a local bad actor to append arbitrary entries to the list of files to process, which can lead to privilege escalation.

Free CentOS Consultation

Schedule a one-hour session with an OpenLogic CentOS expert to discuss your current infrastructure and business goals, and get recommendations for next steps.

Schedule Consultation

How to Get and Install CentOS Patches

The happy path for updating is simple:

  1. Open a command prompt (locally or remote via ssh)
  2. Run yum check-update to display information about available updates (sudo maybe required)
  3. Run yum update to pull and apply all the available updates listed

There are of course many permutations of this sequence to tailor an update to specific needs. For example, run yum update <package-name> to pull and apply an update related to a particular package.

The real complications arise in coordinating required outages, preparing to validate the success, and planning to recover from any failures. This requires communication and engagement with stakeholders across the organization. Attention to these details upfront can minimize disruption and avoid negative attention.

CentOS Patch Management: Best Practices

Depending on the scale of operations, maintaining and managing the CentOS lifecycle can be full-time work for an individual or divided up among a team. Here are the basic tenants of good CentOS patch management:

1. Inventory and Attribute Assets

It is imperative to know the environment as a foundation for discovery, prioritization, and remediation. Maintain key attributes of all existing installs, including hardware details, connectivity, software versions, system class (i.e. dev/test/prod), owner point-of-contact, business purpose, etc.

2. Actively Discover Threats

There are tools available and subscriptions to services that will assist in scanning systems and identifying potential threats. Every organization should frequently and consistently review the results of one or more of these scans to stay aware of threats to the known inventory of systems.

It is also important to establish real-time monitoring of systems in the inventory to watch for anomalies or unusual activity that may indicate a compromised or malfunctioning system.

It is critical to understand that this step in the lifecycle is quite complicated. It can create an abundance of information. It can become noise even to a trained eye; therefore, it is highly advised to use automated alerts that apply filtering or artificial intelligence based on business policies to highlight significant events or alarming trends.

3. Analyze Risk and Impact of Vulnerabilities

Defects can and will arise without warning. Some are more critical, some have a higher likelihood of occurring on your systems, and some have a more immediate or costly impact than others. It is wise to have a preconceived and thoughtful methodology for curating defects and determining an appropriate response. This will save time, energy, money, and reputation.

Some of the curation methodology will be based on asking questions about the system inventory:

  • Which systems are vulnerable?
  • Which systems are critical?
  • Which systems are customer-facing?

Some of the curation methodology will be based on business factors, or the answers to questions such as:

  • Does the defect compromise regulatory compliance?
  • Will patching outages effect revenue streams?
  • Can complacency result in a data breach?

Something as simple as a checklist can go a long way toward categorizing and prioritizing systems to receive updates. However, this should evolve into guiding principles and policies that drive sound and ethical business decisions.

4. Engage Stakeholders

It is important to provide information, gather feedback, and request assistance from the owners and users of systems that are impacted. Adequate communication and interaction with these individuals will help set expectations, avoid surprises, and hopefully solidify success.

5. Test Installation and Rollback Procedures

Patches can fail, resulting in unusable or corrupted systems. They can also apply properly, yet have unexpected downstream side effects on applications. It is always wise to install the patches in a controlled lab environment to build procedural competence, as well as confidence in the result.

Organizations should strive to establish and maintain rapid and thorough testing procedures, as this is a telltale sign of organizational maturity and a contributor to ongoing success. At a minimum, run the tests provided with the patch.

This is another area that greatly benefits from automation. For large enterprises, it is critical to use a toolkit like Puppet or Ansible to make these tasks repeatable and self-reporting. Otherwise, human error is inevitable and key failure indicators can slip through the cracks.

6. Execute Installation and Validate the Outcome

This is the step most organizations remember. Some because it is the only step they took, and luckily it worked fine; others because this is the only step they took, and unfortunately it failed, and everyone is now asking them why.

All kidding aside, installing the patch is the moment of truth, where the rubber hits the road. It is where all the hard preparation work pays off. Whether a patch applies correctly or not, the outcome of the change event should be a success, as there is validation in place to determine the result and a follow-through plan based on pass or failure.

7. Communicate and Document Results

Always be prepared to send a summary communication that outlines the successes and failures of the change event. This is an opportunity to celebrate a win or reset and provide details of next steps. In any case, documentation on the systems should be updated to reflect the current state, including the asset inventory, to set a new baseline for future changes.

Final Thoughts

Anyone tasked with making decisions about patching CentOS and establishing patch management protocols will benefit from having a clear prioritization and assessment process in place. The steps outlined above are a good starting point, and hopefully this blog has made a solid case for why patching CentOS is important, especially if you are running an EOL version. 

Need Support for EOL CentOS or Help Migrating?

OpenLogic offers long-term support for CentOS 6 and 8, including patches for high-severity CVEs. We can also help you with your CentOS migration strategy.

Get Support for CentOS

Additional Resources

Headshot for Tim Carroll

Tim Carroll

Director of Product Development, Perforce Software

Tim Carroll is a senior leader at Perforce Software, influencing software and product development across the portfolio, including OpenLogic, Zend, SourcePro, IMSL, and Gliffy. He’s motivated by providing software solutions that enable people to look beyond solving problems and mobilizing resources to overcome new interesting obstacles. Tim has 25 years of experience in software development with heavy involvement in open source software, including service on the Board of Directors for JA-SIG and the Apereo Foundation.