[product] (script.php) Remote File Include [exploit|vulnerability]

[This was originally published on the OSVDB blog.]

Somewhere out there is a point-and-click web application that allows neophyte “security researchers” (yes, that is a joke) to quickly whip up their very own Bugtraq or Full-Disclosure post. I’m sure others have noticed this as well? More and more of the disclosures have too much in common, and unfortunately for VDBs, more and more are completely bogus reports. I feel bad for the vendors as much as I feel for those of us trying to track vulnerabilities. Anyway, some of the many things these disclosures have in common:

– Title (example: EasyBannerFree (functions.php) Remote File Include Exploit)
– # Everything is commented as if this is supposed to be a script
– The remote file inclusion is http://shell.txt or SHELLURL.COM
– It has a single line of source code quoted to “validate” the finding (example: rrequire ( $path_to_script.”globals.inc.php”);
– May have 80 lines of perl code to exploit a single http:// line, because it looks cool
– Contains more greets/thanks than vulnerability information
– If their disclosure is proven false, they never seem to reply to explain themselves

Odds are strong they won’t include the vendor or give enough information to find it via extensive searching. Odds are good it will not contain the version supposedly affected and contain typos in the script or variable names. And worst of all, it is a glorified “grep and gripe” disclosure. Meaning, they grep out the ‘require’ line, don’t bother to check any other portion of the code, and assume it is vulnerable. Some will go so far as to say stuff like “ (tested on Version 1.13)” even though it is quickly proven false.

So, “security researchers” disclosing all these remote file inclusion bugs. Test your finds before you publish, no more grep and gripe crap please.

January Set As ‘Month Of Apple Bugs’

[This was originally published on the OSVDB blog.]

January Set As ‘Month Of Apple Bugs’

The “Month of Apple Bugs” project, which will be similar to November’s “Month of Kernel Bugs” campaign, will be hosted by the kernel bug poster who goes by the initials “LMH,” and his partner, Kevin Finisterre, a researcher who has posted numerous Mac vulnerabilities and analyses on his own site.

More interesting this time, Landon Fuller has begun using his own blog to release unofficial patches for the MOAB vulnerabilities as they are released.

These two weeks of Word flaws – can we survive?

[This was originally published on the OSVDB blog.]

Courtesy of Juha-Matti Laurio at the Securiteam Blogs:


Since 5th December we have seen three separate, serious vulnerabilities in Microsoft Word:

[Disclosed – original reference – CVE name
Affected products and product versions]

Tue 5th Dec – MS Security Advisory #929433 – CVE-2006-5994 and FAQ
Word 2003/2002/2000, Word 2004/v. X for Mac, Works 2006/2005/2004, Word Viewer 2003

Sat 9th Dec – MSRC Blog entry 10th Dec – CVE-2006-6456
Word 2003/2002/2000, Word Viewer 2003

Tue 12th Dec – Fuzzing list posting – CVE-2006-6561
Word 2003/2002/2000, Word 2004/v. X for Mac, Word Viewer 2003, OpenOffice.org 2/1.1.3, AbiWord 2.2

Of course, vulnerabilities in Word (and other MS Office components) are not new, but this recent wave demonstrate (yet again) just how bad the software industry can be and how security was never a consideration during the original design. Hopefully the recent buzz will finally make Microsoft spend serious time auditing the other big business applications like Visio and Project among others.

When reading various security resources, it constantly amuses me that they all seem to ignore the obvious conclusion and short sighted ‘solutions’ they recommend. “Don’t open [filetype] from untrusted people.” We’ve seen this in the past with ‘executables’ to help stop trojan attacks, ‘gif/jpg/bmp’ to stop various overflows and code execution situations in image processing software, ‘excel’ files after a small wave of vulnerabilities were found in MS Excel, and now ‘word’ documents. The people giving this advice are security professionals in many cases, and they all seem to forget that a fundamental component of security is trust. In short, quit specifying a given file format that is the craze of the day. “Don’t open ANY file from untrusted people.”