CVE-2024-28859

Symfony1 is a community fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support. Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods. These methods are called when php destroys the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. This may allow an attacker to execute any PHP command which leads to remote code execution. This issue has been addressed in version 1.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Symfony1 is a community fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support. Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods. These methods are called when php destroys the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. This may allow an attacker to execute any PHP command which leads to remote code execution. This issue has been addressed in version 1.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Summary

Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project.

Details

This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. For example:

 public function executeIndex(sfWebRequest $request)
  {
    $a = unserialize($request->getParameter('user'));
  }

We will make the assumption this is the case in the rest of this explanation.

Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods like for instance Swift_KeyCache_DiskKeyCache :

  public function __destruct()
  {
    foreach ($this->_keys as $nsKey=>$null)
    {
      $this->clearAll($nsKey);
    }
  }

This method is called when php destroy the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. sfOutputEscaperArrayDecorator implements such interface. Here is the call made on offsetGet():

  public function offsetGet($offset)
  {
    return sfOutputEscaper::escape($this->escapingMethod, $this->value[$offset]);
  }

Which trigger escape() in sfOutputEscaper class with attacker controlled parameters from deserialized object with $this->escapingMethod and $this->value[$offset]:

  public static function escape($escapingMethod, $value)
  {
    if (null === $value)
    {
      return $value;
    }

    // Scalars are anything other than arrays, objects and resources.
    if (is_scalar($value))
    {
      return call_user_func($escapingMethod, $value);
    }

Which calls call_user_func with previous attacker controlled input.

However, most recent versions of Swift Mailer are not vulnerable anymore. A fix has been done with commit 5878b18b36c2c119ef0e8cd49c3d73ee94ca0fed to prevent #arbitrary deserialization. This commit has been shipped with version 6.2.5 of Swift Mailer.

Concreetly, __wakeup() have been implemented to clear attributes' values:

  public function __wakeup()
  {
      $this->keys = [];
  }

And/or prevent any deserialization:

  public function __wakeup()
  {
      throw new \BadMethodCallException('Cannot unserialize '.__CLASS__);
  }

If you install last version 1.5 with composer, you will end-up installing last 6.x version of Swift Mailer containing the previous fixes. Here is an extract of the composer.lock:

{
  "name": "friendsofsymfony1/symfony1",
  "version": "v1.5.15",
  "source": {
      "type": "git",
      "url": "https://github.com/FriendsOfSymfony1/symfony1.git",
      "reference": "9945f3f27cdc5aac36f5e8c60485e5c9d5df86f2"
  },
  "require": {
      "php": ">=5.3.0",
      "swiftmailer/swiftmailer": "~5.2 || ^6.0"
  },
  ...
  {
    "name": "swiftmailer/swiftmailer",
    "version": "v6.3.0",
  ...
  }
}

By reviewing releases archives, composer.json targets vulnerable branch 5.x before Symfony 1.5.13 included:

{
    "name": "friendsofsymfony1/symfony1",
    "description": "Fork of symfony 1.4 with dic, form enhancements, latest swiftmailer and better performance",
    "type": "library",
    "license": "MIT",
    "require": {
        "php" : ">=5.3.0",
        "swiftmailer/swiftmailer": "~5.2"
    },
    ...

So, the gadget chain is valid for at least versions until 1.5.13.

However, if you install last version of Symfony with git as described in the README, Swift Mailer vendors is referenced through a git sub-module…

Symfony1 is a community fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support. Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods. These methods are called when php destroys the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. This may allow an attacker to execute any PHP command which leads to remote code execution. This issue has been addressed in version 1.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Symfony1 is a community fork of symfony 1.4 with DIC, form enhancements, latest Swiftmailer, better performance, composer compatible and PHP 8 support. Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project. This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods. These methods are called when php destroys the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. This may allow an attacker to execute any PHP command which leads to remote code execution. This issue has been addressed in version 1.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Summary

Symfony 1 has a gadget chain due to vulnerable Swift Mailer dependency that would enable an attacker to get remote code execution if a developer unserialize user input in his project.

Details

This vulnerability present no direct threat but is a vector that will enable remote code execution if a developper deserialize user untrusted data. For example:

 public function executeIndex(sfWebRequest $request)
  {
    $a = unserialize($request->getParameter('user'));
  }

We will make the assumption this is the case in the rest of this explanation.

Symfony 1 depends on Swift Mailer which is bundled by default in vendor directory in the default installation since 1.3.0. Swift Mailer classes implement some __destruct() methods like for instance Swift_KeyCache_DiskKeyCache :

  public function __destruct()
  {
    foreach ($this->_keys as $nsKey=>$null)
    {
      $this->clearAll($nsKey);
    }
  }

This method is called when php destroy the object in memory. However, it is possible to include any object type in $this->_keys to make PHP access to another array/object properties than intended by the developer. In particular, it is possible to abuse the array access which is triggered on foreach($this->_keys ...) for any class implementing ArrayAccess interface. sfOutputEscaperArrayDecorator implements such interface. Here is the call made on offsetGet():

  public function offsetGet($offset)
  {
    return sfOutputEscaper::escape($this->escapingMethod, $this->value[$offset]);
  }

Which trigger escape() in sfOutputEscaper class with attacker controlled parameters from deserialized object with $this->escapingMethod and $this->value[$offset]:

  public static function escape($escapingMethod, $value)
  {
    if (null === $value)
    {
      return $value;
    }

    // Scalars are anything other than arrays, objects and resources.
    if (is_scalar($value))
    {
      return call_user_func($escapingMethod, $value);
    }

Which calls call_user_func with previous attacker controlled input.

However, most recent versions of Swift Mailer are not vulnerable anymore. A fix has been done with commit 5878b18b36c2c119ef0e8cd49c3d73ee94ca0fed to prevent #arbitrary deserialization. This commit has been shipped with version 6.2.5 of Swift Mailer.

Concreetly, __wakeup() have been implemented to clear attributes' values:

  public function __wakeup()
  {
      $this->keys = [];
  }

And/or prevent any deserialization:

  public function __wakeup()
  {
      throw new \BadMethodCallException('Cannot unserialize '.__CLASS__);
  }

If you install last version 1.5 with composer, you will end-up installing last 6.x version of Swift Mailer containing the previous fixes. Here is an extract of the composer.lock:

{
  "name": "friendsofsymfony1/symfony1",
  "version": "v1.5.15",
  "source": {
      "type": "git",
      "url": "https://github.com/FriendsOfSymfony1/symfony1.git",
      "reference": "9945f3f27cdc5aac36f5e8c60485e5c9d5df86f2"
  },
  "require": {
      "php": ">=5.3.0",
      "swiftmailer/swiftmailer": "~5.2 || ^6.0"
  },
  ...
  {
    "name": "swiftmailer/swiftmailer",
    "version": "v6.3.0",
  ...
  }
}

By reviewing releases archives, composer.json targets vulnerable branch 5.x before Symfony 1.5.13 included:

{
    "name": "friendsofsymfony1/symfony1",
    "description": "Fork of symfony 1.4 with dic, form enhancements, latest swiftmailer and better performance",
    "type": "library",
    "license": "MIT",
    "require": {
        "php" : ">=5.3.0",
        "swiftmailer/swiftmailer": "~5.2"
    },
    ...

So, the gadget chain is valid for at least versions until 1.5.13.

However, if you install last version of Symfony with git as described in the README, Swift Mailer vendors is referenced through a git sub-module…

TuxCare rebuilt swiftmailer/swiftmailer to address 1 CVE. Fixed in 5.4.12-p1+tuxcare.

TuxCare rebuilt swiftmailer/swiftmailer to address 2 CVEs. Fixed in 6.0.2-p1+tuxcare.