RE: Officially releasing a patch for CVE-2016-1513

[Dennis E. Hamilton]

> -Original Message-
> From: Don Lewis [mailto:truck...@apache.org]
> Sent: Friday, August 12, 2016 14:09
> To: dev@openoffice.apache.org
> Cc: dennis.hamil...@acm.org
> Subject: Re: Officially releasing a patch for CVE-2016-1513
> 
> 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.
[ ... ]
> > [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:
> 
[orcmid] 

Thanks.  I admire the demonstration of care, and the quality of the responses 
where concerns were raised.


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

The File Compare utility, FC, is built into all releases of Microsoft Windows.  
It is basically a standard external command of the cmd.exe console shell.  The 
.bat scripts use it to silently compare and then use the result codes to branch 
depending on what the level of result code is.

 - Dennis


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

Attention: Courtney

[Patricia Shanahan]

Courtney,

I tried to reply directly to your email three days ago. Please check 
whether a message from me got caught in a spam filter etc.


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

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Friday, August 12, 2016 13:55
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
> 
> 
> 
> On 8/12/2016 1:40 PM, Dennis E. Hamilton wrote:
> >> -Original Message- From: Patricia Shanahan
> >> [mailto:p...@acm.org] Sent: Thursday, August 11, 2016 11:07 To:
> >> dev@openoffice.apache.org Subject: Re: Planning for emergency
> >> releases
> >>
> > [ ... ]
> >>
> >> Meanwhile, it is interesting for contemplating a ready-to-release
> >> strategy. We would need to pick a step at which to hold a release
> >> that minimizes the time to put in one critical fix and ship it.
> > [orcmid]
> >
> > It strikes me that an always-existing candidate for a ready to
> > release is the last-previous stable release.
> >
> > The biggest reason is that there only needs to be regression testing,
> > since it is presumably well-established that said release is stable
> > and that has been confirmed on the ground by the success of users.
> >
> > There could be something else that is close, but it strikes me that
> > would probably be a pending maintenance release that is basically
> > about bug fixes and any simple things.
> >
> > I note that, for changing the installer, something we would like to
> > do, the rebuild of a stable release at least needs to be done and
> > checked to see that the install produces the same result.  If that
> > were tested to satisfaction, it would also qualify as a
> > ready-to-release base without having to be put in the wild.
> 
> Personally, I would like to treat the last stable release as the base
> for emergency fixes. I started out suggesting using the current patch as
> an exercise to work through the process for doing that.
> 
> However, I have seen a lot of push back on the idea of ever doing a
> release that only has one change.
[orcmid] 

Yes.  It might be necessary to do triage - choose highly-vulnerable platforms, 
common languages, etc.

And, if we are talking about an unpatched vulnerability with an exploit in the 
wild, I don't think the ASF Board will be sympathetic to our reticence. 

I agree that we do need to do fire drills simply to be able to respond when an 
emergency arises.  

 - Dennis
> 
> -
> 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

RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

[Dennis E. Hamilton]

> -Original Message-
> From: Keith N. McKenna [mailto:keith.mcke...@comcast.net]
> Sent: Friday, August 12, 2016 13:49
> To: q...@openoffice.apache.org; dev@openoffice.apache.org
> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> 
> Attached is a text file with the tests that I ran and the results of
> each. The only problem encountered was in verifying tl.dll.new with the
> .asc signature file. This was due to the web of trust issue discussed
> earlier in this thread.Patricia's signature had not been certified by
> anyone. One I elevated the Owner Trust level and certified it the
> verification passed.
> 
> I will finish reviewing the latest documentation and send any comments
> or suggested changes under separate cover.
> 
> Regards
> Keith
[orcmid] 

Thanks Keith.  The copy-paste error in the APPLY :FAIL3 message will be fixed.  
Thanks for being so attentive and meticulous.  Your test log is wonderful.

 I'm gratified that the Administrator Permissions pain has been alleviated on 
both admin and standard Windows 7 accounts.

I look forward to anything else you come up with.  I anticipate that we can go 
to 1.0.0 for the next round and make general availability next week.

 - Dennis
> 
> 
> Dennis E. Hamilton wrote:
> 
> 
>   BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE
> 
>   The scripts make life much easier, since users don't have to go
> hunting for anything and digging around in operating-system locations.
> 
>   You should be able to go through the procedure that uses the
> automated steps pretty easily.
> 
>   It is very important to know the difficulties that arise or whether
> there were none.
> 
>   The material is available at
>    patch1/binaries/Windows>
>  patch1/binaries/Windows> .
> 
>- Dennis
[ ... ]



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

Re: Officially releasing a patch for CVE-2016-1513

[Don Lewis]

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:


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Don Lewis]

