python els Archives - TuxCare

Business Value of ELS Patching for Python

Python has grown tremendously, and its impact has been remarkable. It has become one of the most popular programming languages among developers and researchers.

Python is an object-oriented, high-level, interpreter-based programming language. It was created by Guido van Rossom in 1991 and has been used for various projects since then.

The importance of Python for DevOps

A recent survey of 4,600 IT professionals found that those who adopted a DevOps culture could deploy code 200% more often than those who did not embrace such a culture. They also spend half as much time applying fixes through patches for bugs, recover twice as fast after failures, and have threefold fewer changes fail. Most importantly, they achieve these results without sacrificing quality.

What’s Python’s place in DevOps development tools? Python’s versatility and ease of use make it an ideal tool for DevOps workflows. Developers can write scripts and deploy them to production servers without worrying about infrastructure. Python is widely adopted across the industry, so it’s easy to find people who know how to use it.

Python is one of several programming languages commonly used by teams practicing DevOps. It has many advantages compared to other languages, making it an excellent choice for this role.

Buying Time to Migrate to the Following Code Release of Python

Several challenges become critical to organizations once they adopt python as their central application for source code development and automation. Once a new release of Python is announced, the organization may take up to 3 years to migrate their current source code to the latest version. In the case of Python 3 not having legacy support for Python 2.7, this created a critical risk for software companies. The inability to back support a previous version places the software company in a challenging place.

The company will need time to develop new code, test, QA, and stage more rapidly. This new code set will likely have more bugs and performance issues with a limited operating window. This rapid code development also places their existing clients at risk. The clients will need to either attempt an upgrade in place or possibly forklift the entire platform. Both options add to the risk for Python clients. Many clients may opt not to upgrade to the software’s new code while considering other options. Unable to receive security updates and choose to live with the inherent risk of vulnerabilities and exploits, these clients will jeopardize their most critical assets. Python developers and clients need enhanced operational security with the latest version available and extended support after the end-of-life date.

Value of Tuxcare Extended Lifecycle Support(ELS)

You’ve built your applications on Python, you know that code front to back, and you’ve spent years chasing instability and squashing bugs. The hard work and long days put in by your team have resulted in something that runs well and builds value for your organization.

What are some of the core business justifications for investing in an ELS?

  • Your currently targeted Python version is going to end-of-life, and you need time to develop the next-generation application.
  • No need to refactor your Python 2.7 applications to Python 3.0
  • We backport security fixes for Python 2.7 versions, so you wouldn’t have to rewrite your app. 
  • Security compliance must be maintained, but an upgrade may break your code. Specific compliance regulation, including PCI-DSS, HIPAA, FEDRAMP, and NIST-800-53, requires all systems to be patched within 30 days after identifying known vulnerabilities.
  • Extend the life of your hardware and software assets while conserving DevOps resources. Using ELS with automation delivery, patches, and updates, including rollback capability, can streamline the update process with the DevOps teams.

Protecting your Python 2.7 from vulnerabilities 

Vulnerabilities will exist in any code, including the Python language. Many vulnerabilities never become exploits. Python, like other applications, is subject to zero-day attacks. These attacks are often executed by hackers betting on specific vulnerabilities within a system that has not been patched regularly. The hacker’s rule is most Python and other systems’ time to patch a vulnerability or patch (MTTP) is between 60 and 150 days.

SecOps usually send out a patch within 38 days. The open window will most likely be when a system becomes exploited. However, no one will know which one or when the attack will occur.

  • ELS will reduce the threat vector of zero-day attacks against Python applications as an automated business process.

An unpatched vulnerability at the language level will inherently place at risk all the applications written in that language, so even if the application’s code itself does not have any issue, some language construct that is used may have, and this is both difficult to diagnose and complex to protect from adequately.

Why Tuxcare?

Trusted partner

