mailing list archives
Re: CVE-2012-0037: libraptor - XXE in RDF/XML File Interpretation (Multiple office products affected)
From: "Timothy D. Morgan" <tmorgan () vsecurity com>
Date: Tue, 27 Mar 2012 12:39:00 -0700
2012-02-02 Notified OpenWall "distros" mailing list again, due to previous
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).
Actually, I didn't manually encrypt the attachment, but my mail client's PGP
plugin likely did the equivalent. PGP/MIME is definitely preferred, but since
certain Windows-based mail clients utterly fail at interpreting it properly, I
often fall back to old style PGP when sending messages to strangers. I think
your updated text helps.
"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."
You may want to re-word this a little to make it utterly clear to those who
don't take the time to think about it. Perhaps something like "If expect
upstream vendors to require more than 14-19 days to develop a fix, establish a
release date with them prior to notifying this list". You could also break it
down in to step-by-step bullets. That page has grown much larger now and it is
tempting to skim...
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
I agree with you that releasing undocumented fixes carries significant risks.
It's become clear to me that the LO/OO projects have a ways to go when it comes
to release engineering.