httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: security hole. bluff?
Date Mon, 22 Apr 1996 20:17:16 GMT
In reply to Brian Behlendorf who said
> 
> 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.

Me and Andrew discussed this in the pub Friday night and that was
basically our conclusion i.e. that earlier parts of the process would
have caught anything dangerous. I think this has hit Apache more
because of publicity about the original use of the code rather than the
way it's actually used in Apache. I guess the claims that this hole has
caused many sites to be compromised also refers to the code's original
use rather than any breaches down to it's use in Apache. I think Andy
actually tried to break in using this hole and found you couldn't.

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message