Symfony

Affected versions Symfony 2.8.0 to 2.8.36, 3.3.0 to 3.3.16, 3.4.0 to 3.4.6, and 4.0.0 to 4.0.6 versions of the Symfony LDAP component are affected by this security issue. The issue has been fixed in Symfony 2.8.37, 3.3.17, 3.4.7, and 4.0.7. 4.1.0 ... [More] has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description This is a continuation of CVE-2016-2403, where we missed checking for a null password. Resolution The fix was submitted as a regular pull request (we did not realize it was a security issue when reviewing and merging the pull request). The patch was not part of any 3.3 releases, but part of the 3.3.17 version released today. Credits I would like to thank Théo Bougé from Scalian for reporting the issue and Smaine Milianni for fixing it. Be trained by Symfony experts - 2018-06-4 Clichy - 2018-06-4 Clichy - 2018-06-6 Clichy [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony http-foundation component are affected by this security issue. The issue has been fixed in Symfony 2.7.48 ... [More] , 2.8.41, 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description The PDOSessionHandler class allows to store sessions on a PDO connection. Under some configurations (see below) and with a well-crafted payload, it was possible to do a denial of service on a Symfony application without too much resources. An application is vulnerable when: It is using PDOSessionHandler to store its sessions; And it uses MySQL as a backend for sessions managed by PDOSessionHandler; And the SQL mode does not contain STRICT_ALL_TABLES or STRICT_TRANS_TABLES (check via SELECT @@sql_mode). When an application has this configuration, doing a denial of service is made easier as a well-crafted session leads to an infinite loop in the code. Resolution We fixed this issue by avoiding the inifinite loop. Credits I would like to thank Federico Stange for reporting this security issue and for working with us trying to figure out when this issue occurred, Nicolas Grekas for working on a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-06-6 Clichy - 2018-06-11 Paris - 2018-06-11 Paris [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony http-foundation component are affected by this security issue. The issue has been fixed in Symfony 2.7.48 ... [More] , 2.8.41, 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description The PDOSessionHandler class allows to store sessions on a PDO connection. Under some configurations (see below) and with a well-crafted payload, it was possible to do a denial of service on a Symfony application without too much resources. An application is vulnerable when: It is using PDOSessionHandler to store its sessions; And it uses MySQL as a backend for sessions managed by PDOSessionHandler; And the SQL mode does not contain STRICT_ALL_TABLES or STRICT_TRANS_TABLES (check via SELECT @@sql_mode). When an application has this configuration, doing a denial of service is made easier as a well-crafted session leads to an infinite loop in the code. Resolution We fixed this issue by avoiding the inifinite loop. Credits I would like to thank Federico Stange for reporting this security issue and for working with us trying to figure out when this issue occurred, Nicolas Grekas for working on a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-05-28 Paris - 2018-05-28 Paris - 2018-05-30 Paris [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony http-foundation component are affected by this security issue. The issue has been fixed in Symfony 2.7.48 ... [More] , 2.8.41, 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description The PDOSessionHandler class allows to store sessions on a PDO connection. Under some configurations (see below) and with a well-crafted payload, it was possible to do a denial of service on a Symfony application without too much resources. An application is vulnerable when: It is using PDOSessionHandler to store its sessions; And it uses MySQL as a backend for sessions managed by PDOSessionHandler; And the SQL mode does not contain STRICT_ALL_TABLES or STRICT_TRANS_TABLES (check via SELECT @@sql_mode). When an application has this configuration, doing a denial of service is made easier as a well-crafted session leads to an infinite loop in the code. Resolution We fixed this issue by avoiding the inifinite loop. Credits I would like to thank Federico Stange for reporting this security issue and for working with us trying to figure out when this issue occurred, Nicolas Grekas for working on a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-06-4 Clichy - 2018-06-4 Clichy - 2018-06-6 Clichy [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony Security component are affected by this security issue. The issue has been fixed in Symfony 2.7.48, 2.8.41 ... [More] , 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description By default, a user’s session is invalidated when the user is logged out. This behavior can be disabled through the invalidate_session option. In this case, CSRF tokens where not erased during logout which allowed for CSRF token fixation. Resolution We fixed this issue by clearing all CSRF tokens when the user is logged out. Credits I would like to thank Kévin Liagre for reporting this security issue, Christian Flothmann for working on a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-05-30 Paris - 2018-06-4 Clichy - 2018-06-4 Clichy [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony Security component are affected by this security issue. The issue has been fixed in Symfony 2.7.48, 2.8.41 ... [More] , 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description This is a continuation of CVE-2017-16652, where we missed an edge case (when the security.http_utils was inlined by the container). Resolution The fix solves the issue for the edge case. Credits I would like to thank Antal Áron for reporting this security issue, Nicolas Grekas for providing a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-06-4 Clichy - 2018-06-4 Clichy - 2018-06-6 Clichy [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony Security component are affected by this security issue. The issue has been fixed in Symfony 2.7.48, 2.8.41 ... [More] , 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description This is a continuation of CVE-2017-16652, where we missed an edge case (when the security.http_utils was inlined by the container). Resolution The fix solves the issue for the edge case. Credits I would like to thank Antal Áron for reporting this security issue, Nicolas Grekas for providing a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-05-28 Paris - 2018-05-28 Paris - 2018-05-30 Paris [Less]

Affected versions Symfony 2.8.0 to 2.8.36, 3.3.0 to 3.3.16, 3.4.0 to 3.4.6, and 4.0.0 to 4.0.6 versions of the Symfony LDAP component are affected by this security issue. The issue has been fixed in Symfony 2.8.37, 3.3.17, 3.4.7, and 4.0.7. 4.1.0 ... [More] has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description This is a continuation of CVE-2016-2403, where we missed checking for a null password. Resolution The fix was submitted as a regular pull request (we did not realize it was a security issue when reviewing and merging the pull request). The patch was not part of any 3.3 releases, but part of the 3.3.17 version released today. Credits I would like to thank Théo Bougé from Scalian for reporting the issue and Smaine Milianni for fixing it. Be trained by Symfony experts - 2018-05-28 Paris - 2018-05-28 Paris - 2018-05-30 Paris [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10, and 4.0.0 to 4.0.10 versions of the Symfony http-foundation component are affected by this security issue. The issue has been fixed in Symfony 2.7.48 ... [More] , 2.8.41, 3.3.17, 3.4.11, and 4.0.11. 4.1.0 has also been fixed before its final release. Note that no fixes are provided for Symfony 3.0, 3.1, and 3.2 as they are not maintained anymore. Description The PDOSessionHandler class allows to store sessions on a PDO connection. Under some configurations (see below) and with a well-crafted payload, it was possible to do a denial of service on a Symfony application without too much resources. An application is vulnerable when: It is using PDOSessionHandler to store its sessions; And it uses MySQL as a backend for sessions managed by PDOSessionHandler; And the SQL mode does not contain STRICT_ALL_TABLES or STRICT_TRANS_TABLES (check via SELECT @@sql_mode). When an application has this configuration, doing a denial of service is made easier as a well-crafted session leads to an infinite loop in the code. Resolution We fixed this issue by avoiding the inifinite loop. Credits I would like to thank Federico Stange for reporting this security issue and for working with us trying to figure out when this issue occurred, Nicolas Grekas for working on a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-05-30 Paris - 2018-06-4 Clichy - 2018-06-4 Clichy [Less]

Affected versions Symfony 2.7.0 to 2.7.47, 2.8.0 to 2.8.40, 3.3.0 to 3.3.16, 3.4.0 to 3.4.10 and 4.0.0 to 4.0.10 versions of the Symfony Security component are affected by this security issue. The issue has been fixed in Symfony 2.7.48, 2.8.41 ... [More] , 3.3.17, 3.4.11, and 4.0.11. Note that no fixes are provided for Symfony 3.0, 3.1 and 3.2 as they are not maintained anymore. Description A session fixation vulnerability within the "Guard" login feature may allow an attacker to impersonate the victim towards the web application if the session id value was previously known to the attacker. The described vulnerability allows an attacker to access a Symfony web application with the attacked user's permissions. The attack requires that the "Guard authentication" login feature is used by the application. Additionally the attacker either got access to the PHPSESSID cookie value or has successfully set a new value in the user's browser. Because of its requirements the described vulnerability poses a low risk only. Resolution The fix migrates the session after a successful login via the "Guard" login feature. Additionally, the session was also migrated after successful login of several other authentication systems that are rarely used in a session environment (like a browser). Because of this, a session fixation exploit is highly unlikely. However, a patch was included to be as secure as possible. Credits I would like to thank Chris Wilkinson for reporting this security issue, Ryan Weaver for providing a fix, and the Symfony Core Team for reviewing the patch. Be trained by Symfony experts - 2018-05-30 Paris - 2018-06-4 Clichy - 2018-06-4 Clichy [Less]