Drupal 8.3.7 - Code scanning issues by Fortify tool

basav's picture

Hi Team,

Our security team used Fortify tool to do a static code of Drupal 8.3.7 code base and found some issues. Mostly json injection, XSS etc

How are these threats perceived by the community? Are there any security drupal patches available which fixes these issues?

Cross-Site Scripting: DOM
1. backbone.js, line 1678 (Cross-Site Scripting: DOM)
The method start() in backbone.js sends unvalidated data to a web browser on line
1678, which can result in the browser executing malicious code.

  1. backbone-min.js, line 1 (Cross-Site Scripting: DOM)
    The method start() in backbone-min.js sends unvalidated data to a web browser on
    line 1, which can result in the browser executing malicious code.

  2. backbone.js, line 1827 (Cross-Site Scripting: DOM)
    The method _updateHash() in backbone.js sends unvalidated data to a web browser
    on line 1827, which can result in the browser executing malicious code.

Path Manipulation
1. bootstrap.inc, line 659 (Path Manipulation)
Abstract: Attackers can control the filesystem path argument to file_get_contents() at
bootstrap.inc line 659, which allows them to access or modify otherwise protected
files.

  1. bootstrap.inc, line 659 (Path Manipulation)
    Attackers can control the filesystem path argument to file_get_contents() at
    bootstrap.inc line 659, which allows them to access or modify otherwise protected
    files.

  2. build_phar.php, line 35 (Path Manipulation)
    Attackers can control the filesystem path argument to file_get_contents() at
    build_phar.php line 35, which allows them to access or modify otherwise protected
    files.

Open Redirect
1. ajax.js, line 1164 (Open Redirect)
The file ajax.js passes unvalidated data to an HTTP redirect function on line 1164.
Allowing unvalidated input to control the URL used in a redirect can aid phishing
attacks.

System Information Leak: External

  1. Process.php, line 1313 (System Information Leak: External)
    The program might reveal system data or debugging information in Process.php with
    a call to phpinfo() on line 1313. The information revealed by phpinfo() could help an
    adversary form a plan of attack.

  2. SystemInfoController.php, line 62 (System Information Leak: External)
    The program might reveal system data or debugging information in
    SystemInfoController.php with a call to phpinfo() on line 62. The information
    revealed by phpinfo() could help an adversary form a plan of attack.

JSON Injection

  1. Json.php, line 143 (JSON Injection)
    On line 143 of Json.php, the method parse() writes unvalidated input into JSON. This
    call could allow an attacker to inject arbitrary elements or attributes into the JSON
    entity.

Thanks

Comments

@basav most of this looks

pwolanin's picture

@basav most of this looks like false positives, but it would be helpful if you would provide the full file paths

Thanks. Probably false

basav's picture

Thanks. Probably false positives. But the security team is not buying it.

Below are the details as requested:

drupal-8.3.7/core/assets/vendor/backbone/backbone.js
drupal-8.3.7/core/includes/bootstrap.inc
drupal-8.3.7/vendor/paragonie/random_compat/other/build_phar.php
drupal-8.3.7/core/misc/ajax.js
drupal-8.3.7/vendor/symfony/process/Process.php
drupal-8.3.7/core/modules/system/src/Controller/SystemInfoController.php
drupal-8.3.7/vendor/easyrdf/easyrdf/lib/EasyRdf/Parser/Json.php

drupal-8.3.7/vendor/paragonie

greggles's picture

drupal-8.3.7/vendor/paragonie/random_compat/other/build_phar.php
drupal-8.3.7/vendor/symfony/process/Process.php
drupal-8.3.7/vendor/easyrdf/easyrdf/lib/EasyRdf/Parser/Json.php

These 3 files are part of a complete Drupal site, but are not maintained by the Drupal project.

  1. Verify the issue is valid - most tools like Fortify find false positives so it is up to you as the user of that tool to verify the issue.
  2. If it is valid, report the problem to the upstream mantainer.

team, Any updates on this?

basav's picture

team, Any updates on this?

Justin Freeman's picture

@basav,

Have you read this page? How to report a security issue with Drupal core, contrib or Drupal.org
https://www.drupal.org/node/101494

Might want to follow the procedure outlined to get a better response.

Agileware, Australian Drupal Developers
http://agileware.com.au

As Peter indicated, these

mlhess's picture

As Peter indicated, these look like false positives, if you have a path to exploit, please create an issue above as Justin says.

I did not review the js

greggles's picture

I did not review the js issues.

1. bootstrap.inc, line 659 (Path Manipulation)

This seems possible, but I believe there is validation along the way to ensure the only paths that can be passed are valid for the user. You should ask your security team for more details about how to exploit the issue. If they can provide steps to exploit, please report that to the private issue tracker.

SystemInfoController.php, line 62 (System Information Leak: External)
The program might reveal system data or debugging information in
SystemInfoController.php with a call to phpinfo() on line 62. The information
revealed by phpinfo() could help an adversary form a plan of attack.

The only way to get the results of phpinfo is to be logged in as a user with administrator permissions.

Thanks for the

basav's picture

Thanks for the response...Regarding Path Manipulation, I did not get any specific steps for exploitation for this case i.e. boothstrap.inc

Below is the generic explanation from Fortify side regarding Path Manipulation.

Explanation:

Path manipulation errors occur when the following two conditions are met:
1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.
For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled
by the attacker.
Example 1: The following code uses input from an HTTP request to create a file name. The programmer has not considered the
possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete
one of its own configuration files.
$rName = $_GET['reportName'];
$rFile = fopen("/usr/local/apfr/reports/" . rName,"a+");
...
unlink($rFile);
Example 2: The following code uses input from a configuration file to determine which file to open and echo back to the user. If
the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file
on the system that ends with the extension .txt.
...
$filename = $CONFIG_TXT['sub'] . ".txt";
$handle = fopen($filename,"r");
$amt = fread($handle, filesize($filename));
echo $amt;
...

Recommendations:

The best way to prevent path manipulation is with a level of indirection: create a list of legitimate resource names that a user is
allowed to specify, and only allow the user to select from the list. With this approach the input provided by the user is never used
directly to specify the resource name.
In some situations this approach is impractical because the set of legitimate resource names is too large or too hard to keep track
of. Programmers often resort to blacklisting in these situations. Blacklisting selectively rejects or escapes potentially dangerous
characters before using the input. However, any such list of unsafe characters is likely to be incomplete and will almost certainly
become out of date. A better approach is to create a whitelist of characters that are allowed to appear in the resource name and
accept input composed exclusively of characters in the approved set.

I have emailed all these security findings to drupal security team.