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.
-
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. -
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.
-
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. -
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
-
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. -
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
- 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
@basav most of this looks like false positives, but it would be helpful if you would provide the full file paths
Thanks. Probably false
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
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.
knaddison blog | Morris Animal Foundation
team, Any updates on this?
team, Any updates on this?
Have you read this page? How to report a security issue
@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
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
I did not review the js issues.
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.
The only way to get the results of phpinfo is to be logged in as a user with administrator permissions.
knaddison blog | Morris Animal Foundation
Thanks for the
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.