|
|
The Month Of PHP Bugs
By Dan Morrill
Expert Author
Article Date: 2007-02-20
In general, I am a major advocate of responsible disclosure, and frankly even if some of the security bugs released during the "Month of PHP Bugs" are two years old, there is a question of dubious ethics here.
Or at least a last ditch effort to be listened to.
When ever someone discloses vulnerabilities without ensuring that a patch exists first, the risk to end users, servers, server administrators and companies can be devastating.
Zero Day attacks against unpatched code happens, but questioning folks on why they are doing it is very important as well. As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed. Source, Interview with Stefan Esser Via Security Focus The problem is that Mr. Esser is questionable, after leaving the PHP security team because "he didn't like how they were doing things", and now adding the "month of PHP Bugs" to the list of items that security folks should be questioning.
It's the bias that Mr. Esser brings to the table, in that he wants someone to listen to him.
The last resort that Mr. Esser has is to do a "Month of PHP bugs", knowing full well that the code is buggy anyways, but heavily used over the planet.
The risk and exposures that anyone running PHP over the month of march should result in a higher alertness on the part of information security folks.
Companies that make PHP dependent applications should be looking at each new bug, and then regression testing, then throwing patches out the window as each new release is made.
For bugs deep in the PHP code set, there is going to be little that any end user or corporate user will be able to do, but risk mitigation strategies are advised.
It will be interesting to see what the response of the PHP community is, but fair warning, this promises to be most difficult for those of us who run PHP apps, systems, and web sites on the internet.
Comments
Tag: PHP, security
Add to  Del.icio.us |  Digg |  Reddit |  Furl
About the Author:
Dan Morrill runs Techwag, a site all about his views on social media, education, technology, and some of the more interesting things that happen on the internet. He works at CityU of Seattle as the Program Director for the Computer Science, Information Systems and Information Security educational programs.
|
|
