Category: Patching

When Security Collides With Engineering (Responsible Disclosure Redux)

Stefan Esser announced earlier this week that he was retiring from citing irreconcilable differences with the PHP group on how to respond to security issues within PHP.
Of particular interest is that he will be making changes to how he handles security advisories for PHP (emphasis mine):

For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.

Since Stefan has locked out commenting his post, I’ll ask here:
Stefan, are you planning on providing workarounds for the advisories that don’t yet have patches? How are you planning on balancing the need for users to know versus broader exposure of a weakness? While I fully support your desire for full disclosure, I’m curious, what is too long? Where do you draw the line now that you’ve stepped further away from the project?
[Update: And more questions after talking to Adam. Why is PHP unable to unwilling to do security to Stefan’s standards? I’d love to hear both sides of this story…
Also what does this mean for PHP users? How bad off are they anyways?]
[Image is from Stefan’s Suhosin Hardened PHP Project.]

"Faux" Disclosure

I wasn’t going to join the debate on relative merits of Dave Maynor/Johnny Cache’s disclosure of vulnerabilities in device drivers at Black Hat 2006, but Bruce Schneier’s post calling it Faux Disclosure, has annoyed me enough that I feel obliged to comment now. In particular he says:

Full disclosure is the only thing that forces vendors to fix security problems. The further we move away from full disclosure, the less incentive vendors have to fix problems and the more at-risk we all are.

I think Bruce is missing a vital thought here that being, it is the threat of full disclosure and the effect that that disclosure will have on their customers that forces vendors to fix problems. Full disclosure without a remedy, when a vendor is working in a timely fashion to resolve the issue does nothing but hurt the end user. The fact of the matter is that given that patches were not yet available from the vendor, that it would have been incredibly irresponsible of Maynor and Cache to disclose the exact details of the vulnerability.
That’s my take on it at least.
Clearly, the issue of when and how much to disclose is still a hugely open topic.
I know several of our readers were at Blackhat and at least one participated on the Vulnerability Disclosure Panel, what did you think of what was said there? Has your opinion changed in light of the disclosure at Blackhat of yet another Cisco vulnerability?
[Edit: Fixed broken link. Also see Brian Kreb’s interview with David Maynor]

Your Apple-Fu Is Impressive!

patched-mac.jpgYesterday, DaveG posted “When OSX Worms Attack” Its some good analysis of the three Apple Worms:

Safari/Mail Vulnerability: Far more interesting. This is a serious vulnerability that needs to be fixed. If you are Mac user, I would at the very least uncheck ‘Open Safe Files’ in Safari preferences. I don’t understand why Apple isn’t advising people on this better. This vulnerability is public, trivial to exploit, and we are at the 7 day mark.

Just a bit over a day later, Apple ships APPLE-SA-2006-03-01, with about 21 CVE marked vulns, and two extra “security enhancements.” Some of it is confusing, for example, “Authenticated users may cause an rsync server to crash or execute arbitrary code” I understand neither the ordering or the lack of specificity.

“Crash” is what happens when I write exploit. “Execute arbitrary code” happens when DaveG writes exploits. So what’s happening? Is it “there’s an overflow, and we’re not sure if you can turn it into run code, and we fixed it?” That’s ok. No, I take it back. That’s great! I don’t want to have to prove that I can execute an overflow to see it fixed. Preemptive fixing is a great plan. If that’s what’s happening, please keep it up, and then please brag about it.

(Image stolen from the F-Secure blog.)

Updating Windows Mobile Phones

old-phone.jpgNothing we ever create, especially software, is ever perfect. One of the banes of professional systems administrators is the software update process, and the risk trade-offs it entails. Patch with a bad patch and you can crash a system; fail to patch soon enough, and you may fall to a known attack vector. The mobile phone companies have taken an innovative approach to the problem: They ignore it. It makes perfect sense to them. If a hacker bricks your phone, they’ll sell you a new one, with a new two-year lock-in.

I suspect this is frustrating to the authors of phone software, who have their own brand to consider:

Artak Abrahamyan , Technical Support Specialist from i-Mate, responded to my email requesting when they’d be releasing MSFP [Microsoft Security & Feature Pack] updates …Although I requested information about which devices would be receiving updates, he didn’t provide that information. My hope is that it will be for all of the Windows Mobile 5.0 devices that i-Mate has released so far. Looks like we’ll see this in early March. (From “Smartphone thoughts“)

This ‘innovative’ approach to preventing customers from getting at a patch has many upsides in fewer software variants running, higher assurance for the telco, and more time for worm writers to hone their attack code.

I am reasonably confident that my phone has security issues. (I’m not slamming Microsoft here–I’m reasonably confident that all software I’ve ever touched has security issues.) However, I have a phone running Windows Mobile, and so I’m aware of my failure to patch. I’d like to see a that allowed me to bypass this telco nonsense and get patches.

[Update: While I’m talking about telco security, let me mention the idiots at Cingular, who insist that caller-id is a good way to authenticate me to my voice mail, and refuse to give me a way to add a password. If you don’t understand why that’s a bad idea, “this google search” may enlighten you. Take a look at those ads.]
(Phone box photo by Alex Segre, on Flickr.)

Known unknowns?

Oracle has just released fixes for 82 vulnerabilities.
After taking several paragraphs to say “Many experts external to Oracle feel that patches for critical vulnerabilities are too slow in coming from the esteemed database giant, and have criticized the company for its slowness in responding to reports originating with outsiders”, Brian Krebs notes that security researchers such as Alexander Kornbrust and David Litchfield have reported at least 137 Oracle vulns which remain unfixed. He then makes an excellent point:

If we consider that Oracle finds more than 75 percent of flaws in-house, and the total number of the unpatched bugs reported to Oracle just by the above-mentioned security researchers is 137, how many flaws has Oracle uncovered in-house that it still hasn’t fixed? Not sure I’ll get the answer from Oracle, but at least I have asked the question.

The 75% figure comes from Oracle, and is in principle impossible to know with precision. Its accuracy depends on the number of Oracle zero-days out there. As Krebs observes:

[I]f there are widespread attacks against Oracle database servers, it is unlikely most people will ever hear about them — that is, until an affected company is forced through various state data-breach notification laws to go public with a few details (none of which are likely to include the affected hardware or software.)