Don,

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 [mailto:dennis.hamil...@acm.org]
> Sent: Sunday, July 24, 2016 15:45
> To: dev@openoffice.apache.org
> 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.
[orcmid] 

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.
[orcmid] 

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.
[orcmid] 

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
[orcmid] 

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 [mailto:truck...@apache.org]
> > Sent: Sunday, July 24, 2016 15:14
> > To: dev@openoffice.apache.org
> > 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 whatever.so | 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: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to