incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject [PROPOSAL] Keeping AOO Attack Surface Small
Date Thu, 24 Nov 2011 21:28:30 GMT
Here are some proposal elements around the Attack Surface of Apache OpenOffice and keeping
it small:

 P1. Extensions, supplements, and updates downloaded by the run-time installer or product
shall only be retrieved from URLs under Apache control from sites operated by Apache infrastructure.
 As a secondary defense, authentication procedures will be used to confirm the provenance
of such downloads.  

 P2. Registration, checking for notices/updates, and any other access to the web by the run-time
should be opt-in and accomplished with the default browser on the platform rather than within
the running code.  Example 1: Check for Updates in the Help menu is a link and selecting it
has the access performed by the default browser.  Example 2: User opt-ins to use of on-line
help.  Help requests to the internet are by providing Apache-controlled URLs to the default
browser.  The URLs are only to Apache-hosted sites.

 P3. Feature proposals shall be accompanied by assessment of whether or not the attack surface
of the product is expanded or not.  In most cases, it will be easy to indicate that there
is no concern.  Operations that can give rise to silent access to networks or execution of
code of unknown origin are automatically suspect.  Operations that can do so while the installer
or product is operated under elevated privilege are automatically considered serious.

 P4. Existing features that cannot be assured to be outside the attack surface of the product
will, when recognized/reported as such, be targeted for possible mitigation and other measures
that shrink or eliminate the attack surface contribution.

These are pro-active measures not related to discovery of defect-related vulnerabilities and
existing exploits.

I don't have a time-limit, or any default consensus, on this proposal.

-----Original Message-----
From: Rob Weir [] 
Sent: Thursday, November 24, 2011 09:40
Subject: Re: GPL'd dictionaries (was Re:

On Nov 24, 2011, at 12:17 PM, "Dennis E. Hamilton" <> wrote:

> Three concerns, in addition to the ones Gianluca expressed already:
> 1. The site is not working reliably and is not operated
by ASF.  Any in-product access to the site has to work well and deal with unavailability.

Do you have a proposal?

> 2. I repeat my security concern over the increase of the product attack surface when
such downloading and installation is done internal to operation of the product or its installer
(which may already require elevated privileges) without coming up with stronger means for
authenticating extension downloads.  (The dictionary case is for data, so that is not quite
so scary.  Authentication still matters.)

Do you have a proposal?

> 3. Any automatic update mechanism is a further concern.

Do you have a proposal?

> A security review activity is apparently missing from the development and feature-decision
process.  That is not going to serve us well considering that this is a consumer product directed
toward non-expert and household users.  It must be assumed that our turn will come.

Do you have a proposal?

> -----Original Message-----
> From: Andre Fischer []
> Sent: Thursday, November 24, 2011 05:29
> To:
> Subject: Re: GPL'd dictionaries (was Re:
> Hi all,
> The last open item on the IP clearance wiki page is the removal of the
> dictionary module from the AOO source code.  In order to provide a
> developer build in the near future that does not contain category-x
> licensed code we need a short term solution.
> The central question is if we have to really remove the dictionaries at
> all.  I did not see a definitive answer, so to be on the safe side I
> assume that the dictionary module should be removed.
> This leaves the question of a replacement.  One relatively straight
> forward way seems to be to use the extensions that can be found at
> Two ways of
> using these extensions come to (my) mind:
> A. Download the extension (assuming that the right locale can be
> detected) automatically from the extension repository during installation.
> B. As last step of the installation, pop up a web page that, among other
> things, tells the user that there is a dictionary extension that can be
> installed and what its license is.
> Variant A has the better usability but may not be acceptable from a
> legal view.
> Variant B would allow to display additional information and could offer
> other (dictionary) extensions as well but would require more work to be
> implemented.
> One problem with both variants is that
> already seems to have load problems.
>  When everybody who installs Apache OpenOffice has to access this
> server then its load would increase dramatically with a new release.
> Unless there are objections I will remove the dictionary module now, to
> clear the way for a category-x free developer build (or whatever its
> name should be).
> For the 3.4 release we have to decide on and implement a replacement.
> Best regards,
> Andre

View raw message