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>] [day] [month] [year] [list]
Message-Id: <200702130139.l1D1dAH0021573@faron.mitre.org>
Date: Mon, 12 Feb 2007 20:39:10 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com, ge@...uxbox.org
Subject: Re: Web Server Botnets and Server Farms as Attack Platforms


Interesting paper, Gadi.

Some thoughts:

1) It seems obvious that RFI is equivalent to remote code execution,
   but it's worth repeating.

2) A PHP exploit is much easier to write than a shellcode exploit.
   Plus, with the file inclusion, the payload is not limited in size,
   and you have a lot more reliability because you don't have to worry
   about platform variations.  Also, a fairly unskilled attacker can
   simply plug URLs into some parameters to find an RFI issue in a
   custom application.

3) The fact that you're seeing a lot of live attacks shows that,
   despite register_globals being disabled by default in PHP for a few
   years now, it's frequently enabled.  And even if it's disabled,
   some developers will implement their own version of
   register_globals by using dangerous constructs such as eval(),
   extract(), and $$varname (the latter being what I call dynamic
   variable evaluation).  Since these constructs can be equivalent to
   register_globals, they can be as dangerous.

4) Besides register_globals, other bugs/features in the PHP
   interpreter probably contribute to the high numbers of PHP
   application vulnerabilities.  Stefan Esser's work in this area is
   extensive.  The GLOBALS variable overwrite, and overwrite issues
   for other superglobals, will allow an attacker to control critical
   variables that the programmer would reasonably assume are safe.
   The unset() and XSS-in-error-messages bugs have been fixed, but how
   many servers still run vulnerable PHP versions?  PHP 5 still
   supports some remote behaviors even when allow_fopen_url is
   disabled.

5) RFI's success in compromising web servers is probably one reason
   why we see so many RFI vulnerabilities being disclosed (along with
   other factors like ease of discovery and prevalence of PHP
   applications).


- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