Sec Bug->Doc #74634 [Opn->Csd]: read_exif_data() documented as not taking URLs but allows URLs

From: Date: Tue, 22 Aug 2017 17:12:27 +0000
Subject: Sec Bug->Doc #74634 [Opn->Csd]: read_exif_data() documented as not taking URLs but allows URLs
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-14913@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74634&edit=1 ID: 74634 Updated by: kalle@php.net Reported by: rskansing at gmail dot com Summary: read_exif_data() documented as not taking URLs but allows URLs -Status: Open +Status: Closed -Type: Security +Type: Documentation Problem Package: Documentation problem Operating System: Linux PHP Version: 7.1.5 -Assigned To: +Assigned To: cmb Block user comment: N Private report: Y New Comment: It was me who was not entirely good at documenting this behavior I implemented in 7.2, I blame my long time absence from working with the docs. The exif extension supports streams like other functions that support streams in PHP do, in the same way. Any value passed should always be validated like anything else :) Thanks Christoph for fixing this, didn't see it myself as it was wrongly labeled as a security issue. Previous Comments: ------------------------------------------------------------------------ [2017-08-22 16:45:34] cmb@php.net FTR: most functions support general stream wrappers if a filename is expected, and I assume that is not explicitly documented for many of those. I have documented that for this particular function in <http://svn.php.net/viewvc?view=revision&revision=342914>, but not for others. ------------------------------------------------------------------------ [2017-07-30 11:58:58] rskansing at gmail dot com Any update on this issue? Seems straight forward to fix the docs, as it seems to be consistent behavior across the similar methods as mentioned. But will it just be fixed silently? ------------------------------------------------------------------------ [2017-06-19 21:37:05] stas@php.net I'm not sure why this specific function would not support streams where all others, like exif_imagetype or getimagesize, do. ------------------------------------------------------------------------ [2017-06-08 10:44:11] leigh@php.net The documentation (http://php.net/exif_read_data) specifically states: filename The name of the image file being read. This cannot be an URL. Looking at the history of exif.c it seems that exif_read_data has always (going back 15+ years) called exif_read_file, and exif_read_file has always used php_stream_open_wrapper So which is correct, the documentation or the current behaviour? ------------------------------------------------------------------------ [2017-05-22 23:55:03] rskansing at gmail dot com Description: ------------ # Description exif_read_date doc page found at http://php.net/manual/en/function.exif-read-data.php says the filename parameter can not be a URL. There is no mention of ability to use wrappers. This expectation that a URL can not be used leads to a potential SSRF and probably other vectors. # Fix Include information about wrappers supported in exif_* docs. Test script: --------------- <?php read_exif_data('https://admin:admin@192.168.0.1:12345'); // $_POST['filename']); Expected result: ---------------- PHP Warning: exif_read_data(): Unable to open file Actual result: -------------- SSRF served inside the network. # nc -l -p 12345 GET / HTTP/1.0 Authorization: Basic YWRtaW46YWRtaW4= Host: 127.0.0.1:12345 Connection: close ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74634&edit=1

« previous php.doc.bugs (#14913) next »