We’ve supported various RHEL forks for over 12 years, including AlmaLinux – a forever-free enterprise-grade OS. Support the significant Linux OS versions from CentOS 6, CentOS 7, and CentOS 8, including Ubuntu 16.04 LTS and RHEL-based distributions.

  • Also available is ELS for PHP.
  • Through KernelCare Enterprise, we provide live patching for the Linux Kernel, critical shared system libraries like OpenSSL and Glibc, open source databases like MySQL, Postgres, and MariaDB, and the virtualization platform QEMU/KVM – all of which cause high business disruption when patched traditionally.

Being compliant is our nature

We have passed and continuously maintain various Cybersecurity certifications. And our services have helped numerous enterprise companies, government agencies, and universities achieve and maintain their compliance status.

The TuxCare Story

  • TuxCare has delivered patches and bug fixes for various Linux distros for over ten years.
  • TuxCare is approaching 1 million in production workloads secured and supported by our services.
  • We have over 1500 customers from multiple industries around the world.
  • TuxCare’s KernelCare Enterprise has patched more than 2,000 vulnerabilities without reboots over the years.
  • We support more than 40 Linux distributions.

Frequently Asked Questions

What version of Python is supported by ELS for Python?

The service will provide security updates for Python 2.7.

Will existing Python code continue to run as-is?

Yes – the goal is to provide security fixes, not language-breaking changes. Your existing Python 2.7 code and applications will continue to run as before – only more securely.

Does this address security issues in my Python application?

Depends. If the security issue stems from a language-specific security problem, your application will be secure from threats targeting that specific security problem.

My application is written in Python and has no security issues – why do I need ELS for Python?

New vulnerabilities emerge every day, and of those, some will target older code. Even if your application does not directly have any security problems, exposure found at the language level may make your application insecure. That is why it is essential to have access to security patches even after a language is no longer officially supported.

Owner-initiated Cybersecurity Supply Chain Attacks

Supply chain attacks come in all forms and shapes. One example is taking over legitimate accounts to deploy malicious code into widely used libraries. Another is deploying changes during compilation through malicious tooling. 

We could carry on – think about mislabeled content intent on tricking unwary users, or additional files added that subvert application behavior. 

But, another particularly malicious supply chain attack perpetrated by the actual code owner or the original developer behind the code is emerging – and it’s proving to be incredibly disruptive. 

A new, dangerous supply chain threat

This attack vector emerged early in 2022 when developers realized that a couple of very widely used libraries (“faker.js” and “colors.js”) had been tampered with to include code that was unrelated to the original intent of these libraries.

Worse, the “additional” code was breaking the applications relying on it by creating an infinite loop in the code. Because the code for these libraries is open and hosted in public repositories it was possible to analyze the commits and identify who had added that malicious code. 

The developer community was disconcerted to find that the code was added by the original developer. 

Apparently unhappy with not being able to monetize the time he expended in developing the code, and how it was being used by so many developers, the developer decided to sabotage his own libraries.

Sabotage that impacts millions

It might sound like it’s nothing – it’s the developer’s code, after all. But to put it all into context, the affected libraries had an aggregate of 25 million downloads… not across their useful lifetime, but every single week. 

The politics of open source and how open source is monetized – including the steps a developer can take to address it – is really an entire article in and of itself, and opinions can vary a lot. But, for obvious reasons, the backlash around a developer tampering with code used by millions was immense. 

In fact, GitHub, where the code is hosted, suspended the developer’s account (though GitHub restored it a few days after). The developer claimed to have hundreds of projects, not only in those two libraries but of course, the two libraries in question have an immense following. 

Malicious action with real impact on developers

The libraries ended up being blocked from distribution, the code was reverted, and new libraries were created to replace the functionality.

What this meant for developers using those libraries was the extra work of checking code, updating it, and changing dependencies. One individual’s actions led to extra testing and all the other tasks that are necessary to ensure proper software execution. Countless work hours were spent on responding to a malicious actor, hours that could have been more productively used elsewhere.

It was deliberate action by a single developer that affected thousands of applications. But there are other situations where it’s not deliberate, but it nonetheless comes from the source, the developer. Or, at least, the developer’s account.

A compromised git server

Just a couple of months after that, in March, the git server holding the code for the most popular web server programming language, PHP, was compromised. Yes, you read the right, the PHP Team’s official PHP git repository was tampered with.

