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
yaml 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.
php - return isstring($variable) ? sprintf('"%s"', $variable) : $variable; + return isstring($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;
Acknowledgements
This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!
For more information
If you have any questions or comments about this advisory: Email us at security@sylius.com
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
yaml syliusgrid: 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.
php - return isstring($variable) ? sprintf('"%s"', $variable) : $variable; + return isstring($variable) ? sprintf('"%s"', addslashes($variable)) : $variable;
Acknowledgements
This security issue has been reported by Craig Blanchette (@isometriks), thanks a lot!
For more information
If you have any questions or comments about this advisory: Email us at security@sylius.com
In affected versions of Sylius, exception messages from internal exceptions (like database exception) are wrapped by \Symfony\Component\Security\Core\Exception\AuthenticationServiceException and propagated through the system to UI. Therefore, some internal system information may leak and be visible to the customer. A validation message with the exception details will be presented to the user when one will try to log into the shop. This has been patched in versions 1.3.14, 1.4.10, 1.5.7, and 1.6.3.
An issue was discovered in Sylius products. Missing input sanitization in sylius/sylius 1.0.x through 1.0.18, 1.1.x through 1.1.17, 1.2.x through 1.2.16, 1.3.x through 1.3.11, and 1.4.x through 1.4.3 and sylius/grid 1.0.x through 1.0.18, 1.1.x through 1.1.18, 1.2.x through 1.2.17, 1.3.x through 1.3.12, 1.4.x through 1.4.4, and 1.5.0 allows an attacker (an admin in the sylius/sylius case) to perform XSS by injecting malicious code into a field displayed in a grid with the "string" field type. The contents are an object, with malicious code returned by the toString() method of that object.