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

["Timothy D. Morgan" <tmorgan () vsecurity com>]

Hi again,

> > 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).

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
> users quicker).

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.

tim