On 12 Aug, Dennis E. Hamilton wrote:
> 
> 
>> -Original Message-
>> From: Don Lewis [mailto:truck...@apache.org]
>> Sent: Thursday, August 11, 2016 14:41
>> To: dev@openoffice.apache.org; ksch...@apache.org
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>> 
>> On 11 Aug, Kay sch...@apache.org wrote:
>> >
>> >
>> > On 08/11/2016 12:50 PM, Kay sch...@apache.org wrote:
>> >>
>> >>
>> >> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> >>> [top posting]
>> >>> I'm in the process of trying to "sync" instructions for Linux32,
>> >>> Linux64, and MacOSX at the moment. As far as instructions on the
>> >>> actual HOTFIX page, we need to have just a "general" instruction
>> >>> for ALL zips that simply says -- "Unzip this package to some
>> >>> folder of your choosing and read the README that's included."
>> >>> Everything else should be in the various READMEs for each
>> >>> platform.
>> >>>
>> >>> I should be done with all edits by this evening for a final
>> >>> review before zipping and signing.
>> >>
>> >> Ok, I've now moved on to creating zip files, etc for Linux32,
>> >> Linux64 and Mac.
>> >>
>> >> My openssl version on does NOT supply digest sha256. Is it OK to
>> >> use sha1? MD5 already computed for each of these.
>> >
>> > sha1 is referenced on the ASF code signing page so I decided it was
>> OK. :)
>> 
>> I'm really surprised that ASF requires MD5 since it was broken long
>> ago. Even SHA1 is now regarded as a weak hash.
> [orcmid] 
> 
> I think it depends on shrinking the attack surface and also what the
> MD5 is being used for.  In the present case, it is extremely difficult
> to construct a Zip that has different usable content and the same
> hash.  It would require adding extra content until the correct hash is
> duplicated despite alteration of the key payload, and that should
> become rather evident.  I think the main reason for keeping it is that
> checking the MD5 is still more widely available to users.  It may not
> be foolproof but it is better than not.
> 
> And yes, collisions are possible and can be manufactured, but having
> one that accomplishes something can be rather tricky.  The
> proofs-of-concept involve alterations that aren't visible and won't be
> noticed.  Somebody will notice and it is not clear that the possible
> benefit is worth the effort to pull it off, especially against the
> risk of discovery.
> 
> Hmm, one thing we could do is add the length of the zip in the README.
>  (It takes a little work, but can be done, even when the (signed)
> README is inside the Zip.  That's another nice reason for having the
> signed README also available for independent download outside of the
> Zip and only downloadable from the ASF archive site, along with the
> different hashes and the package's signature.

Adding the length definitely raises the bar.  When downloading
third-party source tarballs to build FreeBSD packages, both the hash and
file size are checked.  Even so, FreeBSD has switched from md5, to sha1,
and now sha256 for the hash.


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

Re: Planning for emergency releases

[Patricia Shanahan]

On 8/12/2016 1:40 PM, Dennis E. Hamilton wrote:

-Original Message- From: Patricia Shanahan
[mailto:p...@acm.org] Sent: Thursday, August 11, 2016 11:07 To:
dev@openoffice.apache.org Subject: Re: Planning for emergency
releases


[ ... ]


Meanwhile, it is interesting for contemplating a ready-to-release
strategy. We would need to pick a step at which to hold a release
that minimizes the time to put in one critical fix and ship it.

[orcmid]

It strikes me that an always-existing candidate for a ready to
release is the last-previous stable release.

The biggest reason is that there only needs to be regression testing,
since it is presumably well-established that said release is stable
and that has been confirmed on the ground by the success of users.

There could be something else that is close, but it strikes me that
would probably be a pending maintenance release that is basically
about bug fixes and any simple things.

I note that, for changing the installer, something we would like to
do, the rebuild of a stable release at least needs to be done and
checked to see that the install produces the same result.  If that
were tested to satisfaction, it would also qualify as a
ready-to-release base without having to be put in the wild.


Personally, I would like to treat the last stable release as the base
for emergency fixes. I started out suggesting using the current patch as
an exercise to work through the process for doing that.

However, I have seen a lot of push back on the idea of ever doing a
release that only has one change.

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

Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

[Keith N. McKenna]

  
  
Attached is a text file with the
  tests that I ran and the results of each. The only problem
  encountered was in verifying tl.dll.new with the .asc signature
  file. This was due to the web of trust issue discussed earlier in
  this thread.Patricia's signature had not been certified by anyone.
  One I elevated the Owner Trust level and certified it the
  verification passed.
  
  I will finish reviewing the latest documentation and send any
  comments or suggested changes under separate cover.
  
  Regards
  Keith 

Dennis E. Hamilton wrote:


  BETA 0.1.0 WITH AUTOMATED SCRIPTS IS NOW AVAILABLE

The scripts make life much easier, since users don't have to go hunting for anything and digging around in operating-system locations.

You should be able to go through the procedure that uses the automated steps pretty easily.

It is very important to know the difficulties that arise or whether there were none.

The material is available at 
.

 - Dennis




  
-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Wednesday, August 10, 2016 18:01
To: dev@openoffice.apache.org
Cc: q...@openoffice.apache.org
Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

Beta version 0.1.0 is now nearing completion.

It will include two scripts, one for applying the patch, the other for
reverting the patch.

The .zip will also have a copy of the original 4.1.2 tl.dll as well as
the new one.  These are used in the procedures to verify the files that
are present in the OpenOffice configuration in order to apply the patch
and also to remove it.

Next steps:
 * Additional path testing of the two scripts and verification that
operation on Windows XP and on Windows 10 work as expected.

  
  [orcmid] 

Done
 
It is also much easier to work through the patch checks using the scripts.

  

 * Updating of the README to reflect the availability of the batch-file
scripts as well as the manual procedure if ever needed.

  
  [orcmid] 

Done


  

 * Although the Zips already carry executable code (i.e., DLLs) there
may be some Antivirus push-back where the policy is to not allow .zip
files with scripts in them.  The README will also have to address that
possibility.

  
  [orcmid] 

I forgot that at the last minute.  I will put that into the next version.  Meanwhile, those who check these procedures should report any AV objections they ran into.



  

 - Dennis



  -Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Monday, August 8, 2016 09:58
To: dev@openoffice.apache.org
Cc: q...@openoffice.apache.org
Subject: RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

Alpha version 0.0.1 of README-4.1.2-patch1-apply-Windows.txt has been
introduced into the files (and the .zip) at
.

This version reflects suggestions by Marcus Lange, Pedro Lino, and


Keith


  McKenna.  Suggestions that are not (yet) implemented will be discussed
in replies to their messages and on the bugzilla issue at
.


By its nature, this material is intended for users operating on


Windows.


  In some cases, incompatible forms are used on the Subversion server
where the above files are situated.  Version 0.0.1 attempts to
accommodate for this incompatibility.  In continuing to verify the
procedure, please indicate whether there are (now) difficulties using
the text files, especially on Windows.

Users of Linux systems may have difficulties with some utilities for
which the Windows versions of the same tool (e.g., md5sum) do not
produce Linux-acceptable line endings.  It is useful to know if that


is


  still the case.  The files have been confirmed to be usable using the
utilities built for use on Windows.

For future versions, the use of HTML instead of text will be


considered.


  HTML does not have white-space incompatibility problems across


different


  platforms. The HTML will also be digitally-signed as a means of
verifying its authenticity.

In addition to possibly using HTML as a better form for cross-platform
use of text, attention will now move toward introducing scripts that
automatically apply the change, replacing all of steps 9-18.

Meanwhile, it is valuable to continue testing that the replacement


file


  produces no regression or introduction of any defects not seen using


an


  unmodified Apache OpenOffice 4.1.2.

 - Dennis



  
-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Tuesday, August 2, 2016 20:31
To: dev@openoffice.apache.org
Cc: q...@openoffice.apache.org
Subject: [TESTING] 

RE: Planning for emergency releases

[Dennis E. Hamilton]

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Thursday, August 11, 2016 11:07
> To: dev@openoffice.apache.org
> Subject: Re: Planning for emergency releases
> 
[ ... ]
> 
> Meanwhile, it is interesting for contemplating a ready-to-release
> strategy. We would need to pick a step at which to hold a release that
> minimizes the time to put in one critical fix and ship it.
[orcmid] 

It strikes me that an always-existing candidate for a ready to release is the 
last-previous stable release.

The biggest reason is that there only needs to be regression testing, since it 
is presumably well-established that said release is stable and that has been 
confirmed on the ground by the success of users.

There could be something else that is close, but it strikes me that would 
probably be a pending maintenance release that is basically about bug fixes and 
any simple things.  

I note that, for changing the installer, something we would like to do, the 
rebuild of a stable release at least needs to be done and checked to see that 
the install produces the same result.  If that were tested to satisfaction, it 
would also qualify as a ready-to-release base without having to be put in the 
wild.

 - Dennis
> 
> -
> 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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Marcus]

