init

Author: bigshaq

0x01 [bug #79383] 777 Permissions/README.md

@@ -0,0 +1,84 @@
+
+# Digging into ``ZipArchive::extractTo()``
+In this post, I will show something that I found in PHP’s source code and affects all versions of PHP. 
+During my PHP Internals research, I reviewed the code of ``ZipArchive::extractTo()``, which is responsible for extracting a zip file(opened using ``ZipArchive::open()``) and found an interesting thing.
+
+## Description
+Let’s take this example PHP script:
+```php
+<?php
+$zip = new ZipArchive;
+if ($zip->open('test.zip') === TRUE) {
+    $zip->extractTo('/tmp/phpfuzz/outdir/');
+    $zip->close();
+    echo 'ok';
+} else {
+    echo 'failed';
+}
+?>
+```
+This script will extract the contents of ``test.zip`` into a directory called “outdir”.
+
+The issue here is that, by default, PHP will create ``outdir/*`` to be with hard-coded 777 permissions:
+
+https://github.com/php/php-src/blob/5fa17fbf94fa95705922313ac0d19e38ddabbad9/ext/zip/php_zip.c#L2781
+
+![screenshot1](./images/1.png)
+
+This is the directory tree after un-zipping the file:
+
+![screenshot1](./images/2.png)
+
+Everything is readable to the public usergroup. And it's recursive (sub-directories are affected as well).
+
+>**Note**: In other systems it can be a "full 777 permission"(like ``rwxrwxrwx``) but on my system it's not due to my *uname* setting (I kept the default setting so you can see a real-life scenario).
+
+## Impact / Threat
+
+This affects mostly applications on shared hosting environments.
+
+On a shared hosting environment, all websites/applications are stored on the same server and each website has its own Linux user & group (this is not correct for all shared hosting providers, but this is the common design that most of the shared-hosting providers prefer to stick with). 
+ 
+ ![screenshot1](./images/3.png)
+
+Making the extracted files & directories readable by the “public” usergroup (in the screenshot above, called “Other”) allows other applications hosted on the same Linux server to read the extracted zip content. This can be easily done using symlinking technique (more about symlinks: https://www.cybrary.it/blog/2019/07/symlink-attacks/)
+
+**Example scenario**:
+1.	A PHP application has a feature that's triggering a call to the ``extractTo()`` method. This can happen during plugin installation or any other reason for unpacking zip files.
+
+The files will be extracted to: ``/home/victim/public_html/extracted_here/``
+
+2.	All of the extracted files (which might contain sensitive info such as configurations) are readable to all users on the server. All of the directories are readable too and can be listed by a malicious user on the server.
+
+3.	In order to disclose those extracted files, the attacker buys a basic hosting plan on the same shared-hosting of the target application (or alternatively, take over another vulnerable website that is stored there)
+
+The attacker’s home directory: ``/home/appsec/public_html/``
+
+4.	When the attacker will try to access the victim’s files, he will try the following: 
+```
+appsec@server:$ ls /home/victim/public_html/
+```
+This attempt will (most likely) not work because the server is configured properly and the only bypass will be at the OS level.
+
+**However**, if there's a directory/file which is created by ``ZipArchive::extractTo``, it will be readable for everyone on the server.
+
+The attacker runs again the command, but this time he runs the command on a directory created by the ``extractTo`` method:
+```
+ appsec@server:$ ls /home/victim/public_html/extracted_here/
+```
+And everything will be listed. The attacker can also run ``cat`` on the files and expose the contents of the files.
+
+A more elegant (and common) way to traverse between the extracted directories that are exposed will be by using a symlink technique.
+
+## Reporting to PHP
+I reported this to PHP (bug *#79383* in PHP’s bug tracker) and they said that this is an expected behavior. However, they found out that it is **not documented anywhere.**
+
+![screenshot1](./images/4.png)
+
+As such, they agreed to add a warning (see below) saying that you should use ``umask()`` to prevent from any unnecessary info leakage:
+Commit: https://github.com/php/doc-en/commit/c870cfa314d880326cf30cd34b560c94f9526954
+
+
+![screenshot1](./images/5.png)
+
+

0x01 [bug #79383] 777 Permissions/images/1.png

@@ -0,0 +1,74 @@
+## CVE-2020-7066 – Null byte Poisoning in PHP7
+
+When talking about Null-byte Poisoning in PHP, the most common scenario is file upload / file extension validation bypass (*CVE-2006-7243* and *CVE-2015-2348*). Those kinds of attacks are very rare because we left them in 2006-2015. However, there are other functions which are vulnerable to nullbyte poisoning and didn’t get enough attention / write-ups. The bug that I present here is relevant for all PHP versions as of March 2020.
+
+Let's take this example: The PHP code allows sending requests only to ``.example.com`` subdomains.
+```php
+<?php
+$url = "http://localhost\0.example.com"; // payload
+
+$host = parse_url($url, PHP_URL_HOST);
+if (substr($host, -12) !== '.example.com') { // pseudo-validation
+    die('Not allowed');
+}
+$headers = get_headers($url);
+print_r($headers);
+?>
+
+```
+
+Output:
+The request will be sent to http://localhost even though the validation in the ``if`` statement is correct.
+```
+Array
+(
+    [0] => HTTP/1.1 200 OK
+    [1] => Date: Sun, 22 Mar 2020 21:19:03 GMT
+    [2] => Server: Apache/2.4.7 (Unix)
+    [3] => Spoofed-Info: isHere
+    [4] => Connection: close
+    [5] => Content-Type: text/html
+)
+```
+
+## Root cause
+This is the source code of ``get_headers()`` :
+
+![screenshot1](./vuln_1.png)
+
+At line 672 the parameter is passed from the "php layer"(Zend engine) to the ``char *url`` pointer, and the length of the string is passed to ``size_t url_len`` 
+
+At this point, the string length is **still** 29 bytes long(``http://localhost<NULL>.example.com`` and not ``http://localhost``)
+
+If we debug this and set a breakpoint on ``zif_get_headers()`` we can see that we weren't able to fool Zend Engine. It knows the real length of the string, even with the null-byte injected in it:
+```
+(gdb) p url_len
+$2 = 29
+(gdb) x/29bc url
+0xb787c100:	104 'h'	116 't'	116 't'	112 'p'	58 ':'	47 '/'	47 '/'	108 'l'
+0xb787c108:	111 'o'	99 'c'	97 'a'	108 'l'	104 'h'	111 'o'	115 's'	116 't'
+0xb787c110:	0 '\000'	46 '.'	101 'e'	120 'x'	97 'a'	109 'm'	112 'p'	108 'l'
+0xb787c118:	101 'e'	46 '.'	99 'c'	111 'o'	109 'm'
+```
+
+So, if PHP knows that the length of the string is 29 and not 16, how does this magic work? 
+
+If you look closely, at line 680 (in screenshot above) the ``url`` pointer is passed **but  ``url_len`` is not**. 
+When the execution reaches to ``php_stream_open_wrapper_ex()`` it doesn't know the length of the string so like any other typical C program, it will assume that the string ends in the first occurrence of a null byte. 
+
+## The Fix
+The git commit: 
+https://github.com/php/php-src/commit/2bc92a0cf79e52e2096e45987468740d5bc748ed
+![screenshot1](./fix.png)
+
+The PHP Development Team updated the parameter type to be a ``Z_PARAM_PATH`` (a macro that throws an error if there's a null-byte in the parameter) and not a ``Z_PARAM_STRING`` (which can represent strings with a null-byte in it)
+
+Output:
+```
+PHP Warning:  get_headers() expects parameter 1 to be a valid path, string given in ...
+```
+
+
+>**Note:** The bug was originally reported by ``64796c6e69 at gmail dot com`` (here: https://bugs.php.net/bug.php?id=79329). I wrote this to share a more in-depth analysis.
+
+

0x01 [bug #79383] 777 Permissions/images/2.png

@@ -0,0 +1,147 @@
+# Out-of-Bounds read in ``urldecode()``
+
+## Details
+* **Description**: "*In PHP versions 7.2.x below 7.2.30, 7.3.x below 7.3.17 and 7.4.x below 7.4.5, if PHP is compiled with EBCDIC support, ``urldecode()`` function can be made to access locations past the allocated memory, due to erroneously using signed numbers as array indexes.*" - In other words, if you type a negative hex value in a system with EBCDIC encoding enabled, you'll be able to leak memory ✨
+
+* **CVSS3 Score**: 7.5 high
+
+## Impact / Threat
+This bug requires the vulnerable server to enable EBCDIC encoding, so it mainly affects Mainframe systems(yuck!) **and** possibly some flavors of IBM Cloud Instances which runs PHP (IBM created this encoding so they have support in their cloud environment environment as well. It was found to be enabled in cloud "flavors" such as *Linux z/OS*. References: [[#1]](https://cloud.ibm.com/docs/runtimes/php?topic=PHP-getting_started), [[#2]](https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zappldev/zappldev_14.htm), [[#3]](https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gxla100/encodesupport.htm)). 
+ 
+
+## The bug / Exploitation
+
+This is the source code of ``urldecode()``:
+
+[ext/standard/url.c](http://git.php.net/?p=php-src.git;a=blob;f=ext/standard/url.c;h=fe6d7f9de1d69eaafd577518d92d899feb7145b0;hb=fe6d7f9de1d69eaafd577518d92d899feb7145b0#l548) @ line 548
+
+```c
+/* {{{ php_url_decode
+ */
+PHPAPI size_t php_url_decode(char *str, size_t len)
+{
+	char *dest = str;
+	char *data = str;
+
+	while (len--) {
+		if (*data == '+') {
+			*dest = ' ';
+		}
+		else if (*data == '%' && len >= 2 && isxdigit((int) *(data + 1))
+				 && isxdigit((int) *(data + 2))) {
+#ifndef CHARSET_EBCDIC
+			*dest = (char) php_htoi(data + 1);
+#else
+			*dest = os_toebcdic[(char) php_htoi(data + 1)];
+#endif
+			data += 2;
+			len -= 2;
+		} else {
+			*dest = *data;
+		}
+		data++;
+		dest++;
+	}
+	*dest = '\0';
+	return dest - str;
+}
+
+```
+
+If  ``CHARSET_EBCDIC`` is defined (usually, on systems with EBCDIC encoding support), an Out-of-Bounds Read can occur.
+
+Let's focus on the relevant parts of the function:
+```c
+PHPAPI size_t php_url_decode(char *str, size_t len)
+{
+	char *dest = str;
+	char *data = str;
+/*...more code...*/
+
+#ifndef CHARSET_EBCDIC
+			*dest = (char) php_htoi(data + 1);
+#else
+			*dest = os_toebcdic[(char) php_htoi(data + 1)]; // <--- oob read here
+#endif
+
+/* ... more code ... */
+```
+* ``os_toebcdic[256]`` is an array(or a map, i assume) used for decoding purposes. 
+* To convert the string input into hex values, PHP uses ``php_htoi()`` and then convert the result into a signed byte(char).
+* This signed number is then provided as an index to the ``os_toebcdic[]`` array. 
+* There will be no OOB Read after the buffer because the max value of a byte is 0xff (==256), which is the same size as the ``os_toebcdic[]`` 
+* However, the casting (in the second bullet) is done to a ``char`` and not an ``unsigned char``, which means that we can insert **negative hex values** to leak values that are found in the memory **BEFORE** our buffer. 
+
+
+
+
+payload:
+```php
+<?
+urldecode('%xfd'); //0xfd == -3, could be 0x80 for bigger OOB (which is -128 in dec, this is the minimum value of a signed byte. b10000000) 
+?>
+```
+
+in gdb:
+
+```
+gdb-peda$ call php_htoi(data+1)
+$42 = 0xfd
+
+gdb-peda$ p/d (char)$42
+$43 = -3
+```
+The array index is negative an memory will be leaked via the returned value of PHP's ``urldecode()`` 
+
+## Understanding the Concept 
+
+Let's take the following example program:
+```c
+#include<stdio.h>
+
+int main()
+{
+        char text[255] = "ABCD";
+        char buf[] = "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ"; // not used in the program
+
+        char c = 0xfc;  // signed char, can contain negative values (from -128 to 255)
+
+        printf("%x", text[c]); // text[-3]
+        return 0;
+}
+```
+
+We are using ``c`` as an index specifier to ``text`` and print the value in hex.
+
+The expected output will be a character from the ``text[]`` array, maybe A(``0x41``) or B(``0x42``), or maybe C(``0x43``), etc. Even if the attacker will manage to read **after** ``D``, he will not be able to read the contents of what is after ``text[255]`` in memory (because the maximum size of ``char c`` is 255). So what do we do? insert a negative value :D
+
+The actual output is: ``0x51``, which is Q, and belongs to anohter variable in the program (``buf``).
+It happens when an array index specifier is set to a negative value. In our case, ``c`` was set to ``0xfc`` (which is ``-3`` in dec)
+
+In the following hexdump, you can see that ``buf`` is found right before our ``text[]`` array in the memory:
+```
+gdb-peda$ hexdump &buf
+
++0000 0xbffff4c5  51 51 51 51  51 51 51 51  51 51 51 51  51 51 51 51  │QQQQ│QQQQ│QQQQ│QQQQ│
+...
++0020 0xbffff4e5  51 51 51 51  51 51 51 51  51 51 00 41  42 43 44 00  │QQQQ│QQQQ│QQ.A│BCD.│
++0030 0xbffff4f5  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  │....│....│....│....│
+pwndbg>
++0040 0xbffff505  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  │....│....│....│....│
+...
+```
+
+Hence, we jumped "backwards" when we inserted negative values in the array index specifier.
+
+## The Fix
+
+The PHP Development team turned the array index specifier to be an ``unsigned char`` to avoid negative values in array index specifiers. 
+
+Same issue was found in ``php_raw_url_decode``
+
+The commit: http://git.php.net/?p=php-src.git;a=blobdiff;f=ext/standard/url.c;h=1dd073e2bb423652821f351135b9582d76e175d5;hp=fe6d7f9de1d69eaafd577518d92d899feb7145b0;hb=9d6bf8221b05f86ce5875832f0f646c4c1f218be;hpb=14fcc813948254b84f382ff537247d8a7e5e0e62
+
+![screenshot](./res/fix.png)
+
+
+>Original report #79465: https://bugs.php.net/bug.php?id=79465&edit=2

0x01 [bug #79383] 777 Permissions/images/3.png

@@ -0,0 +1,17 @@
+## About MapServer
+
+https://github.com/mapserver/mapserver
+
+>MapServer is a system for developing web-based GIS applications. The basic system consists of a CGI program that can be configured to respond to a variety of spatial requests like making maps, scalebars, and point, area and feature queries.
+
+
+>MapServer was originally written by Stephen Lime. Major funding for development of MapServer has been provided by NASA through cooperative argreements with the University of Minnesota, Department of Forest Resources.
+PHP/MapScript developed by DM Solutions Group.
+
+
+## PHP/MapScript Vulnerabillities :bug:
+As part of my PHP Internals research, I also learned about PHP **extensions**. I found a buffer overflow & format string vulnerabillities in a PHP extension called MapScript, which is part of the MapServer app. 
+
+In this directory, you'll find two of the reports I sent privately to MapServer development team with PoCs.
+
+All of the findings were fixed and the project maintainers allowed me to disclose those reports after I sent a responsible, full disclosure request ( thanks Steve & Jeff :D )