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: <200701090207.l09273QL015353@faron.mitre.org>
Date: Mon, 8 Jan 2007 21:07:03 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: jgraef@...rs.sourceforge.net
Cc: bugtraq@...urityfocus.com
Subject: Re: OpenPinboard <= Remote File Include


Remote file inclusion does not seem possible - the only relevant
code is this:

  require_once("languages/$language.php");

Since the "languages/" string will always appear first, you can't
inject an "http://" or similar to the front of the string, so remote
file inclusion is not possible.

OK, so we need to consider directory traversal sequences a la ".." for
local file inclusion.

It appears that directory traversal might be exploitable before
product installation is complete.

Before the require_once statement, we have:

  if (file_get_contents("locked")!="locked") header("location: install.php");
  require_once("config.php");

As has been observed by various people, merely printing a Location
header will not prevent execution of the rest of the application.  So,
the require_once() will always be executed.

In 2.0 and 2.0.1, config.php is empty - at least until the admin has
finished installation using install.php.

So, before installation is complete, $language (and other variables)
are not set to any values.  Assuming register_globals is enabled,
there is a small time window during which the attacker might insert
".." (and probably "%00"?) into the $language parameter to include
local files.

After the admin has properly run install.php, $language is inserted
into config.php, preventing this particular exploit.

Unfortunately, during the post-disclosure analysis of install.php, I
might have found a serious issue involving code execution but not RFI.
I will privately work with the developer to address the problem, then
follow up to the list.

- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