Category Archives: Vulnerability Disclosure

[update] Month of PHP Bugs

I previously blogged about the Month of PHP Bugs [MOPB], an effort lead by Stefan Esser and the Hardened PHP Project to raise awareness about vulnerabilities in the PHP language. The month has come and passed and of course I have to wonder about a few things.

1. The project ended up releasing 45 vulnerabilities over 31 days, many of them remotely exploitable. For anyone that was under the delusion that PHP was “pretty secure”, think again. Not only were some remote, many were methods for bypassing the native protection methods PHP offers like open_basedir or issues with various functions designed to filter bad input.

2. These “Month of X Bugs” always get a press blitz before it happens, but we rarely see the same news outlets cover the same thing a month later. It’s nice to see the results of the project, the number and type of vulnerabilities as well as any insights (see comments on previous blog post) the developers had.

3. The PHP project thankfully responded to many of these vulnerabilities already. PHP 5.2.1 and 4.4.5 fix a lot of security issues. Oh wait, that was released two weeks before the MOPB. Where is the next big release that fixes the unpatched issues?

All in all, a very impressive effort. Esser and the Hardened PHP Project have certainly raised the bar for the “Month of X Bugs” projects.

How Apple Orchestrated Web Attack on Researchers

How Apple orchestrated web attack on researchers
http://blogs.techrepublic.com.com/Ou/?p=451
http://blogs.zdnet.com/Ou/?p=451

Last summer when I wrote “Vicious orchestrated assault on MacBook wireless researchers”, it set off a long chain of heated debated and blogs. I had hoped to release the information on who orchestrated the vicious assault but threats of lawsuits and a spineless company that refused to defend itself meant I couldn’t disclose the details. Well a lot has changed since then and researcher David Maynor is no longer working for SecureWorks and he’s finally given me permission to publish the details.

[..]

Apple is a mega corporation that nearly smashed the reputation of two individuals with bogus claims of fraud. It didn’t matter they weren’t the one’s pulling the trigger because they were pulling all the strings. David Chartier should be ashamed of himself and his blog. Jim Dalrymple of Macworld and his colleagues that jumped on the bandwagon should be ashamed of their reporting. Frank Hayes was the only one of Dalrymple’s colleagues that had the decency and honor to apologize. Most of all, shame on Apple.

Month of MySpace Bugs (MOMSB)

Yes, the trend continues and gets more .. odd.

The Washington Post decided to cover this story giving it more attention than it probably deserves. From the home page of the effort:

The purpose of the exercise is not so much to expose Myspace as a hive of spam and villainy (since everyone knows that already), but to highlight the monoculture-style danger of extremely popular websites populated by users of various levels of sophistication. We could have just as easily gone after Google or Yahoo or MSN or ZDNet or whatever. Myspace is just more fun, and is becoming notoriously dickish about responding to security issues.

I’m not exactly sure how MySpace deserves a “monoculture-style” designation since it is a single social web site and the vulnerabilities (presumably) aren’t specific to one web browser or operating system.

Month of PHP Bugs

Hell hath no fury like a PHP developer scorned…

http://blog.php-security.org/archives/46-Month-of-PHP-bugs.html

During the last months there have been the Month of the Browser bugs and the Month of the Kernel bugs projects that tried to raise awareness for security vulnerabilities in browsers and kernels.

After thinking a bit about this I started to wonder if I should not start a Month of PHP bugs somewhen in the first half of 2007. At the PHP conference it was once again claimed that it is not PHP that is insecure but the applications written by novice programmers. While it is true that many PHP applications are written by people with no clue about security it is absolutely not true that PHP is a secure programming language.

I think it is necessary to make ALL people aware of this. The plan is therefore to choose one of the 31 day months after January and release everyday a vulnerability in PHP itself. I would like to hear comments from the PHP community about this plan. (Be warned that anonymous rants will be deleted)

To check out the bugs, visit www.php-security.org/. I will also be adding comments to this entry pointing out some of the interesting commentary and underlying message behind this effort.

The Perfect Patch Storm

Steven Christey of CVE recently commented on the fact that Microsoft, Adobe, Cisco, Sun and HP all released multi-issue advisories on the same day (Feb 13). My first reaction was to come up with an amusing graphic depicting this perfect storm. Due to not having any graphic editing skills and too much cynicism, I now wonder if these are the same vendors that continually bitch about irresponsible disclosure and it “hurting their customers”?

These same customers are now being subjected to patches for at least five major vendors on the same day. In some IT shops, this is devastating and difficult to manage and recover from. If a single patch has problems it forces the entire upgrade schedule to come to a halt until the problem can be resolved. If these vendors cared for their customers like they pretend to when someone releases a critical issue w/o vendor coordination, then they would consider staggering the patches to help alleviate the burden it causes on their beloved customers.

