Zenphoto and the Security Community 06 November 2013
The Zenphoto team typically works in conjunction with the Security Community to insure you, our users, can be confident in the environment we provide. The unfortunate nature of software is that bugs creep in. When some of those introduce security issues we are grateful to the Security Community for pointing them out to us.
We take any report seriously
A typical scenario is that a researcher will discover a potential flaw. He will develop an example exploit to verify his hypothesis, and then he will send a report to us describing his analysis and including the example exploit. This is proper scientific methodology consisting of a hypothesis and an experiment to validate it. The two are really integral components. A hypothesis without an experiment is simply speculation without substantiation.
We receive the report, verify that the problem still exists, and if so attempt to speedily correct the issue. The correction will always go into the current support build which you can download and install if you feel the need. Depending on the severity of the threat we may also make an immediate release as we know that users are more likely to install a release build than the support release. This deploys the fix to the maximum percent of our community. We also report back to the researcher the details of what release contains the fix and when it is to be generally available. We expect that the researcher report will include these details so that users reading it will know what action to take.
If the research was done on an earlier version of Zenphoto than the current the test case may not succeed on the current release. In this case we presume that the problem has been fixed as a side effect of other changes and so report to the researcher. We expect in this case that the researcher will verify the fix on the current release and so report in his publication.
Sometimes we disagree with the exploit. An example might be when the exploit requires that a logged in user enter contaminated data into a field on the administration pages. Our presumption is that site owners do not deliberately sabotage their sites. (As an aside, if this assumption is wrong there would typically be much simpler means for him to do so than the esoteric exploits we typically see.) What we do in this case will depend on the root analysis and the impact of any fix on Zenphoto usability.
Security and usability
Security and usability are typically tradeoffs. For instance, you can require strong passwords on your site. But this makes them harder to remember for the user so makes the site less useable. (Or in some circumstances less secure—when the user writes the password down on a post-it note attached to his display screen.) Other times the code needed to prevent the vulnerability can be costly and slow the system down. It was this that led to our removing the front-end editing capability from Zenphoto. We could have made it secure, but that would have placed a performance burden on all access to the site. We did not feel that the cost was justified.
From time to time we receive reports from “researchers” that do not conform to the norm set above. They may omit providing the test exploit or the test may be un-realistic (for instance presuming that the site owner will deliberately enter the exploiting text.) We still take these seriously if we can. If the description does not make sense to us we will request the exploit be updated to a rigorous test.
Reports with missing test cases
Our problem comes when the “researcher” (one legitimate researcher has shared with me the term the community uses for these--Application Security Specialists, or ASS for short) insists on his claim without providing supporting test cases. The typical statement might be “Well if this parameter is so-in-so there will be a security breach.” But that begs the question of if the parameter could ever in the real world have that value. For instance, if the claim is that it could happen with a Cross Site Reference Forgery (XSRF) then our reasonable response is that XSRF attacks are detected and prevented when the scripts load, so the code at issue will not get executed. To add code wherever there might be a bogus parameter without verification of the possibility of the parameter ever getting that far is irresponsible. It adds overhead for no benefit. It also detracts from the time we can spend making the enhancements our community desires. (Investigating these inadequately documented claims also saps our limited resources.)
We have observed one commonality of the “researchers” who seem unwilling to do thorough research of their claims. They all seem to work for firms who might benefit from instilling fear, uncertainty and doubt in software users. They usually provide a service that can help you “fix” your problems. Perhaps it is a security consultancy; perhaps it is a software analysis tool. It is really sad that these companies feel they must resort to such tactics. To me doing so really detracts from their reputation and credentials.
So what does all this mean to you?
If you see a security report about Zenphoto look for the following:
- A concise description of the security issue
- An analysis of the root cause of the problem
- A verifiable experiment to demonstrate that the problem is real world
- A response from the Zenphoto team
If any of the above are missing consider the report suspicious. At the very least it means the reporter did not follow the Security Community custom (so may not even be familiar with it.)