SoftwareSecurity2014/Group 4/Code Scanning

V5 LEVEL 1B - INPUT VALIDATION VERIFICATION REQUIREMENTS ON MIBEW

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.

Tool : RATS (Rough Auditing Tool for Security)

We scanned mibew using the following command on RATS: rats --quiet --xml -w 3. It cost us 0.126819 second to scan the mibew project. The RATS result scanned 11704 lines of mibew project. The detailed result of the RATS scan can be seen on table below:

Threat Level	Number of Threats	What causes threats
High	2	fopen, mail
Medium	0	-
Low	37	is_dir, fixed size local buffer, fileperms, is_readable, is_file

RATS discovered low level of vulnerabilities caused by “fixed size local buffer” or “dirname” which is related to race condition. Furthermore, RATS also found the vulnerabilities of “fileperms”, “is_readable”, “is_dir”, and “is_file” which are related to potential TOCTOU (Time of Check, Time of Use) vulnerabilities. TOCTOU is also known as one of the common race condition problem. Race condition is the behaviour where the output is dependent on the sequence of other events. Therefore, race condition is not part of the Input Validation vulnerability in web application. In general, the race condition could cause some input validation problem if some data was changed in between the validation time and the used time. However, it was hardly happened in a PHP application. Even though it's happened, most likely it was caused by the bug inside the Apache, since Apache also using a C code in its API.

Tool : HP Fortify

We scanned mibew using Fortify Audit Workbench. Regarding to the results, it detects 3757 vulnerabilities. These problems can be categorized into low level (102), medium level (2862), high level (52) and critical level (741). The vulnerabilities results which can be used for Input Validation verification are Cross-Site Scripting (Persistent, Poor Validation, Reflected); Header Manipulation; Often Misused File Uploaded, Open Redirect, and Path Manipulation. Mibew uses “safe_htmlspecialchars” as a validation pattern for its input.

Comparison: RATS (Rough Auditing Tool for Security) vs Fortify Result Fortify and RATS can gives different type of vulnerabilities for the same line of code, as an example for the translate.php line 88. Fortify result in Critical level vulnerability which related to the “fopen” vulnerability as follow: “Attackers can control the filesystem path argument to fopen() at translate.php line 88, which allows them to access or modify otherwise protected files.” While RATS gives result for that line as Low level vulnerability which related to the “fixed size local buffer” or “dirname” vulnerability. Based on this result, Fortify result is more useful for the V5 requirements, because RATS result is mainly focused on the race condition vulnerability.

In addition, there is still a chance for a false positive result in Fortify. For instance, in “b.php” line 58, Fortify resulted in a usage of “fopen” which is categorized as a Critical level. However, when we analyze that usage, we conclude that this fopen did not actually has a vulnerability because of before hand validation controls. Therefore, it is still needed to analyze the code flow thoroughly before we conclude the code has a vulnerabilities.

Category	Source File	Lines	Sink	Verdict
Cross-Site Scripting: Persistent	notification.php	24, 32, 40, 48, 63	getlocal, sanitize_string	False Positive
		35, 51	safe_htmlspecialchars	False Positive
		57	prepare_html_message	False Positive
		62	$mibew_root	False Positive
	performance.php	27, 34, 45, 49, 54, 58, 63, 67, 72, 76, 81, 85, 90, 94	getlocal	False Positive
	permissions.php	27, 34	getlocal	False Positive
	resetpwd.php	33,37,40,55,60,68,76,88,94,98	getlocal	False Positive
	restore.php	33,37,40,52,57,64,76,82	getlocal	False Positive
	group.php	28, 31, 39, 51, 55, 60, 64, 69, 73, 78, 82, 87, 91	getlocal	False Positive
	groups.php	31, 41, 42, 52, 54, 56, 58, 76, 80, 82, 95, 106, 117	getlocal, $mibewroot, getlocalforJS	False Positive
	login.php	30, 37, 42, 49, 57, 69, 78	getlocal, $mibewroot, getlocalforJS	False Positive
	settings.php	27, 34, 45, 49, 54,58	getlocal	False Positive
	statistics.php	25,41,47,69,94	getlocal	False Positive
	themes.php	27,38,44,61,64	getlocal	False Positive
	update.php	145	echo "<threads revision=\"$revision\" time=\"" . time() . "000\">";	True Positive
	users.php	51,53,60...66,79,89,91 25,36,37,40	getlocal	False Positive
	ban.php	24,40	getlocal2	False Positive
Header Manipulation	operator.php	87, 100	header("Location: ...)	False Positive
	opgroups.php	71	header("Location: ...)	False Positive
	groupmembers.php	71	header("Location: ...)	False Positive
	group.php	100, 104	header("Location: ...)	False Positive
	login.php	44	header("Location: ...)	False Positive
	canned.php	113	header("Location: ...)	False Positive
Cross-Site Scripting: Poor Validation	performance.php	47, 56, 65, 74, 83, 92	form_value	False Positive
	permissions.php	39, 45, 49, 56	safe_htmlspecialchars	False Positive
	resetpwd.php	40	urlencode	False Positive
		49, 50	safe_htmlspecialchars	False Positive
	restore.php	66	form_value	False Positive
	group.php	44, 53, 62, 71, 80, 89, 96	form_value	False Positive
	groupmembers.php	27, 34, 39, 45, 50 ,51, 52, 58	safe_htmlspecialchars, getlocal	False Positive
	groups.php	71, 72, 76, 88, 89, 94	safe_htmlspecialchars	False Positive
	login.php	51, 75	safe_htmlspecialchars, form_value, getlocal	False Positive
	notification.php	35, 51, 57	safe_htmlspecialchars, prepare_html_message	False Positive
Path Manipulation	translate.php	24,35,60,74,81	echo, fopen	True Positive
	avatar.php	66, 68	unlink, move_uploaded_file	True Positive

From the table above, we might concluded that the warnings was caused by several functions. Those functions are getlocal(), safe_htmlspecialchars(), prepare_html_message(), sanitize_string(). When we checked into this functions manually, we found out that these function was doing the blacklisting validation. Therefore, we conclude that the fortify warnings regarding these functions was false positive.

During our analysis on level 2B, we found a false negative from the Fortify result. When we did the checking for the Fortify warning about the HTTP response header on operator.php line 87, which we found that the parameter already validated using intval, we decided to also check the line 86. That line was using the function create_operator function. We did analyze the create_operator more thoroughly and find that it using the deprecated PHP function which is mysql_real_escape_string(). The function mysql_real_escape_string() will sanitize the input from several of special character (\x00, \n, \r, \', ", \x1a). However, this function is still vulnerable against SQL injection because it doesn't include all the character needed for preventing from SQL injection. Moreover, all the SQL queries in mibew was not done under prepared statement. Without saying that by using prepared statement will guarantee the security against SQL injection, but without using it will open more possibilities to SQL injection.

In conclusion, RATS result also provided us with the Input Validation vulnerability. However, compared to Fortify result, it’s only resulted in limited type and amount of vulnerability. Most of the RATS result are also revealed on the Fortify scan result.