Skip to content
Log inStart free trial

GHSA-v35g-4rrw-h4fw CVE-2014-6072

Symfony Cross-Site Request Forgery vulnerability in the Web Profiler

High Packagist
Severity
8.1 / 10
High · CVSS 3.1
Exploit chance (EPSS)
—
No score published
Known exploited
No
Not in CISA's catalog
Weakness
CWE-94 Improper Control of Generation of Code ('Code Injection')
Fix
Available
2 packages have a fixed version

Description

All 2.0.X, 2.1.X, 2.2.X, 2.3.X, 2.4.X, and 2.5.X versions of the Symfony WebProfiler bundle are affected by this security issue.

This issue has been fixed in Symfony 2.3.19, 2.4.9, and 2.5.4. Note that no fixes are provided for Symfony 2.0, 2.1, and 2.2 as they are not maintained anymore.

Description

The Symfony Web Profiler is a great development tool, but it should not be enabled on production servers. If it is enabled in production, it must be properly secured so that only authorized people have access to it. Developers must be very cautious about this as the Web Profiler gives many sensitive information about a Symfony project and any attackers can exploit many of them. Just to name a few sensitive information: user logins, user cookies, executed SQL statements, ...

That being said, the import/export feature of the web profiler is exploitable even if the Web Profiler is secured as the form to import a profiler is not protected against CSRF attacks. Combined with the fact that profiles are imported as a PHP serialized string, it makes your application vulnerable to code injection.

Resolution

As the import/export feature of the Web Profiler is not that useful, and because PHP serialize/unserialize functions have a long history of vulnerabilities, I decided to remove this feature from the Web interface and move it as CLI commands.

If you were relying on this feature, you now need to use the profiler:import and profiler:export Symfony commands provided by the WebProfiler bundle from the command line interface.

Those commands are not enabled by default and must be activated explicitly. For Symfony 2.4+, you can import them in your app/config.yml configuration file:

import:
   - { resource: "%kernel.root_dir%/../vendor/symfony/symfony/src/Symfony/Bundle/WebProfilerBundle/Resources/config/commands.xml" }

For Symfony 2.3, you can use the following snippet of code in app/console:

$kernel = new AppKernel($env, $debug);
$application = new Application($kernel);
if ($kernel->getContainer()->has('profiler')) {
    $profiler = $kernel->getContainer()->get('profiler');
    $application->add(new ImportCommand($profiler));
    $application->add(new ExportCommand($profiler));
}
$application->run($input);

At this point, I want to reiterate that you should never enable the Symfony Web Profiler on your production servers as this is a development tool. And if you need to enable it, double-check that it is properly secured.

The patch for this issue is available here: https://github.com/symfony/symfony/pull/11832

Affected versions

Packagist

PackageVulnerableFixed in
symfony/symfony
>= 2.0.0, < 2.3.19
2.3.19
symfony/symfony
>= 2.4.0, < 2.4.9
2.4.9
symfony/symfony
>= 2.5.0, < 2.5.4
2.5.4
symfony/web-profiler-bundle
>= 2.0.0, < 2.3.19
2.3.19
symfony/web-profiler-bundle
>= 2.4.0, < 2.4.9
2.4.9
symfony/web-profiler-bundle
>= 2.5.0, < 2.5.4
2.5.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

symfony/symfony Packagist → 2.3.19

composer
composer require symfony/symfony:^2.3.19

symfony/web-profiler-bundle Packagist → 2.3.19

composer
composer require symfony/web-profiler-bundle:^2.3.19

Severity breakdown

CVSS 3.1 8.1

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-94: Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

How to prevent it
  • Architecture and Design: Refactor your program so that you do not have to dynamically generate code.
  • Architecture and Design: Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
  • Testing: Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
  • Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
  • Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
  • Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

References

Other links

Timeline

  1. Published
  2. Last updated by the source
AdvisorySeverityWhy it's related
GHSA-2v3c-qxhr-7vpv
Symfony: Unbounded Recursion in the YAML Inline Lexer Lets a Single Document Crash the Process
High Also affects symfony/symfony
GHSA-r925-mgvr-h9cc
Symfony: ReDoS in HeaderUtils::split() Reachable Through the Cache-Control Request Header
High Also affects symfony/symfony
GHSA-h5x3-xfc9-m39h
Symfony: UrlGenerator Dot-Segment Encoding Skips Every Other Chained `../` or `./` → Generated URL Collapses Off-Route Under RFC 3986 Normalization
Medium Also affects symfony/symfony
GHSA-v3wm-qf9p-c549
Symfony: HtmlSanitizer URL Parser Deny Gates Underinclusive: Percent-Encoded BiDi Marks and Unicode Whitespace Bypass Visual-Spoofing Defense
Medium Also affects symfony/symfony
GHSA-rrj9-5q2j-4gvr
Symfony: Mailomat Mailer Webhook Parser Reads the HMAC Algorithm from the Request: Signature Algorithm Downgrade
Medium Also affects symfony/symfony
GHSA-38cx-cq6f-5755
Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient
High Also affects symfony/symfony
GHSA-6h46-9jf5-q59x
Symfony: Security Firewall Bypass via failure_forward Subrequest: Unauthenticated Access to access_control-Protected GET Routes
High Also affects symfony/symfony
GHSA-x5qj-865h-mgvm
Symfony: HtmlSanitizer UrlAttributeSanitizer Misses URL Attributes
Medium Also affects symfony/symfony
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor