Q
Problem solve Get help with specific problems with your technologies, process and projects.

Why did the PHPMailer library vulnerability have to be patched twice?

After a remote code execution flaw in PHPMailer was patched, the problem persisted, and had to be repatched. Expert Michael Cobb explains how the critical vulnerability works.

The open source PHPMailer library was found to have a serious remote code execution flaw. The vulnerability was...

patched, and then repatched, as the first attempt did not sufficiently mitigate the problem. How does this vulnerability work? Why didn't the original patch fix the issue?

Code libraries and frameworks greatly reduce the time it takes to build new applications. They save development teams from having to build common components from scratch for each new project.

Most web services are built using popular third-party frameworks and libraries. The big problem with this reuse of code is that, if a vulnerability is found in a popular library, it affects hundreds of thousands of applications, sites and services.

This situation occurs quite frequently, and arose again recently when Dawid Golunski discovered a remote code execution flaw in the open source transport class PHPMailer. Exploiting this vulnerability would give an attacker access to the targeted server in the context of the web server account; this could lead to a full compromise of the web application.

PHPMailer is used by many open source projects, such as WordPress, Drupal and Joomla, with an estimated nine million users worldwide. There are thousands of code snippets and examples on the internet showing how to send an email using PHPMailer from various forms, such as a contact or registration form, but most contain an insecure line of code that makes this vulnerability exploitable, as it allows anyone to forge the From and the Sender addresses.

PHPMailer uses the PHP mail function as its default method for sending an email. Although all email addresses used by PHPMailer are validated before being used, Golunski found a way of crafting a valid From email address that also contained an executable command. Although the From email address should be set by the developer, it is often set using data supplied by the user, which is extremely bad practice, as a user can submit any email address they choose. Also, if the Sender property is not set explicitly by the developer, the From address is used. This Sender value is added to the fifth parameter passed to the PHP mail function, which doesn't correctly filter any string literal escape characters it may contain. This allows an attacker to inject additional parameters containing commands that are executed when the mail is sent.

This vulnerability was tracked as CVE-2016-10033, and PHPMailer developers thought they had fixed the flaw when they released PHPMailer version 5.2.18. They added the escapeshellarg escaping function to sanitize the Sender address value before it is passed to the PHP mail function.

However, Golunski noticed that, when the escapeshellarg function was used in combination with the existing escaping function, escapeshellcmd, the Sender value was still not properly escaped. By adding an extra quote to the original attack code, it was still possible to escape out of the protection thought to be afforded by the patch. This new vulnerability was reported as CVE-2016-10045, and a patch was released in PHPMailer 5.2.20.

The PHPMailer team has posted on GitHub examples of how to correctly handle email addresses used in website forms. It requires emailing form data to and from valid addresses within a site's domain, explicitly set by the developer.

This is considered a highly critical flaw, and shows how important it is for developers and web administrators to stay up to date with the latest security threats and to subscribe to vendor alerts for any shared components, packages or libraries they use within their code.

Developers should certainly review any scripts that use the PHPMailer mail function, and also study how PHP's various escaping functions work, and the effect they have on different types of strings, as incorrectly escaped strings can also lead to SQL injection vulnerabilities.

Next Steps

Learn about the decades-old bug patched in the open source graphics library libpng

Discover how to test open source web apps for common vulnerabilities

Find out what possible effects the closure of the Open Source Vulnerability Database will have on the security industry

This was last published in May 2017

Dig Deeper on Email and messaging threats

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How does your enterprise ensure the security of the open source libraries it uses?
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

  • CIO Trends #6: Nordics

    In this e-guide, read how the High North and Baltic Sea collaboration is about to undergo a serious and redefining makeover to ...

  • CIO Trends #6: Middle East

    In this e-guide we look at the role of information technology as the Arabian Gulf commits billions of dollars to building more ...

  • CIO Trends #6: Benelux

    In this e-guide, read about the Netherlands' coalition government's four year plan which includes the term 'cyber' no fewer than ...

Close