On 12 Aug, Dennis E. Hamilton wrote: > 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.
That sounds reasonable. Checking the zip before unpacking is important to prevent attacks against zip itself or to prevent unpacking some other sort of malware. This issue recently came up with FreeBSD, see: <http://docs.freebsd.org/cgi/mid.cgi?20160810115813.GA86720> >> >> 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. That also sounds reasonable. >> >> 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. That also sounds reasonable. What tool do you use for the file comparison? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
