In Symfony before versions 5.0.5 and 4.4.5, some properties of the Exception were not properly escaped when the `ErrorHandler` rendered it…
GitHub_M·CWE-209·Published 2020-03-30
In Symfony before versions 5.0.5 and 4.4.5, some properties of the Exception were not properly escaped when the `ErrorHandler` rendered it stacktrace. In addition, the stacktrace were displayed even in a non-debug configuration. The ErrorHandler now escape alls properties of the exception, and the stacktrace is only display in debug configuration. This issue is patched in symfony/http-foundation versions 4.4.5 and 5.0.5
In Symfony before versions 5.0.5 and 4.4.5, some properties of the Exception were not properly escaped when the `ErrorHandler` rendered it stacktrace. In addition, the stacktrace were displayed even in a non-debug configuration. The ErrorHandler now escape alls properties of the exception, and the stacktrace is only display in debug configuration. This issue is patched in symfony/http-foundation versions 4.4.5 and 5.0.5
Description ----------- When `ErrorHandler` renders an exception HTML page, it uses un-escaped properties from the related Exception class to render the stacktrace. The security issue comes from the fact that the stacktraces were also displayed in non-`debug` environments. Resolution ---------- The `ErrorHandler` class now escapes all properties coming from the related Exception, and the stacktrace is not displayed anymore in non-`debug` environments. The patches for this issue are available [here](https://github.com/symfony/symfony/commit/cf80224589ac05402d4f72f5ddf80900ec94d5ad) and [here](https://github.com/symfony/symfony/commit/629d21b800a15dc649fb0ae9ed7cd9211e7e45db) for branch 4.4. Credits ------- I would like to thank Luka Sikic for reporting & Yonel Ceruto and Jérémy Derussé for fixing the issue.
Description ----------- When `ErrorHandler` renders an exception HTML page, it uses un-escaped properties from the related Exception class to render the stacktrace. The security issue comes from the fact that the stacktraces were also displayed in non-`debug` environments. Resolution ---------- The `ErrorHandler` class now escapes all properties coming from the related Exception, and the stacktrace is not displayed anymore in non-`debug` environments. The patches for this issue are available [here](https://github.com/symfony/symfony/commit/cf80224589ac05402d4f72f5ddf80900ec94d5ad) and [here](https://github.com/symfony/symfony/commit/629d21b800a15dc649fb0ae9ed7cd9211e7e45db) for branch 4.4. Credits ------- I would like to thank Luka Sikic for reporting & Yonel Ceruto and Jérémy Derussé for fixing the issue.
En Symfony versiones anteriores a 5.0.5 y 4.4.5, algunas propiedades de la Excepción no fueron escapados apropiadamente cuando el "ErrorHandler" la renderizó en stacktrace. Además, el stacktrace fue desplegado incluso en una configuración sin depuración. ErrorHandler ahora escapa de todas las propiedades de la excepción, y el stacktrace se muestra solo en la configuración de depuración. Este problema está parcheado en Symfony/http-foundation versiones 4.4.5 y 5.0.5.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 2.0 | Primary | NVD | 5.5 | 8.0 | 4.9 | AV:N/AC:L/Au:S/C:P/I:P/A:N |
| 3.1 | Primary | NVD | 5.4 | 2.8 | 2.5 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N |
| 3.1 | Primary | cve.org | 4.6 | — | — | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N |
| 3.1 | Primary | cve.org | 4.6 | — | — | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N |
| 3.1 | Secondary | NVD | 4.6 | 2.1 | 2.5 | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N |
| 3.1 | Secondary | GHSA | 4.6 | — | — | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N |