On Wednesday 25 April 2007 05:35, Vincent Archer wrote:
On Tue, 2007-04-24 at 20:03 +0300, ØØØ ØÙÙÙ ØØÙØ ØÙØÙ wrote:
This is a case of poor-programming, on the script coder's part, it is
not so
much a vunerability.
In that case, nobody's talking about vulnerabilities on this list, only
poor programming. :)
Vulnerabilities are results of poor programming.
The problem in here is that the programmer "assumes" that the variables
do have a proper value checking done prior to handling off to the script
engine. HTTP_METHOD is well defined. One would assume apache has
validated the method somehow.
If you properly code the scripts, Apache's acceptance of misc data in the
method field is not a vulnerability, it is a feature that could be used to
make that field extensible with minimal effort. i.e. a script could be
designed to send out data based on different methods not listed in the RFC.
Unfortunately, this assumption was flawed.
That variable only contains what it is sent by apache. it doesn't
parse it.
nor is it supposed to.
However, it (apache) should perform integrity checks, because it has the
capacity to do so.
True. but Apache should not facilitate lazy programming on script programmers
part, the more you baby sit people, the more they will rely on that
babysitting and not do it for themselves because they will inherently assume
that they have a 'safety net', thus if the script is run on a server without
that "safety net" THAT server gets labeled as "vunlnerable" when without that
script the server is not vulnerable.
What are we going to do next? get the HTTPD to valadate the URL-based queries
(i.e. "script.php?var=value") to prevent "unintended input"
(i.e. "viewfile.php?file=../../../file" )? This is a SCRIPT problem. not a
problem with the HTTPD.
This CAN be a vulnerability with individual scripts, however, it is
not a vuln
with PHP or Apache.
Not with PHP. But I would agree with the original programmer that apache
is in fault here. Apache should have done the expected work, and
validated that the request was standards-compliant. It didn't, and that
opens up a huge chasm in which plenty of problems, vulnerabilities and
others, may hide.
From RFC 2616 Section 5.1.1:
The list of methods allowed by a resource can be specified in an Allow header
field (section 14.7). The return code of the response always notifies the
client whether a method is currently allowed on a resource, since the set of
allowed methods can change dynamically.
--------
The standards don't say anything about a static list of methods being
required. so Apache is compliant there. It is a per-script problem for not
parsing the raw data provided to the script properly.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