Attackers managed to change the source code for PHP 8.1 and introduce malicious commits into the system under the guise of “typo fixes”, which hid malicious code that, if successfully integrated into the PHP codebase, would disseminate to millions of PHP deployments and create a backdoor in millions of internet-facing websites and services written in PHP.

How did it happen? Git is a great tool, but it has a flaw where it is possible to sign code commits as someone else. Another person reviewing the code edits may then be fooled into thinking that the edits were made by, say, the main project developer. 

The result is that any review could rely heavily on trust – the trust that the right person edited the code and made acceptable changes. Reviews can therefore be less stringent, allowing malicious code to slip under the radar undetected. 

And it’s not just PHP…

The malicious code added to PHP 8.1 was detected and the commits were rejected, so the code never made it into the PHP codebase millions use every day. Yet the problem it created led the team to move from its own git repository to GitHub.

In May, Python’s ctx library and PHP’s phpass library were both compromised in an operation that the attacker claimed was simply “for research purposes”, a claim that was ultimately impossible to prove or disprove. 

In a convoluted series of steps, the attacker took over the repositories for these libraries by impersonating the original developers – taking over email addresses that no longer existed, then requesting password recovery for those accounts, and creating fake domains to validate ownership of expired ones. 

This tricked the repository hosts into giving repository administration to the attacker, who was posing as the original developer who had lost access to his own code. The attacker proceeded to include credential-stealing code in those libraries, including AWS credentials. The attacker’s claims that all the gathered credentials were deleted were also impossible to verify.

Threat actors are investing heavily in supply chain attacks

These examples shine a light on the need for a quick response to threats in the code supply chain. The threat to code supply chains is not new in and of itself. However, the attacks we’re seeing lately are different because the time invested goes much beyond the usual attack turnaround time of days or weeks.

The latest examples of compromises involve a huge amount of time to execute the compromise. In many ways it is a much more serious example of a supply chain attack, striking at the heart of code that is – blindly – used by millions of organizations around the world.

In another point that makes the matter more serious: it’s worth considering the large amount of work required to change library versions to respond to a compromise. New libraries take a considerable amount of time to execute, test and deploy each time such an event takes place. 

This is where a service like Extended Lifecycle Support for PHP and Extended Lifecycle for Python can help. TuxCare quickly provides security updates for language level issues and for related modules, which help close holes created by some of the attacks we described faster and with less work than the alternatives.

Python Extended Lifecycle Support: A Deeper Look

Extended Lifecycle Support (ELS) for Python enables continued use of Python 2 applications, with timely security updates, without requiring any code refactoring or migration to newer Python versions. This lets your organization extend the value proposition of currently running applications already deployed and working perfectly while avoiding the time-consuming and costly upgrade process that comes with migrations to a new language version.

Continue reading “Python Extended Lifecycle Support: A Deeper Look”

Changes From Python 2 to 3 Making Code Refactoring Unavoidable

Being faced with the prospect of having to delve into old code to get it running against a new language version is one of the things developers try to avoid at any cost. It’s hard to understand old code; unexpected changes might introduce new bugs, performance will likely take a hit, and it is a tremendous effort for little payback. After all, you’re adding nothing new, just getting it to run as before. This post will cover some examples of changes from Python 2 and 3 that make this code refactoring unavoidable. Continue reading “Changes From Python 2 to 3 Making Code Refactoring Unavoidable”

Resources

State of Enterprise Linux Cybersecurity ... Read More State of Enterprise Linux Cybersecurity ...
Dangerous remotely exploitable vulnerability ... Read More Dangerous remotely exploitable vulnerability ...
Securing confidential research data ... Read More Securing confidential research data ...
State of Enterprise Vulnerability Detection ... Read More State of Enterprise Vulnerability Detection ...
Demand for Rapid Risk Elimination for ... Read More Demand for Rapid Risk Elimination for ...
TuxCare Free Raspberry Pi Patching Read More TuxCare Free Raspberry Pi Patching