SoftwareSecurity2014/Group 12/Code Scanning

Fortify

The OWASP ASVS document lists for each verification level the corresponding verification requirements. We focus on verification requirement 5 (input validation) and for verification level 1B the following two requirements need to be satisfied:

• V5.1: Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.
• V5.2: Verify that a positive validation pattern is defined and applied to all input.

(Erik: For this PHP application buffer overflows are largely out-of-scope of course, unless there are calls to eg. OS library calls that might have buffer overflows.

A positive validation pattern is defined by the OWASP organization as a specific type of data validation strategy. Positive validation embraces the idea of accepting input data only when it matches known `safe' values.
Using the Fortify Scan Wizard utility we were able to analyze the Joomla-3.1.0 source code and produce a list of the vulnerabilities found, each being of a certain type. Due to the large number of vulnerabilities found we are not able to elaborate upon all vulnerabilities, we will discuss only the vulnerabilities relevant for our input validation requirement. The report generated by Fortify indicates that many of the critical vulnerabilities are caused by the lack of (or improper) input validation.

Critical priority issues

Using the Fortify Audit Workbench we found 93 critical vulnerabilities. With regard to our requirement, there are three categories of vulnerabilities that are relevant for satisfying our requirement. These are: Command Injection(5 issues), Open Redirect(1 issue) and Path Manipulation(71 issues)

Command Injection

Error 1
The first vulnerability detected by Fortify was in simplepie.php:

$data = unserialize($row[1]);

Abstract: Line 8978 in simplepie.php calls unserialize() with a command built from untrusted data. This call can cause the program to execute malicious commands on behalf of an attacker.
The row argument may be built from untrusted data essentially allowing a potential attacker to execute malicious commands. If we look at where the row argument comes from, we notice that the row variable is initialized via the following statement:

$row = mysql_fetch_row($query)

So in fact rows are extracted from a SQL database. This means that in order for an attacker to insert malicious code via the above mentioned vulnerability, the attacker needs to be able to pollute the database with malicious commands. (Erik: Fortify tries to do some data flow analysis, but there are limits what it can do, so I'm not surprised that here it gives up and warns about what is probably a false positive)

Open redirect

Error 1
Another vulnerability was categorized by Fortify as a `Open Redirect' vulnerability meaning that a potential victim may be redirected to a malicious website. The following code was present in framework.php:

header('Location:'.substr($_SERVER['REQUEST_URI'],0,strpos($_SERVER['REQUEST_URI'], 'index.php')).'installation/index.php');

Abstract: The file framework.php passes unvalidated data to an HTTP redirect function on line 25. Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.
The request url argument can be controlled by a potential attacker implying that input validation is required here.

Path Manipulation

Error 1
As a third example, consider the following line of code in file.php(184):

@chmod($file, 0777);

The chmod command allows the attacker to change permissions of a file. Since the file argument is controlled by the attacker, the attacker may get access to or modify a file to his choice thus escalating privileges. (Erik: So in this case there was no validation of the file name at all, and there should have been? Maybe if the file is in a directory where the user is uploading files it is harmless to allow users to chmod them? )
Abstract: The file default.php mishandles confidential information on line 486, which can compromise user privacy and is often illegal.

The following code is present on line 486:

$result = @fwrite($fp, $data);

(Erik: how does this compromise user privacy? )

The report generated by Fortify indicates that many of the critical vulnerabilities are caused by the lack of (or improper) input validation. According to Fortify a password is stored inside the data, which is obviously undesired. (Erik: These warnings about passwords are actually a prominent source of false positives by Fortify. Btw, it has nothing to do with V5, I'd say. Also, it's not really to do with input validation, is it?

High priority issues

Command Injection

Error 1
The first vulnerability detected by Fortify was in restore.php:

$myInstance = unserialize($serialized_data);

Line 4792 in restore.php calls unserialize() with a command built from untrusted data. This call can cause the program to execute malicious commands on behalf of an attacker. The $serialized_data might contain tainted data. It's not clear from the report where $serialized_data originated but it should be properly sanitized before called.

Header Manipulation

Fortify lists the same error as we got in the critical issues which was listed under Open redirect. However, it is now listed under Header Manipulation, the following code was present in framework.php:

header('Location:'.substr($_SERVER['REQUEST_URI'],0,strpos($_SERVER['REQUEST_URI'], 'index.php')).'installation/index.php');

This is exact the same line as listed in the critical issue, which might be confusing and just creates extra work. However it now has the following description: Including unvalidated data in an HTTP response header can enable cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation or open redirect.

Header Manipulation: Cookies

Poisoning Cookies might form a risk if not validated correctly, we found the following error in tracks.raw.php:

setcookie(JApplication::getHash($this->context.'.basename'), $form['basename'], time() + 365 * 86400, $cookie_path, $cookie_domain);

Abstract: The method display() in tracks.raw.php includes unvalidated data in an HTTP cookie on line 94. This enables Cookie manipulation attacks and can lead to other HTTP Response header manipulation attacks like: cache-poisoning, cross-site scripting, cross-user defacement, page hijacking or open redirect. We need to investigate further if this is a real risk or just a false positive.

Medium priority issues

File Upload

The medium priority issues all consists of file upload vulnerabilties. We picked one example:

<input class="input_box" id="install_package" name="install_package" type="file" size="57" /> 

Fortify searches all the source code for the keyword type="file" in the <input> tags. Since the most devastating attacks often involve remote code execution Fortify gives an alert even though it seems like this is a feature of Joomla. The fact that the file in which the vulnerability is found is located inside a Joomla installer folder confirms the idea that it is a legitimate feature of Joomla. So this might be a false positive.

Low priority issues

Command Injection

We get the impression that Fortify searches for various function that bring a certain risk with them. The Command Injection vulnerabilities that we have found are all examples of this. The questions remains as to whether these vulnerabilities are a threat. For example, Fortify searches for

 system(), exec() and passthru() 

Cross-Site Request Forgery

Fortify gives a warning that the forms in Joomla need to have a user-specific secret in order to prevent an attacker from making unauthorized requests.

Hidden Field

Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will violate these assumptions. Fortify found 402 hidden fields, so Joomla might be vulnerable to attackers manipulating their contents. (Erik: But there are legitimate reasons to use hidden fields, so there might be - or maybe you even expect there to be - many false positives here)

Rats (Rough Auditing Tool for Security)

We run Rats on the Joomla 3.1.0 source code; it found 25 vulnerabilities:

• High [17]: fopen
• Medium [8]: [1] is_writeable, [1] is_file, [6] is_dir

The medium vulnerabilities are mainly TOCTOU (Time of Check, Time of Use) vulnerabilities. The high level vulnerabilities are triggered by functions that use input data from untrusted sources such as fopen. As the name suggests, Rats is a rough auditing tool which is only capable of finding 'rough' vulnerabilities within a programme; it scans for vulnerable functions. Nonetheless, Rats has found relevant errors concerning input validation (V5). Fopen does not check the input data; malicious data can be inserted.

We run Rats with the following command:

rats --resultsonly [dir]

The results are listed below: {{hilite|(Erik: Do any of them seem to be relevant for V5?)}

Joomla 3.1.0//administrator/components/com_joomlaupdate/helpers/download.php:47: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/helpers/download.php:56: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/helpers/download.php:87: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/helpers/download.php:301: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/helpers/download.php:311: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/models/default.php:356: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/models/default.php:482: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:1271: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:1540: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2333: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2409: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2968: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2970: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:3050: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:3983: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:3985: High: fopen

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:4028: High: fopen

Argument 1 to this function call should be checked to ensure that it does not

come from an untrusted source without first verifying that it contains nothing

dangerous.

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:1591: Medium: is_writeable

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

1592 (chmod)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2019: Medium: is_file

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

2015 (chmod), 2021 (chmod), 2025 (chmod)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2067: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

2067 (mkdir), 2072 (unlink), 2073 (mkdir), 2081 (chmod)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2444: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

2463 (mkdir), 2471 (chmod)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:2516: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

2518 (chmod), 2522 (chmod), 2524 (unlink)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:5699: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

2562 (rmdir)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:4335: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

4303 (opendir), 4337 (opendir)

Joomla 3.1.0//administrator/components/com_joomlaupdate/restore.php:5723: Medium: is_dir

A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is

the first line where a check has occured.

The following line(s) contain uses that may match up with this check:

5730 (unlink)