incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Build and Release Hygiene
Date Mon, 16 Jul 2012 15:04:00 GMT
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


B) Testing our Release Candidates to verify that they are as clean as possible


View raw message