php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76519 include function access file written after question mark (?)
Submitted: 2018-06-22 10:06 UTC Modified: 2018-06-22 17:26 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: ziyahan at netsparker dot com Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 7.0.30 OS: Ubuntu
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ziyahan at netsparker dot com
New email:
PHP Version: OS:

 

 [2018-06-22 10:06 UTC] ziyahan at netsparker dot com 
Description:
------------
a few days ago, a bug disclosure has been published:
https://mp.weixin.qq.com/s?__biz=MzIzMTc1MjExOQ==&mid=2247485036&idx=1&sn=8e9647906c5d94f72564dec5bc51a2ab&chksm=e89e2eb4dfe9a7a28bff2efebb5b2723782dab660acff074c3f18c9e7dca924abdf3da618fb4&mpshare=1&scene=1&srcid=0621gAv1FMtrgoahD01psMZr&pass_ticket=LqhRfckPxAVG2dF%2FjxV%2F9%2FcEb5pShRgewJe%2FttJn2gIlIyGF%2FbsgGmzcbsV%2BLmMK#rd


In disclosure, researcher use question mark (?) to bypass validity mechanism of phpmyadmin, however this trick can be used also in pure PHP script. 

I really don't understand how php interpreter evaluates question mark that given as param to include function.

I have a code like below:

<?php
$page = $_REQUEST["target"];
if(strpos($page,"ziyahan.txt")===0) {
include $page;
}

?>

It does not seem bypassable first, however I realize that a weird payload can bypass this

?target=ziyahan.txt%3f/../../../../../../../../etc/passwd

I cannot understand how the payload has an affect there?

It seems a bug.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-06-22 10:27 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2018-06-22 10:27 UTC] cmb@php.net 
This does not look like a bug at all.  You are checking if $page
*starts* with "ziyahan.txt", and it does.  This is certainly
insufficient to validate a user supplied filename which you intend
to pass to include.

A properly configured open_basedir setting should prevent the
inclusion of etc/passwd, though.
 [2018-06-22 10:28 UTC] requinix@php.net
-Assigned To: cmb +Assigned To:
 [2018-06-22 10:28 UTC] requinix@php.net 
That is a simple path traversal attack. https://www.google.com/search?q=path+traversal+attack

The %3f and %253f is used to trick phpMyAdmin's checkPageValidity() into allowing the path. Why it even allows for anything other than a strict whitelist, let alone for question marks in the *filename*, I don't know...

The question mark is not required for your proof of concept.
?target=ziyahan.txt/../../../../../../../../etc/passwd
 [2018-06-22 11:41 UTC] ziyahan at netsparker dot com 
Hi again,

There is a wrong assumption here.

If OS would be Windows, you're right, payload can be considered OK.

It is because in Windows, you will be able to access test/../../../file.txt, even if the directory test does not exist

However, the OS that I worked on is Ubuntu.

Yes, question mark is not mandatory. 

http://VULNERABLE_HOST/test/lfi.php?target=wrong.php../../../../../../../etc/passwd

However, the file, wrong.php, does not exist actually:) 

How can I access the file /etc/Password by using the payload above?

It seems weird, a bug.

IF you don't think so, please explain how it can be possible?
 [2018-06-22 11:52 UTC] ziyahan at netsparker dot com 
BTW, I forgot to say. For the case below:

http://VULNERABLE_HOST/test/file.php?target=file.txt../../../../../../../etc/passwd

I can reach /etc/passwd either way, existence of file.txt does not matter!
 [2018-06-22 11:55 UTC] spam2 at rhsoft dot net 
please inform yourself about path traversal attacks

it's in doubt the underlying operating system which you can blame but to be honest: if you accept ../../ without test realpath() at your own you have nobody to blame but yourself
 [2018-06-22 12:05 UTC] ziyahan at netsparker dot com 
Are you serious?

Do I look a one discuss here LFI?

I am only trying to understand how the scenario below is possible:

<?php
include("wrong.php../../../../../../../etc/passwd");
?>

How can it return /etc/passwd

In bash, you can try this command ie, cat wrong.php../../../../../etc/passwd

Another imporant thing is that,

"require" function does not evaluate the same payload in a same way.

Could you please investigate the issue instead of judging me.
 [2018-06-22 14:10 UTC] requinix@php.net 
Google, ziyahan. https://www.google.com/search?q=path+traversal+attack

PHP is not examining each part of the path. It shouldn't need to. /x/../foo should always end up at /foo because that's how paths work.
realpath() is the way to examine each part. realpath(/file/../foo) will fail.

And yes, Linux does not allow /file/../foo. But Windows does.
 [2018-06-22 17:26 UTC] ajf@php.net 
I don't think the dismissiveness of each other's positions here is helpful.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 07:00:02 2025 UTC