< is >

Quantifying the Security Benefits of Debloating Web Applications

Introduction

The main idea of software debloating is to reduce software's attack surface by removing pieces of code that are not required by users. In this study, we analyze four popular PHP applications (phpMyAdmin, MediaWiki, Magento and WordPress) and show that a reduction of up to 71% in Logical Lines of Code, up to 60% in historic CVEs and up to 100% in Object Injection Gadgets is possible. Essentially, by removing unused functionality and libraries from the application we can significantly reduce the attack surface.

The paper is available at https://www.securitee.org/files/debloating_usec2019.pdf

Slides

Videos

Architecture

This system is comprised of three docker images:

  • "web" container hosts the web applications. It runs Apache with PHP 5.6 (To support older version of applications for our study) and uses XDebug to record code coverage information. Web container is accessible at http://localhost:8085 by default.
  • "db" includes the main database (code_coverage) with CVE mappings and coverage information along with database files required to run desired web applications.
  • "admin" container hosts the administation panel and debloating logic. Adding new software, mapping new CVEs and viewing which vulnerable lines within the application were triggered during the usage of the application are possible. Moreover, you can remove unused files and functions using this panel after executing desired functionality of the application and recording its code coverage. Web and Admin map to the same volume and access the same web applications. Admin panel is accessible at http://localhost:8086/admin.

Extending the framework
- Admin Panel: The admin panel that contains the debloating logic and reporting UI is hosted under web/admin directory.
- Database Schema: The schema of the database along with CVE mappings for the four web applications is located at database/Schema/db_template_with_vulns_pma_mwk_mgt_wordpress.sql.
- Recording Code Coverage: PHP auto_prepend is used to record code coverage of PHP files. The file that is injected in all PHP files handles the code coverage life cycle and records the information in the database is accessible at codecoverage/start_xdebug.php
- Parsing PHP Files: We use PHP-Parser to parse and rewrite PHP files.
- File Debloating: File debloating is implemented under web/admin/application/controllers/Software_file.php:debloat_files($id). We match each file with the list of covered files in the database and remove those which were never executed.
- Function Debloating: Function level debloating uses a compiler pass implemented inside DebloatFunctionVisitor class within web/admin/application/controllers/Software_file.php. debloat_functions($fk_software_files_description) function is responsible for this action. For each function, we check if any of the executable lines within that function were executed during the tests. If no line within a function is executed, then we remove the function and replace it with the place holder.
- Calls To Removed Files/Functions: We use a place holder to fill removed files and functions to stop further execution of the PHP code within the path that includes a removed functionality. This stops the application from entering the states that were not anticipated by developers. This place holder can be modified within Software_file.php. It currently shows an HTML error message to the user with the actual file or function that was removed and logs this event in the error_log of Apache.

Source Code

Mapping of vulnerabilities to source code: You can separately download the mapping of vulnerabilities to source code of applications. To ensure that the mappings point to the correct lines, use the specific version of applications that we used (Links are available below).
Mapped CVEs to vulnerable files and lines (CSV file).
Mapped CVEs to vulnerable functions (CSV file).

Pre-configured applications: Four pre-configured docker images that host versions of web applications used in our study along with File and Function level debloated versions are accessible below:

  • phpMyAdmin Docker images: Download (includes phpMyAdmin 4.0.0, 4.4.0, 4.6.0, 4.7.0)
  • MediaWiki Docker images: Download (includes MediaWiki 1.19.1, 1.21.1, 1.23.0, 1.24.0, 1.28.0)
  • Magento Docker images: Download (includes Magento 1.9.0, 2.0.5)
  • WordPress Docker images: Download (includes WordPress 3.9, 4.0, 4.2.3, 4.6, 4.7, 4.7.1)

Current web application configuration expects each web application to reside in the "web" directory itself. To test file and function level debloated variants, simply move their directories up from file_debloating or function_debloating directories to web.
The source code is hosted on Github at https://github.com/silverfoxy/PHPDebloating.
* docker and docker-compose packages are required to run this code.

Running the container: In order to build and run docker containers, after downloading your desired template, navigate to its root directory and run: 

docker-compose up
you can access the web applications at http://localhost:8085 and reports at http://localhost:8086/admin.

