Re: CVE-2012-0037: libraptor - XXE in RDF/XML File Interpretation (Multiple office products affected)

[Solar Designer <solar@xxxxxxxxxxxx>]

Hi,

As stated in the timeline below (thanks!), this issue was handled in
part using the Openwall-hosted distros list (which currently notifies
many Linux distro vendors, FreeBSD, and NetBSD/pkgsrc with PGP
re-encryption to individual recipients):

http://oss-security.openwall.org/wiki/mailing-lists/distros

The primary reason why I feel I have to post this follow-up message is
that the long embargo period here was a major violation of the list's
policy.  It is the second major violation so far; the first one was for
HashDoS, and it was similarly discussed on oss-security after the fact:

http://www.openwall.com/lists/oss-security/2011/12/29/4
http://www.openwall.com/lists/oss-security/2011/12/29/7

It's cases like this that may eventually make us reconsider and stop
hosting the non-public lists.  (Some propose automatic publishing of
messages after N days as an alternative.)  Luckily, so far violations
like this have been relatively rare, and one of the reasons why I feel
every one of them needs attention is to keep it so.

I've included more detail below:

On Sat, Mar 24, 2012 at 09:40:42AM -0700, VSR Advisories wrote:
> 2012-01-09    OpenOffice, LibreOffice, AbiWord, KOffice, and libraptor
>               maintainers were provided a draft advisory and test sample.
>               The OpenWall "distros" mailing list was also notified.
>               Apache OpenOffice Security team acknowledged notification.
>               libraptor developer confirmed flaw.
> 
> 2012-01-10    CVE-2012-0037 assigned by Apache.
> 
> 2012-02-02    Notified OpenWall "distros" mailing list again, due to previous
>               technical problems.

IIRC, the "technical problems" being referred to here were an attachment
not being re-encrypted to list members, so they only had partial info
until this point - essentially just the fact that there's a
vulnerability in those products, but with no detail; given the extra
embargo time (not needed by distro vendors) this may actually be good.
The list setup is a bit picky about what encrypted message formats it
supports (besides plaintext, they may be PGP/MIME or PGP inline, but
they can't have individual pre-encrypted attachments - this has since
been clarified on the wiki).

> 2012-02-04    libraptor developer provided patches to all notified parties.
> 
> 2012-02-22    Extensive arguing between vendors about embargo/release date.
> 
> 2012-03-06    More arguing about release date.
> 
> 2012-03-14    Agreed upon release date established.
> 
> 2012-03-22    Security updates and vendor advisories released.
> 
> 2012-03-24    VSR advisory released.

At the time of the initial notification in January, the distros list
policy was to allow a maximum embargo period of 14 days (and this was
stated on the wiki page with the list posting address).  At the time of
the second notification in February, the policy was stated as:

"Please note that the maximum acceptable embargo period for issues
disclosed to these lists is 14 to 19 days, with embargoes longer than 14
days (up to 19) allowed in case the issue is reported on a Thursday or a
Friday and the proposed coordinated disclosure date is thus adjusted to
fall on a Monday or a Tuesday.  Please do not ask for a longer embargo.
In fact, embargo periods shorter than 7 days are preferable."

When it became apparent that this was to be violated since one or two of
the affected upstreams wanted much more time, the reporter (Timothy D.
Morgan of VSR Security) explained that at the time of his initial
notification he had thought that 14 days would in fact be enough.  While
this sounds like a rather fundamental problem with a maximum embargo
time policy (it is always possible that something new is discovered
during discussion, which may invalidate the initial time estimate of the
reporter), I've just added the following verbiage to hopefully reduce
the number of such occurrences going forward:

"If you have not yet notified upstream projects/developers of the
affected software, other affected distro vendors, and/or affected Open
Source projects, you may want to do so before notifying one of these
mailing lists in order to ensure that these other parties are OK with
the maximum embargo period that would apply (and if not, then you may
have to delay your notification to the mailing list), unless you're
confident you'd choose to ignore their preference anyway and disclose
the issue publicly soon as per the policy stated here."

Of course, I fully expect this attempt to sometimes fail, but maybe -
just maybe - it will help in some cases.  There's no perfect solution
here (although some would reasonably argue that simply not doing any
pre-disclosure coordination is perfect - in a way it is).

The time required by the free office product vendors to issue a security
fix here reminded me of web browsers in 1990s.  Several web browser
vendors have since learned to issue security fixes much quicker, but
apparently office vendors still lack processes to do so.  Besides, the
timing of the move of OpenOffice to Apache Incubator introduced a delay
here (I think it was the very first release of Apache OpenOffice).
I hope further security issues won't be taking this long to fix in
released versions (such as through quick new releases or a binary update
capability for existing releases).

Also, apparently it is still common practice to delay documenting
security fixes in office products as such - that is, since releases take
so long to prepare and test, they're first built with security fixes
included but undocumented, they're even made publicly available for
testing, and only then they're finalized and the security fixes become
publicly known as such.  This too is or should hopefully be a practice
of the past as it relates to some other software, and let's just pretend
that I naively hope it will be gone for these products (which is closely
related to being able to fix security issues and push such fixes to the
users quicker).

I'd appreciate any comments and suggestions - preferably on the public
oss-security list.  (Suggestions sent to me in private are a lot less
valuable since I can't fully refer to them.)

Alexander