php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73805 Fix of CVE-2011-1398 creating other security issues
Submitted: 2016-12-23 04:39 UTC Modified: 2016-12-28 02:46 UTC
From: habte dot yibelo at gmail dot com Assigned:
Status: Open Package: HTTP related
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: habte dot yibelo at gmail dot com
New email:
PHP Version: OS:

 

 [2016-12-23 04:39 UTC] habte dot yibelo at gmail dot com
Description:
------------
Hello,

In CVE-2011-1398, and later on CVE-2012-4388 there is an attempt to stop CRLF injections in sapi_header_op function in main/SAPI.c functions. however the fix created other vulnerabilities on the way.

so for instance, assume an application vulnerable for CRLF injection:

header("Location:".$_GET['to']);

Sending ?to=x%0ANew:header after the fix will result in PHP returning:

"Multiple headers detected." but what also happens is, the 302/301 redirection doesn't happen. later we realized PHP just drops the header if it sees the character instead of rendering it either encoded or alteast echo the first header. 

This creates other vulnerabilites when user-input is rendered back to browser-security headers, sometimes this creates even dangerous bugs depending on what kind of header it gets refelected back to. Example cases are presended in the next section.


Test script:
---------------
Example, assume an application doing Content-Disposition while delivering sensitive files (svg, html, php):

<?php
$file = $_GET['file'];  
header('Content-Disposition: attachment; filename="'.$file.'"');
?>
<img src=x onerror=alert(1)>

Normally a download would happen, with the filename, but in this case, the header gets dropped so the browser have no option but to render the content. thus creating stored-XSS in this case. I have found terrible cases on applications where this has led to a code execution and finally decided to report it as it seem to affect a lot of developers not knowing about it.

Obviously this is just an example but this could affect a lot of cases, recently I have found it affecting a PKP (Public-Key-Pinning) header making MiTM possible by dropping the header.



Expected result:
----------------
Expected result should be the header getting returned, encoded or atleast is semi-half that isn't user controlled. 

Actual result:
--------------
header gets dropped.

Thanks,

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-27 06:57 UTC] stas@php.net
-Type: Security +Type: Bug
 [2016-12-27 06:57 UTC] stas@php.net
Not a security issue since it requires application code to be already vulnerable.
 [2016-12-28 02:46 UTC] habte dot yibelo at gmail dot com
"Not a security issue since it requires application code to be already vulnerable."

> vulnerable to what? there isn't any security vulnerability here. it is creating one. returning user-provided info in header is considered safe after the fixes so there should be no excuse. but these vulnerabilities have a potential to cause more serious issues. revisit please.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Dec 05 17:01:24 2019 UTC