Running the usage profiles: In the paper, we mention Tutorials mapped through Selenium scripts. Monkey tests based on Gremlinsjs. Spider and Scanner from BurpSuite.

  • Tutorials (Selenium scripts): The scripts are located under Tests/Selenium-Tests/application_name. It requires Chrome and Firefox (only for Magento 2.0.5 tests) along with the webdrivers and selenium to run. Most of the tests will execute successfully regardless of the platform.
    * Magento 2.0.5 tests are stable only on Ubuntu and may sometimes fail to click certain buttons on Windows or Mac.
  • Monkey tests: The scripts are located under Tests/GremlinsJS/application_name.js. Install Tampermonkey extension on Chrome and import javascript files. Navigate to the target application and enable the script from Tampermonkey. To limit their execution time we used Tab sleep timer extension. We run separate tests for admin/registered/unregistered users.
  • Spider: BurpSuite Community Edition was used in our study. Point the spider to the home page of the application and give it the credentials to login.
  • Vulnerability Scanner: The scanner module from BurpSuite Pro was used for this part.

Debloating a new web application: To add a new web application, follow these steps:

  1. Move your web application files to "web" directory and make sure Dockerfiles/web/Dockerfile installs the required dependencies and prepares the web server.
  2. By placing the database backup sql file under Dockerfiles/db/entrypoint/ the database will be restored upon building the image. ِYour web application can access the database container at "db".
  3. Under administration panel, add your web application directory to the database. Update destructors and exit calls to comply to our structure under Debloating menu by adding your web application files to the database.
  4. Generate usage traffic that represents how users interact with the application to record code coverage.
  5. Map any known vulnerabilities to your application if you want to measure the effectiveness of debloating in terms of removed vulnerabilities.
  6. Under administration panel in Debloating page, choose your desired debloating granularity (File or Function level). Next, the application will be debloated and you will see a report on which files/functions were removed.
    * Make sure you maintain a separate copy of your original application as debloating will remove certain parts of your application.

Mapping web applications to versions in the database: The debloating engine needs to know which version of web applications is being used, you can either use cookies or environment variables to pass this information to the back end.

- Cookie: By setting the following cookies, the backend knows which application is being tested.
  • test_group: name of test category (e.g. "pma470_tutorials")
  • test_name: name of specific test (e.g. "drop database")
  • software_id: from code_coverage database (e.g. "1" for phpMyAdmin)
  • software_version_id: from code_coverage database (e.g. "1" for phpMyAdmin 4.0.0)
- Environment Variables: These values can be set within .htaccess in root directory of each web application. Values from cookies will override this setting. This method is specially useful where it is not possible to manually set cookies within the testing software for example the spider or scanner.
  • SetEnv lim_test_group "mgt205_scanner"
  • SetEnv lim_test_name "mgt205_scanner"
  • SetEnv lim_software_id "3"
  • SetEnv lim_software_version_id "11"
Temporarily Disabling Code Coverage Recording: Sometimes we need to stop code coverage reporting. To do that, stop PHP from prepending the code coverage logic to all PHP files by adding the following code to .htaccess.
  • php_value auto_prepend_file none

About

We are a team of security researchers at PragSec Lab, Stony Brook University (https://securitee.org).
For any queries or questions contact Babak Amin Azad at [email protected]

FAQ

- What does a debloated application look like in action?
Unless you trigger a removed part of the application, everything else looks identical. And a custom error message is displayed if a removed feature is executed. Here's a video of an exploit attempt on CVE-2016-4010 failing on debloated version of Magento 2.0.5. This attempt fails because the gadget chain relies on Credis_client class (redis client for Magento) being present which is removed after debloating.

- How are Object Injection Gadgets extracted?
Our current study is based on known gadget chains from popular PHP packages reported at PHPGGC library. After we debloat the web applications, we checked if these gadgets (the whole file or the magic functions) are removed or not.

- Can I run this software in a production environment?
XDebug, the PHP extension that is used to record line level code coverage hooks into Zend engine and has a noticeable overhead. In our setup, based on the four applications we tested, the page load time was increased 2-4 times. As such, this overhead may be unacceptable based on your setup. One solution is to record the coverage on a subset of users by load balancing. Another solution is to use record-and-replay proxies to record real traffic to the application and replay them offline.
A third solution is to optimize XDebug's code coverage engine and make it more efficient for our need. Currently it overloads over 47 op codes. As only detecting the coverage of files or functions is enough for our architecture, we can extend this module or use in-house implementations that decorate functions with code that records the coverage and achieve an acceptable overhead.