reply: MJR: The Vulnerability Disclosure Game: Are We More Secure?

The Vulnerability Disclosure Game: Are We More Secure?
http://www2.csoonline.com/exclusives/column.html?CID=28072
By Marcus J. Ranum

Do you remember the original premise of the disclosure game? By publicly announcing vulnerabilities in products we will force the vendors to be more responsive in fixing them, and security will be better. Remember that one? Tell me, dear reader, after 10 years of flash-alerts, rushed patch cycles and zero-day attacks, do you think security has gotten better?

I know that Microsoft, Oracle and others have spent huge amounts of money improving the security of their software. Never mind the fact that 99.99 percent of the computer users in the world would rather they had spent that money making their software cheaper or faster, I suppose it’s a great thing to see that software security is being taken seriously. Security has gotten more expensive. But do you think security has gotten better?

It’s a tad ironic that the only way we could ever hope to answer this question is if the vendors practiced full-disclosure! The only way this question could be answered is to see a list of all the vulnerabilities that vendors like Microsoft or Oracle have found and fixed through in-house auditing. If they have found and fixed 1,000 vulnerabilities compared to the 250 publicly disclosed (arbitrary numbers), then yes, security has gotten better. Right? If software is shipping with less vulnerabilities per lines of code, then security has improved, and the “we’ll force your hand” crowd had something to do with it.

If twenty years of brutal full disclosure really did teach them the importance of security by forcing them to spend considerable money on said security, then didn’t those wiley “we’ll force your hand” folks in the 90′s do what they claimed, although a little differently than planned?

reply: Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea’

Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea’
http://www2.csoonline.com/exclusives/column.html?CID=28073
By Bruce Schneier

Full disclosure – the practice of making the details of security vulnerabilities public – is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure.

I don’t want to live in a world where companies can sell me software they know is full of holes or where the government can implement security measures without accountability. I much prefer a world where I have all the information I need to assess and protect my own security.

No reply needed.

reply: Microsoft: Responsible Vulnerability Disclosure Protects Users

Microsoft: Responsible Vulnerability Disclosure Protects Users
http://www2.csoonline.com/exclusives/column.html?CID=28071
By Mark Miller, Director, Microsoft Security Response Center

Responsible disclosure, reporting a vulnerability directly to the vendor and allowing sufficient time to produce an update, benefits the users and everyone else in the security ecosystem by providing the most comprehensive and highest-quality security update possible.

Provided “sufficient time” doesn’t drag out too long, else the computer criminal (who are in the ‘security ecosystem’) benefit greatly from responsible disclosure too.

From my experience helping customers digest and respond to full disclosure reports, I can tell you that responsible disclosure, while not perfect, doesn’t increase risk as full disclosure can.

Except “your experience” wouldn’t take full disclosure cases into account appropriately. Look at some of the vulnerabilities reported in Windows, Real, Novell and other big vendors. Notice that in more and more cases, we’re seeing the vendor acknowledge multiple researchers who found the issues independantly. That is proof that multiple people know about vulnerabilities pre-disclosure, be it full or responsible. If a computer criminal has such vulnerability information that remains unpatched for a year due to the vendor producing “the most comprehensive and highest-quality security update possible”, then the risk is far worse than the responsible disclosure your experience encompasses.

Vendors only take these shortcuts because we have to, knowing that once vulnerability details are published the time to exploit can be exceedingly short-many times in the range of days or hours.

See above, the bolded “proof” I mention. If vendors are going to move along with their head in the sand, pretending that there is a single person with the vulnerability or exploit details, and pretending that they alone control the disclosure, the vendors are naive beyond imagination.

The security researcher community is an integral part of this change, with Microsoft products experiencing approximately 75 percent responsible disclosure.

I’d love to see the chart showing issues in Microsoft products (as listed in OSVDB), relevant dates (disclosed to vendor, patch date, public disclosure) and the resulting statistics. My gut says it would be less than 75%.

Bogus RFI Reports Getting Out of Hand

I know we’re all getting tired of the Remote File Inclusion (RFI) vulnerabilities being disclosed that end up being debunked, but this one takes the cake so far (yes I’m behind on e-mail).

Fri Jun 16 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0321.html
(1) path/action.php, and to files in path/nucleus including (2) media.php, (3) /xmlrpc/server.php, and (4) /xmlrpc/api_metaweblog.inc.php

Sat Jun 17 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0447.html
Demonstrated that the vulnerability is bogus.

Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0486.html
media.php

Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0501.html
Demonstrated (again) that the vulnerability is bogus.

So not only is it fake, it was also previously disclosed and debunked. I swear, Bugtraq moderators should seriously consider blocking any RFI disclosure from hotmail.com. Would save Vulnerability Databases a lot of time.

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

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.

Follow

Get every new post delivered to your Inbox.

Join 4,759 other followers