Sophos Cloud Optix
Updated 6 November 2012: We’ve updated the below article to give precise dates of when Sophos was informed of vulnerabilities, and when fixes were rolled-out to customers.
As a security company, keeping customers safe is Sophos’s primary responsibility. As a result, Sophos experts investigate all vulnerability reports and implement the best course of action in the tightest time period possible.
Recently, researcher Tavis Ormandy contacted Sophos about an examination he had done of Sophos’s anti-virus product, identifying a number of issues:
- A remote code execution vulnerability was discovered in how the Sophos anti-virus engine scans malformed Visual Basic 6 compiled files. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers completed: 22 October 2012 (42 days later)
- The Sophos web protection and web control Layered Service Provider (LSP) block page was found to include a XSS flaw. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers completed: 22 October 2012 (42 days later)
- An issue was identified with the BOPS technology in Sophos Anti-Virus for Windows and how it interacted with ASLR on Windows Vista and later. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers completed: 22 October 2012 (42 days later)
- An issue was identified in how Sophos protection interacts with Internet Explorer’s Protected Mode. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers began: 5 November 2012 (56 days later)
- Vulnerabilities were found in how Sophos’s anti-virus engine handles malformed CAB files. These vulnerabilities could cause the Sophos engine to corrupt memory. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers completed: 22 October 2012 (42 days later)
- Vulnerabilities were found in how Sophos’s anti-virus engine handles malformed RAR files. These vulnerabilities could cause the Sophos engine to corrupt memory. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 10 September 2012
Roll-out of a fix for Sophos customers began: 5 November 2012 (56 days later)
- A remote code execution vulnerability was discovered in how the Sophos anti-virus engine scans malformed PDF files. Sophos has seen no evidence of this vulnerability being exploited in the wild.
First reported to Sophos: 5 October 2012
Roll-out of a fix for Sophos customers began: 5 November 2012 (31 days later)
- Tavis Ormandy provided samples of other malformed files, with no associated vulnerabilities, which can cause the Sophos anti-virus engine to behave unexpectedly. After being examined by Sophos experts, improvements were made to the robustness of the engine when it scans such files.
First reported to Sophos: 4 October 2012
Roll-out of a fix for Sophos customers will begin: 28 November 2012 (55 days later)
Best practice
Sophos customers are reminded of the following best practices:
1. Keep systems patched and up to date
2. Upgrade to the latest version of Sophos software to get the best protection
Responsible disclosure
Sophos believes in responsible disclosure.
The work of Tavis Ormandy, and others like him in the research community, who choose to work alongside security companies, can significantly strengthen software products. On behalf of its partners and customers, Sophos appreciates Tavis Ormandy’s efforts and responsible approach.
I applaud Tavis Ormandy and Sophos for working together to resolve these vulnerabilities and to protect Sophos’ customers.
It is only through responsible disclosure that significant progress in security can be made. Firms like Vupen could learn a lot from this kind of collaboration and by disclosing vulnerabilities responsibly.
Of course, it makes perfectly sense collaborating for free for a company that makes bucks with security software and doesn't bother using basic security practices, very logical indeed.
Hi Chap,
I disagree and I don’t see what you find wrong with my comment. If Tavis did not come forward and responsibly disclose the necessary information to Sophos, the vulnerabilities that he found may not have been found or worse, exploited by someone else.
I acknowledge that Sophos did not use basic security but they are taking security more seriously now (see Sean’s comments below).
——————————————-
I am not affiliated with Sophos, I am simply a volunteer commenter.
I read Travis Ormandy's original report this morning after seeing it fly around Twitter. As a corporate customer, I'm pleased to see such a response. Responsible disclosure such as this should be applauded.
I am slightly concerned by the repeat statement: "Sophos has seen no evidence of this vulnerability being exploited in the wild". Just because it hasn't been seen, it doesn't mean it's not there. How long was Stuxnet (and Duqu, Flame etc) around before detection?
If one man can find these issues, so can another, who may not disclose it as responsibly.
Hi Andrew
You're right. Although Sophos has seen no evidence so far of the vulnerabilities being exploited in the wild, that doesn't necessarily mean that will remain the case.
To that end we have been rolling out updates to our customers, patching systems and providing protection against the vulnerabilities.
We felt it was important to share information about whether the vulnerabilities had been exploited in the wild, so customers could properly assess the threat to their systems.
As always, we recommend that customers keep their computers up-to-date with the latest patches, and install the upgrades from Sophos.
Hope that helps
Of course, it makes perfectly sense collaborating for free for a company that makes bucks with security software and doesn't bother using basic security practices, very logical indeed.
It is not mentioned in this article how the security update rollout to customers was achieved on October 22nd and what components were changed. Is there somewhere we can go to check that what should have happened actually did?
In situations like this it would have been very helpful for Sophos to have emailed out to each corporate client with a quick,
"We're rolling out security updates automatically for these products… Click here to see what's changing."
The link would then go to a KB page detailing what to look for to verify that changes were made (changes in help-about, version numbers of console or agent files etc.).
"Trust but verify", right?
As the responsible party for my corporate environment, I should be given a chance to know about any meaningful changes or updates — particularly when those changes are the result of a public release. If a senior manager comes to me, waving Ormandy's two reports, do I:
a) Look dumbfounded and say, "Where did you find this? It's the first I've heard of it."
or
b) Reply, "Yes. Sophos already addressed most of those issues on October 22nd, informed me via email on the 25th, and I verified that we had received those updates successfully. We're still in good hands."
I know what I'd *like* to say. 🙂
Hi Gavin
Thanks for your message.
Sophos's support team has published a support knowledgebase article with more details here: http://www.sophos.com/en-us/support/knowledgebase… This includes version numbers and so forth.
Unfortunately, it was not possible to inform customers of the detailed nature of the updates in October before the publication of Tavis Ormandy's paper. I suspect he might have felt that Sophos was stealing his thunder if it had pre-announced his public disclosure, and that could have resulted in the disclosure of other vulnerabilities which at that stage had not been rolled out to Sophos's corporate customers.
Clearly premature disclosure would not have been in the interest of the majority of Sophos's customers.
If you have further product-related questions I am sure Sophos's support team would be happy to hear from you by phone, email or via their online forum. I'm afraid the Naked Security site isn't the ideal forum for product-related questions.
I hope my response helps, and thanks for your understanding.
Thank you Graham,
Your comments were indeed helpful. That KB article was exactly the kind of thing I was hoping existed, so I appreciate you linking to it here.
I absolutely understand the issue with Sophos not being able to say anything before Ormandy's reports were published and I was by no means asking for premature disclosure in the least — merely proactive disclosure when the time was right. Unfortunately this Naked Security article was the only communication from Sophos that I personally came across (though I did not hunt for more, I readily admit), hence my decision to reply with that general feedback here.
However you are of course quite correct that Naked Security is not the right venue to discuss specific product support issues, and I apologise if it was felt that my comments — though intended to be very general in nature — were misplaced in that regard.
Thank you for your attention as always, Graham, and in a broader context for all the work that the Naked Security writers do disseminating security issues out to the masses. This is an excellent resource as always!
As a potential Sophos customer, why did it take 42 days to start deploying fixes for the problems listed? These appear to be quite serious flaws in software that many companies are depending on to protect their workstations and servers.
We were definitely leaning towards Sophos but the slow turnaround mentioned in this article is going to make Sophos a hard sell to management. What is Sophos going to do to improve this in the future?
I think specifically, what we need to know is:
– will the development of the product(s) be reviewed so that Ormandy never has to use the phrase "It is inexcusable to ever ship security sensitive code without /GS on Windows or -fstack-protector on Linux and Mac" (page 15)?
– will plans be put in place for additional resources to be dynamically assigned to incident response, as required, to reduce the 42 day turnaround to resolve issues?
Hi Andrew,
Security researchers rightly focus on software vendors such as Sophos and our competitors.
We take this very seriously and are continuing our investigations well beyond the level of those issues raised by Tavis Ormandy.
We can roll out fixes very quickly, if necessary, but generally strike a balance between the frequency of updates and ensuring our customers remain properly protected without the burden of unnecessary upgrade cycles.
Hope that helps
42 days is not an unheard of amount of time for issues that have had no evidence of being exploited in the wild. Would you rather have a 12-day kneejerk patch put into place with minimal testing, which might take an otherwise benigh, unexploited issue and turn it into a customer-impacting mistake that proper coding and testing and time had fixed? As a potential customer, which approach would you like to have that will reduce your risk of attacks/downtime?
I'm sorry, but it is rarely a proper approach to question "days to patch" unless it is particularly egregious and/or involving publicly exploited issues.
Do you even code? 🙂
(I have no affiliation with Sophos.)
Thanks for the question AP,
Sophos has a process of regular updates to improve our products and address issues such as those privately disclosed to us by Tavis Ormandy.
We can roll out fixes very quickly, if necessary, but generally strike a balance between the frequency of updates and ensuring our customers remain properly protected without the burden of unnecessary upgrade cycles.
If it wasn't for Tavis Ormandy's push for a hard date on the publication of the paper, Sophos wouldn't have patched their products in 42 days. Tavis' paper said an original estimate from Sophos for a particular fix was Q1 2013!
Time to look for other security products…
Hi YK,
Sophos took all the issues raised by Tavis Ormandy extremely seriously.
In the particular case you refer to, the issue related to an architectural change which Mr Ormandy agreed was not critical to address ahead of more important fixes.
Hope that helps
I agree with the comments above concerning the time taken to issue these updates. Also I learned about these issues from mainstream media, i didnt receive any communication from Sophos which is dissapointing. In terms of the KB article posted above with the update versions each issue has a different 'Fixed in' version. It would be useful if Sophos could summarise and say something like "to fix these issues customers are recommended to update to version x".
Hi MBB,
Following a process of responsible disclosure, Sophos was not in a position to publicly communicate these issues until we had provided our customers with updates that prevent them from being exploited.
As soon as Tavis Ormandy published his paper we announced the details on Naked Security and published the knowledgebase article to ensure as much detail was available as rapidly as possible.
http://www.sophos.com/en-us/support/knowledgebase…
We’ll obviously look at what we could do in the future to improve communications in these incidents.
It seems like the response time from Sophos on getting these fixed is really slow. Whay is it taking so long to get your product patched?
I am also disturbed I received no proactive notification from Sophos – along with any recommended manual remediation steps or extra steps to insure we remain protected. Very poor in my opinion.
Hi Roger
I'm not sure that it's fair to say that Sophos's response was "really slow".
Tavis Ormandy works for Google, and is the co-author of an official Google note about vulnerability disclosure. This note recommends giving vendors sixty (60) days to fix critical bugs before publicising them, which Tavis did in this case.
Here is that Google article:
http://googleonlinesecurity.blogspot.com/2010/07/…
So, did Sophos meet the 60-day critical bugfix deadline suggested by Google?
Yes. The critical vulnerabilities reported to us by Tavis on 5th September were patched and rolled out within 42 days. The critical vulnerability reported on 05 October was patched and rolled out within 31 days.
Hope that helps reassure you regarding our speed of response.
Ok 42 days, seems long but software like this is no doubt extremely complex. However what I want to know is, how is it he found all of these serious vulnerabilities but Sophos never did? Do they not fuzz their own products? It seems strange to me that he could find all these serious issues but Sophos did not. This makes them seem very, very inept. I have to agree with others, Sophos is now sadly off the table for any future security purchases.
Hi Dave
Although we do carry out testing and security reviews of all our software, Tavis Ormandy has clearly managed to find a number of vulnerabilities that our own testing and reviews did not. The majority of vulnerabilities detected related to file handling and how we read and understand files like PDF and compressed files.
This is one of the most complex areas for security companies, but it is clear we need to do a far better job of identifying these issues.
As a result we are undertaking a complete review of our security design processes and making significant changes to our internal vulnerability testing procedures We have already implemented many of these changes, including far more extensive fuzz testing as part of our standard release procedures.
As a Sophos customer myself and one who recommended Sophos to quite few businesses I’m pretty worried about all this. Not so much about time took to patch the flaws, but how one security researcher working in his spare time managed to find so many serious flaws in a product which is supposed to be the most secure part of the system. How many more undetected issues are there, which are just waiting to be exploited by any clever hacker (who will not share their findings with Sophos)?
And what about Tavis thoughts on Sophos in general:
"As demonstrated in this paper, installing Sophos Antivirus exposes machines to considerable risk. If Sophos do not urgently improve their security posture, heir continued deployment causes significant risk to global networks and infrastructure.
…
For this reason, Sophos products should only ever be considered for low-value non-critical systems and never deployed on networks or environments here a complete compromise by adversaries would be inconvenient."
Hi Aras
If someone is focused enough on finding security issues then it will be possible to find them in any product. This is an inherent challenge of the software industry. We agree with Tavis Ormandy that several of the issues he found were serious, although we don’t necessarily share his opinion about the degree of risk to our customers, particularly now that we have released automatic updates that fix all the issues he identified.
We would also like to reassure customers that we are determined to minimize the risk of further vulnerabilities being identified. We are carrying out a thorough review of our security design processes and are making significant changes to our internal vulnerability testing procedures. We have already implemented many of these changes as part of our standard release procedures.
Hi Sean,
Thanks for your answer. Appreciate that no software is 100% secure. I just can't remember a case when so many security issues are found in a security software itself.
I think Sophos should hire a few guys like Tavis to periodically search for vulnerabilities in all their products. It’s "easy" to fix an issue when somebody comes and points a finger (and even provides working exploit samples). But this not good enough! Bad guys will not share their findings with Sophos. You must be one step ahead.
Last few months haven't been great for Sophos to say at least. First auto-update false positive fiasco (which wasted countless hours of my time). No this…
I will continue using Sophos for now, but my trust has been seriously damaged. I hope there are no more bad new coming from you guys.
Having read Tavis Ormandy's report I was looking forward to the official response from Sophos. I've looked through the blog and web page, and I have to wonder – is this blog post the official response?
That one person found such gaping vulnerabilities just by researching out of curiosity is disturbing. That the response basically is "yeah, he reported X number of things and we've fixed them – moving on" is alarming. We're talking about severe vulnerabilities, not only in the product itself but also in that core OS security mechanisms such as ASLR and Internet Explorer Protected Mode are effectively disabled.
To me, the question is not whether X amount of days to fix the flaws is good or not, but rather this: how is it possible that such basic design and coding flaws could exist without being caught in design and code reviews, penetration testing etc? If one guy could find this, what could a specialized team with more resources and malicious intent find?
Sophos, in all respect, I think you need to provide a better, more comprehensive answer. The big issue is not the vulnerabilities Tavis Ormandy found, but rather what the bad guys will find – after this you can be sure they're looking.. What's being done do address the root causes for these issues? By that, I mean not only plugging the identified holes and looking for similar holes, but also looking at what deficiencies in processes, technology etc. allowed those holes to exist in the first place.
Hi Mattias
We always take vulnerability reports very seriously, whether or not they are surrounded by publicity. We agreed with Tavis Ormandy that several of the issues he found during his research project were significant and concerning.
Although we have fixed the issues we are certainly not just ‘moving on’ – sorry we gave that impression.
We are determined to minimize the risk of further vulnerabilities being identified by any third party, and are carrying out a thorough review of our security design processes and are making significant changes to our internal vulnerability testing procedures. We have already implemented many of these changes as part of our standard release procedures and will be continuing to make changes over the coming weeks and months as we carry out thorough security audits across our products.