httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@organic.com>
Subject Re: security hole. bluff?
Date Mon, 22 Apr 1996 20:12:19 GMT
On Mon, 22 Apr 1996, Ben Laurie wrote:
> I should add that the Apache Group's response was the correct one, whether the
> security hole really exists or not. It clearly did not damage the code, it
> clearly could possibly somehow cause a hole and in the absence of time for
> contemplation we fixed it. We might like to consider removing the fix if
> further analysis shows it is not a hole.

I have been thinking a little bit about this - any conformant HTML forms 
implementation will always encode characters like '\n' into their hex 
encoding (%0A?), and since the unsafe character check happens *before* 
that is actually expanded to '\n', then it shouldn't be a problem.  The 
problem arises if any application actually submits a '\n' in POST data
(since it couldn't do that in a GET form submission, '\n' isn't allowed 
in a URL).  And then, of course, the hole still needs to exist in CGI 
software to do so.  So, I can't think of a legitimate place where '\n' 
would actually be in that stream.  That said, reversing the patch we 
applied would not really improve functionality or spec compliance or 
anything.

	Brian	

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/


Mime
View raw message