10:20 CET, 9th March 2012 By Carsten Eiram.
This week, Secunia had to publish an advisory for a currently unpatched vulnerability in Safari as Apple failed to provide a proper status update after 6 months of coordination via SVCRP. This blog describes the background for this release and some of the difficulties researchers - and sometimes even coordination houses like Secunia - may face when attempting to coordinate disclosures with a software vendor.
When a researcher decides to coordinate a vulnerability discovery with a vendor, it is commonly expected that the vendor provides status updates on the progress, ensuring that the researcher knows that the vendor is actively working on a fix. Some vendors provide these status updates automatically while others on demand. In either case, a certain level of detail on the progress is expected; further into the process, it is also expected that the vendor can provide an estimated fix date.
When reporting a vulnerability to Apple their initial response clarifies that status updates are not automatically provided, but that the researcher should feel free to request one if needed. When requesting a status update, these are sometimes fairly informative, but often just a short standard response, providing no real information on the current progress nor expected fix date (e.g. "We are still investigating this issue, and have no current estimate as to when a security update for this issue will be available"). Should a researcher press Apple for more information on their progress and an expected fix date, Apple hides behind an internal policy, dictating that "Apple does not comment on the specific timing of future product releases or updates, as our product release schedules are subject to change at any time".
Naturally, fix dates may be subject to change and most researchers seem willing to push a targeted disclosure date if required in order for the vendor to release a proper fix. However, after a vendor has had a chance to analyse and start addressing a vulnerability, researchers deserve to know when a fix should be expected. Fortunately, this is something most of the major software vendors like Microsoft, Adobe, Symantec, Novell, and IBM.
In this specific case, Apple had 6 months to look into the coordinated vulnerability - and 8½ months looking into another Safari vulnerability also published this week. As both vulnerabilities were subject to our old disclosure policy, Apple had up to 1 year to issue fixes as long as they could provide proper status updates. Our new disclosure policy published in 2012 provides a 6 month semi-hard deadline.
When we requested a status update from Apple a month ago (i.e. 5 months into the coordination process), we received a response stating that Apple had no further information to provide. The previous status update given 3½ months into the coordination process had just stated that Apple confirmed the vulnerability and was investigating. We informed Apple that a proper status update was needed to pass on to the researcher, whom we were coordinating the vulnerability for, but the request was ignored. A week later we sent a follow-up and Apple responded that it was against policy to comment on fix dates. Ultimately, Apple was informed that unless a more detailed response with information on a target date could be provided, we would have to publish the advisory three weeks later on 7th March 2012. No response was ever received and the advisory went out.
It's regretful to experience that there are still some major software vendors that do not understand how to properly work with researchers. Hopefully, Apple will in the future strive to work better with researchers to ultimately protect their customers by providing more informative status updates and estimated fix dates instead of prioritising antiquated internal policies higher.
Chief Security Specialist
Subject: Coordinating Vulnerability Disclosures with Apple