full-disclosure - Re: Apache Illegal Request Handling Possible XSS Vulnerability

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <462DE60C.2000402@s0ftpj.org>
Date: Tue, 24 Apr 2007 13:12:12 +0200
From: KJKHyperion <hackbunny@...tpj.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Illegal Request Handling Possible XSS
 Vulnerability

Michal Majchrowicz wrote:
> In this case I agree this is a solution. If Apache wouldn't accept any 'separators' then XSS (and other stuff) wouldn't be possible at all. Is there anywhere described which chars can be used in protocol "field"?
There is no "flaw". You clearly have never written a HTTP request 
parser: validation is stupid, validation is boring, validation is 
expensive, the grammar in the RFC is little more than wishful thinking, 
it was clearly designed by UNIX sysadmins/Perl coders and it cannot be 
implemented in a single pass of lex/yacc unless an intestinal pattern of 
nested states is used. HTTP met real world and the lulz just came to be, 
and have never stopped since

I don't see how any of this is news, or relevant, or insightful, but 
then again I Do Not Get Computer Security (TM). Ladies and gents, other 
interesting spec violations in Apache's request parser, from my 
personal, occasional experience of reluctant HTTP request parser writer 
("know your enemy", in more ways than one):
 * Any number of empty lines before the request line is legal. This 
simplifies handling of multiple requests on the same connection
 * Spaces before and after the colon in header lines are stripped; maybe 
before header names as well, don't remember; once you implement a 
skip_whitespace(), you have to try very hard not to use it everywhere
 * Multi-line continuation works not only for header values, but names 
as well; one less parser state, yay!
 * Valid character ranges are not enforced, Apache only cares about 
separators. Seriously, who the hell cares. Data is code and code is 
data, you are supposed to encode data wherever it might risk becoming code

They don't even look that threatening or interesting to me, but as I 
said IDNGCS (TM), and I cannot seriously accept, on a purely 
intellectual level, how computer security is so much more about drama 
than technology. I understand my explainations must feel at least as 
alien to PHP developers within earshot; so for all I care, just 
implement mod_security or whatever your favorite placebo du jour is, and 
stop crying for mommy to strip the backslashes from your soup

PS. And FUCK stop producing HTML output with echo/print/printf! XSS 
vulnerabilities are caused by UNESCAPED OUTPUT, not by unfiltered input. 
By producing HTML/SQL/filenames/etc. you are for all intents and 
purposes feeding code into a compiler, which for all intents and 
purposes is the SAME thing as EXECUTING code (you DID take that Computer 
Science Fundamentals course, did you?). I'm a Windows kernel-mode C 
developer and *I* know that. So stop stripping my backslashes, dammit!

PPS. bonus quotable that didn't make the final cut: "You are the poison 
apple that torments Turing's immortal soul"

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/