We receive several reports a week of someone claiming that their OpenOffice is infected by a virus or trojan. We take such reports seriously, and I've investigated several myself, with steps such as:
1) create clean VM of Windows XP 2) install all XP patches 3) install security software that is claimed by user to detect the virus 4) install latest updates to the security software 5) install OpenOffice from the official download site 6) Run all the scans In every single case we've come up clean. The user was either already infected, infected from some other application, or downloaded an infected OO install from another website. This is good. But I have a feeling that this is more due to luck. Consider the "spear phishing" potential. It is not hard to determine who builds our Windows releases. So someone with access to a zero day attack, say, in Firefox or Internet Explorer (and such attacks can be purchased online at auctions) could send that person a spoofed email, claiming to contain a screen shot of an crash or other build issue, that exploits the browser bug and gets control of the build machine. This is well within the state of the art for today's attackers. This potential, plus the constant opportunity for social engineering or even human error, increases the risk. Even moving to a buildot for builds doesn't eliminate the risk. Of course, we should do what we can do to reduce the above risks. That is only prudent. But I think we also need a set of testing steps, after the signed Release Candidate is posted, to scan for the presence of malware, using clean environments (VM's, ideally) and using several different security scanners. Such a review should be part of our regular check list items, along with reviewing RAT scans or verifying the MD5 hashes. What do you think? What should be our standard procedure for: A) Ensuring that our builds are as clean as possible and B) Testing our Release Candidates to verify that they are as clean as possible -Rob
