12.12.2020
2 min. read
Categories: News Technical
Security releases announcement – August 2020

The quality of our software has always been the most important thing for us. Today we published fixes for two security vulnerabilities found in Sylius/SyliusResourceBundle.

Is my store affected by this vulnerability?

Generally speaking, if you haven’t updated your dependencies after 18.08.2020, your store is vulnerable. The affected component is sylius/resource-bundle which is versioned independently from sylius/sylius. If you use Sylius v1.7, you most likely use ResourceBundle v1.6. You can check which specific version of sylius/resource-bundle you have installed by running composer show sylius/resource-bundle.Another way to check whether your application contains known vulnerabilities is to use Symfony binary (https://symfony.com/download). Run symfony check:security to scan your application.

Read more here (https://symfony.com/doc/current/setup.html#checking-security-vulnerabilities).

CVE-2020-15143: Remote Code Execution in ParametersParser while using request parameters inside expression language

The original security advisory has been published on GitHub at Sylius/SyliusResourceBundle repository.

Impact

Request parameters injected inside an expression evaluated by symfony/expression-language package haven’t been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution.

The vulnerable versions include: <=1.3.13 || >=1.4.0 <=1.4.6 || >=1.5.0 <=1.5.1 || >=1.6.0 <=1.6.3.

Example

foo:
  path: /foo/{id}
  defaults:
    _sylius:
      repository:
        method: findSome
        arguments:
          entity: "expr:service('repository').find($id)"

In this case, $id can be prepared in a way that calls other services.

If you visit /foo/"~service('doctrine').getManager().getConnection().executeQuery("DELETE * FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE * FROM TABLE")~""), which will execute a query on the currently connected database.

To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language.

Patches

This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4. Versions prior to 1.3 were not patched.

Workarounds

The fix requires adding addslashes in ParametersParser::parseRequestValueExpression to sanitize user input before evaluating it using the expression language.

- return is_string($variable) ? sprintf('"%s"', $variable) : $variable;
+ return is_string($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;

Acknowledgements

This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!

CVE-2020-15146: Remote Code Execution in OptionsParser while using request parameters inside expression language

The original security advisory has been published on GitHub at Sylius/SyliusResourceBundle repository.

Impact

Request parameters injected inside an expression evaluated by symfony/expression-language package haven’t been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution.

The vulnerable versions include: <=1.3.13 || >=1.4.0 <=1.4.6 || >=1.5.0 <=1.5.1 || >=1.6.0 <=1.6.3.

Example

sylius_grid:
  grids:
    foo:
      fields:
        bar:
          options:
            baz: "expr:service('sylius.repository.product').find($id)"

In this case, $id can be prepared in a way that calls other services.

If you visit
/route id="~service('doctrine').getManager().getConnection().executeQuery("DELETE * FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE * FROM TABLE")~""), which will execute a query on the currently connected database.

To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language.

Patches

This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4. Versions prior to 1.3 were not patched.

Workarounds

The fix requires adding addslashes in OptionsParser::parseOptionExpression to sanitize user input before evaluating it using the expression language.

- return is_string($variable) ? sprintf('"%s"', $variable) : $variable;
+ return is_string($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;

Acknowledgements

This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!

Share:
Kamil Kokot
A huge talent and a crazy imagination owner. Exceptional joker. Programmer by day, Krzysztof Krawczyk (famous polish evergreen songs composer) fan by night. Frequent concert-goer who loves to learn useless skills.
More from our blog
Technical 2 min read 24.06.2020
This time let’s take a look at Sylius Plus and our new apple of the eye - the Sylius Plus Loyalty System. Read More
News Technical 2 min read 01.06.2020
The benefits of having a way to analyze sales in your eCommerce management system are undeniable. It’s an easy way to check some of the most important data about your shop’s performance. Read More
Business Ecosystem News 2 min read 18.05.2020
Mollie and Sylius have just become Strategic Technological Partners. It means that from now on Mollie is Sylius' preferred payment service provider (PSP) for merchants in Benelux, DACH, and France. Read More
Comments