Am 08/12/2016 10:01 PM, schrieb Patricia Shanahan:

On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
...

[Anecdotal Side Note: I just discovered that the MD5 hash for the
4.1.2 Windows .exe fails to check on my Windows system because of a
defect in the .md5 file. For reasons unknown, the md5sum tool that I
have requires exactly two spaces between the hash value and the name
of the file the hash is for. Once I fiddled around and added the
second space, it all checks. What is intriguing to me is that this
has not been reported by anyone, which is perhaps of greater concern
than the fact that MD5 is used [;<].


I may have encountered this problem, but just attributed it to my lack
of familiarity with the tools. I had no problem using md5sum to compute
the hash, and it matched the one in the file.


Just to document this also:
I haven't noticed this problwm because I've taken the hash values from 
the MD5 and SHA246 files and put it into the little program I have 
found. Then it compared it with the computed onces from the tl.dll file.


Marcus


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

Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)

[Patricia Shanahan]

On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
...

[Anecdotal Side Note: I just discovered that the MD5 hash for the
4.1.2 Windows .exe fails to check on my Windows system because of a
defect in the .md5 file.  For reasons unknown, the md5sum tool that I
have requires exactly two spaces between the hash value and the name
of the file the hash is for.  Once I fiddled around and added the
second space, it all checks.  What is intriguing to me is that this
has not been reported by anyone, which is perhaps of greater concern
than the fact that MD5 is used [;<].


I may have encountered this problem, but just attributed it to my lack
of familiarity with the tools. I had no problem using md5sum to compute
the hash, and it matched the one in the file.

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

RE: Ready to setup release build machines?

[Dennis E. Hamilton]

I thought that the basic requirement is that the release manager(s) do any 
builds on a machine under their [exclusive] individual control.  That also 
means satisfying baseline requirements for release builds though.  That pretty 
much requires use of a VM if the main development system of a release manager 
is aligned with different tools and dependencies.

I am not so certain about putting up shared release-build VMs on non-ASF 
infrastructure though. 

One advantage to using ASF infrastructure is to bring code signing into the 
fold.  That seems rather important down the road.

 - Dennis 

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Tuesday, August 9, 2016 10:29
> To: dev@openoffice.apache.org
> Subject: Ready to setup release build machines?
> 
> Seeing the issue from a purely technical point of view (i.e., imagining
> for a while that there is no cost associated and no Infra around), how
> far are we from having an "Apache OpenOffice build farm" where we can
> build releases?
> 
> Note: this is not a buildbot. Buildbots are meant to check that the
> build is not broken. They do create install sets, but for example the
> Linux builds wouldn't be as compatible as the ones we build on CentOS 5.
> What I mean here is VMs able to build a release.
> 
> I think that within two-three weekends I could theoretically be able to
> setup a Linux-based VM host and two KVM-based VMs running CentOS 5 (32
> and 64 bit) that would be able to build releases and that could have
> shared access (i.e., not only me but other active PMC members). But this
> would only cover a small subset of users.
> 
> What about Windows? Would someone be able, under the same hypothesis, to
> add a Windows VM to the stack? This would bring us much closer to full
> coverage.
> 
> And what about Mac? If I recall correctly, one is tied with Apple
> hardware for MacOS X. What would be a way to bring Mac builds under
> "collective" control?
> 
> Regards,
>Andrea.
> 
> -
> 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

RE: Officially releasing a patch for CVE-2016-1513

[Dennis E. Hamilton]

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

RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows

[Dennis E. Hamilton]

> -Original Message-
> From: Keith N. McKenna [mailto:keith.mcke...@comcast.net]
> Sent: Wednesday, August 3, 2016 12:47
> To: dev@openoffice.apache.org
> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> 
> Replies in line
> 
> Dennis E. Hamilton wrote:
> > Testing of an Apache OpenOffice 4.1.2-patch1 procedure is requested.
> >
> > The files to be used in testing are at
> > .
> >
[ ... ]
> [knmc]
> performed the procedure successfully on Windows 7 home premium 64 bit
> using an administrator account.
> Also performed the procedure successfully on the same system using an
> standard user account. This was however tedious as most of the steps to
> apply the patched .dll required entering the administrator password.
> 
> > * [IMPORTANT] Identify any missing, incomplete or confusing
> > information in the README.  Describe what you see as important
> > improvements before making general release of the procedure for use
> > by non-expert users of Apache OpenOffice on Windows.
> >
> [knmc]
> In section 10 of the procedure section the line "Open the folder
> selected in step (7)" should read "Open the folder selected in step (8)"
> 
> On the whole I found the README difficult to follow with information out
> of sequence and extraneous information such as not accepting help from
> unsolicited phone calls. Not bad information, just out of place in a
> process document. Now that I have some available time I will get out my
> "blue pencil" and mark-up the document.
> 
> One improvement for the average user would be to automate the process
> with a .bat file that could find the proper folders and do the copy and
> rename procedures.
[orcmid] 

There are now .bat files for automated application and reversal of the patch.  
It will be valuable to know how well those work better on Windows 7 now, and 
especially on the standard user account.

The editing of the README is also intended to alleviate some of your other 
concerns.

It is valuable to know whether this is now good enough from your experienced 
perspective.

 - Dennis
> 
> > The goal is to provide as much as we can to assist Windows users in
> > applying this fix with confidence and success.  The experience of
> > more-knowledgable users who appreciate the difficulties of
> > non-experts is important in achieving that.
> >
> > Thank you for any effort you invest and the feedback you provide.
> >
> > - Dennis
> >
> >
> >
> >
> >
> >
> > -- Dennis E. Hamilton orc...@apache.org dennis.hamil...@acm.org
> > +1-206-779-9430 https://keybase.io/orcmid  PGP F96E 89FF D456 628A
> > X.509 certs used and requested for signed e-mail
> >
> 
> 
> 



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