• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login

Code Injection in Signed PHP Archives (Phar)

July 13, 2017Jeff ChannellEspanolPortugues

173
SHARES
FacebookTwitterSubscribe

PHP contains an interesting but rarely used feature called Phar, which stands for PHp ARchive, that allows developers to package entire applications as a single executable file. It also boasts some additional security benefits by signing archives with a digital signature, disallowing the modification of the archives on production machines.

According to the official PHP documentation:

Phar can compress individual files or an entire archive using gzip compression or bzip2 compression and can verify archive integrity automatically through the use of MD5, SHA-1, SHA-256 or SHA-512 signatures….

… The Phar extension takes security into account, and disables write access to executable phar archives by default, requiring system-level disabling of the phar.readonly php.ini setting in order to create or modify phar archives. Normal tar and zip archives without an executable stub can always be created or modified using the PharData class.

While the above is technically true, we at Sucuri have found that these restrictions are easily bypassed by a determined attacker and cannot be relied on to protect the integrity of an archive. As such, it is advised that additional measures be taken to confirm the validity of any Phar archives before using in a production setting.

How Phar Disables Writes

The documentation states that archives can only be written if explicitly allowed in php.ini – but this protection is only enforced in code. What this means is that the Phar classes included with PHP will not allow the writing of new files or the modification of existing ones when attempted via the Phar class methods provided for this purpose. Any modification via external resources is not – and cannot – be enforced in this manner, leaving these files open to alteration by any user with write access to the file.

Having write access will most certainly allow the file to be changed, but that would inevitably alter the file’s signature. This should cause any attempted execution to fail, right?

How Phar Checks Signatures

To give more background on how Phar archives are constructed, they are PHP files that contain a mixture of code and other binary data.

First, comes the stub – a section of code that handles the extraction of resources. A binary manifest comes next, which allows the interpreter to understand the file structure of the embedded contents that follow. The signature makes up the last section of the file.

The signature format used by Phar archives is quite simple. On creation, a signature is generated. The file contains only the stub, manifest, and contents. This signature, along with a 4-byte signature flag, tells PHP what signature type was used. Last, a magic 4-byte constant marks a file as having a signature. All are then appended to the final file.

When PHP later reads the archive, it can determine the signature and type by reading the end of the archive. This type of formatting is ultimately where the problem arises.

Injecting Code in the Signature

To test this, we started out with a simple “Hello World” Phar file and signed it using OpenSSL. Executing the resulting .phar through the command line displayed our simple message as long as the archive existed alongside its public key file. Without the public key file, the interpreter failed with the PharException.

Likewise, any attempt to alter the stub section of the archive would also cause the signature to fail, but code injected before the stub would execute before this failure occurred. This is not a good thing, but the question then arose if it was possible to not only inject code – but to do so silently.

It turned out to be quite simple.

Since the signature is hard-coded into the file, we just removed the old signature section completely. After adding our payload (a simple “Hello Evil World”), we calculated a new MD5 signature, appended it to the malicious copy, and replaced our once benign “Hello World” with our infected version.

The resulting file executed our “Hello Evil World” payload then happily said “Hello World” as if nothing was wrong, and PHP was none the wiser. The public key file was ignored completely.

What This Means for Developers

Developers should be aware that the security mechanisms built into the Phar format are not a complete solution, and cannot prevent the modification of the code within.

The premise of Phar is to allow multiple PHP files to be stored within a single container, and that is exactly how it should be treated – as a collection of files.

What the Phar file format won’t do is prevent others from:

  • reading your code
  • modifying your code
  • including your code elsewhere

This doesn’t mean that you shouldn’t ever use Phar for anything ever, but developers and system administrators need to be aware of the limitations of the format.

173
SHARES
FacebookTwitterSubscribe

Categories: Security Advisory, Website SecurityTags: Best Practices, Encryption, Secure Development

About Jeff Channell

Jeff Channell is Sucuri's software engineer who joined the company in 2016. Jeff's main responsibilities include maintaining integrations between our different systems. His professional experience covers 10 years of software development for the web. When Jeff isn’t writing code, you might find him at home with his family, working on a variety of side projects, or out at the local brewery. Connect with him on Twitter.

Reader Interactions

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Join Over 20,000 Subscribers!

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2022 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.