openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Officially releasing a patch for CVE-2016-1513
Date Fri, 12 Aug 2016 19:22:12 GMT

Having worked through the 4.1.2-patch1 (CVE-2016-1513 remediation) for Windows, I learned
a few more things about what can be done.

> -----Original Message-----
> From: Dennis E. Hamilton []
> Sent: Sunday, July 24, 2016 15:45
> To:
> Subject: RE: Officially releasing a patch for CVE-2016-1513
> The patched DLL is shipped with an external digital signature.  I guess
> we could ask that to be installed alongside it.  That would be a good
> tell-tale.
> The web site where the patch is downloadable from will have hashes for
> the archive containing the patched library and will also have an
> external signature for that.  These are on a secure AOO infrastructure
> site, the best place to retrieve hashes and signature files.  There is
> no reason not to have a hash of the library inside the downloadable
> archive for those who, for some reason, cannot check the signature but
> can verify the hash.

There are hashes and a signature for the Zip that contains the patch and any procedure.

In the Windows case, the copies of the original distributed tl.dll and the patched one each
have detached signatures inside the Zip as well.  No hashes have been added there, on the
assumption that checking the Zip is good enough.

> In the manual procedure, we will ask users to rename the existing
> shared-library before copying in the replacement.  This will provide a
> means to revert to the patched library if a regression results.

This approach is used.  If the patch is applied, the original tl.dll is renamed to tl.dll.old.
 This is in the manual procedure and it is also provided by the script for the automated procedure.

The script for applying the patch can also be used to determine the patch is already there.
 The script for reverting the patch will determine first whether the patch has been applied.
> There is a difference in file-creation dates and in the size of the
> files as well.  The procedure for hotfixing with the patched library
> should provide that information to discourage attempting to patch a
> different release and also make it easier to tell the patch is there.

For Windows, it turns out that dates are a problem on files because of how Windows distinguishes
between created and modified. Some operations change one and not the other in unexpected ways.
 There are also differences in this regard between versions of Windows in the range Windows
XP to Windows 10.  

There also seem to be possible issued with the Windows installer putting new dates on things.

Finally, it is not possible to check dates easily using a .bat script on Windows.  

This is all resolved in the current 0.1.0 beta of the 4.1.2-patch1 for Windows by literally
comparing files, rather than checking their dates and it is done without depending on signature
computation tools being available on the machine.

That's how the procedure determines whether the patch file has already been applied or not.

> You're right that different builds by others who look to just extract
> the shared library will likely end up with a different binary of that
> library.  For a binary distribution from any origin that has the patch
> compiled-in, I would think something like the static string might be
> helpful.  If we do that in the AOO4121 tag, we'll have to redo the
> patched libraries we've already built.  I was hoping we could avoid that
> and stick with ones we have done some testing on already.
> Is what we're planning enough?
>  - Dennis

I think this is still good enough.  Someone who sees tl.dll.old in there will know there has
been a patch.

There are more sophisticated scripts that could be developed.  That is worth addressing elsewhere
on one of these threads.

> > -----Original Message-----
> > From: Don Lewis []
> > Sent: Sunday, July 24, 2016 15:14
> > To:
> > Subject: Re: Officially releasing a patch for CVE-2016-1513
> >
> > On 24 Jul, Don Lewis wrote:
> >
> > > At a minimum, we should publish the hash values of buggy and fixed
> > > versions of the library.  That might not help someone who builds and
> > > installs from source since the build not be completely repeatable.
> > > For instance the library might contain a timestamp.
> >
> > Adding a static string "CVE-2016-1513 Fixed" to the source is another
> > possibiliy.  On *nix, the user/administrator can run:
> > 	strings | grep CVE
> > and look for the above to verify that the fixed library has been
> > installed.  Someone would have to figure out how to do the equivalent
> on
> > Windows.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message