incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Date Tue, 27 Mar 2012 17:04:14 GMT
I agree that preserving an existing registrymodifications.xcu is desirable.

There's no problem so long as the AOO 3.4 install is set to have the UseSHA1 and UseBlowfish
options by default when there is no setting in registrymodifications.xcu.

If you are confident patching Common.xcs is sufficient for all of the paths where the default
is not over-ridden, let's do it.  It is probably easy to test whether there is an uncovered
path to the default setting in the Save Options class constructor.

 - Dennis

-----Original Message-----
From: Juergen Schmidt [mailto:jogischmidt@googlemail.com] 
Sent: Tuesday, March 27, 2012 00:46
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations

On 3/27/12 3:48 AM, Dennis E. Hamilton wrote:
> I confirmed my hypothesis.  When AOO 3.4 is installed over the top of an existing (i.e.,
OpenOffice.org 3.3.0) installation, it does not updated the registrymodifications.xcu that
is already there.  Since there are no settings of options for Save As Password use of SHA1
and Blowfish there, none are there after the AOO 3.4 install.  That means only the program-set
defaults will kick in and the user will be converted to "Save with Password" using SHA256/K
checksums and AES256 CBC encryption.
>

The update installs over an existing user installation where a user have 
made some local changes that we don't overwrite. Everything else would 
be probably surprising to the users who have potentially changed a lot 
of default values.

I think the behaviour is want the user expect. And the config entries 
are read from the configuration anyway independent from the 
initialization in the code. So either the default values from Common.xcs 
(finallly main.xcd) are used or the overwritten value in the user config 
layer.

I don't see a problem here.

Juergen


> I verified this with AOO 3.4 r1303653 atop OO.o 3.3.0.
>
>   - Dennis
>
> PS: I also confirmed that LibreOffice 3.5.0rc3 is adding chaff to XML files that are
compressed and encrypted, preventing easy access to known plaintexts for attacking the encryptions
in the ODF package.  (There is a discussion of chaff, among other technicalities at<https://issues.apache.org/ooo/show_bug.cgi?id=119090>.)
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Monday, March 26, 2012 17:16
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com; jsc@apache.org
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> I did more experiments with AOO-dev 3.4 and LO 3.5.0rc3 which I happened to have installed
where it was easy to test them together.
>
> TEST RESULTS
>
>   1. It is possible to change the default behavior of AOO-dev 3.4 and LO 3.5.0rc3 (both
of which produce AES 256 CBC and SHA256-1k encryptions by default) by setting options in registrymodifications.xcu.
>
>   2. If registrymodifications.xcu is deleted, a new one is created *but* it has *no*
settings for the SHA1 and Blowfish in ODF12 and these installations *revert* to AES256 CBC
and SHA256-1k even if their last use was with options set for Blowfish CFB and SHA1/1K.
>
> HYPOTHESIS **CONFIRMED**: If an install is done on top of a previous installation not
supporting AES to update to a later version, no settings for this will be added to the "legacy"
registrymodifications.xcu and the default will go into effect: encryptions will start being
done in AES256, surprise, surprise.
>
> RECOMMENDATION:
>
>   1. It looks like registrymodification.xcu is the place where a tool or script can do
the job when it comes to setting/changing the desired option.
>
>   2. It looks like there must be code changes to set the default to Blowfish and SHA1/1K
within the application to cover the case where registrymodification.xcu doesn't specify an
option either way.
>
>   This last may be in Common.xcs but I am betting that the assured default setting is
in the constructor initial values in savopt.cxx.  Why?  Because that class holds the options
and setters and getters for them.  Other software uses the setters when processing configuration
parameters from elsewhere, with the default value delivered by the getter when no configuration
parameter provides a change.  My money is on that being the place.
>
>   - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, March 25, 2012 18:15
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> TJ,
>
> I was doing some nosing around and, based on some information on the Community Forums
(thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu,
at least on Windows.  The location will vary with different versions of windows.
>
> On windows, you can find one under the installed-user profile, such as Documents&
 Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu
for any install since the AES256 has been instituted as default.  the *.xcu is actually an
XML file and you can find the settings by searching for "blowfish" and for "SHA1".
>
> How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no
idea.
>
>   - Dennis
>
> -----Original Message-----
> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
> Sent: Friday, March 23, 2012 11:26
> To: ooo-dev@incubator.apache.org
> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> [ ... ]
>
> ... options to consider:
>
> 3. User change to config file, to use the new option.
>
> I have suggested a writeup on this, but such instructions are much
> better aimed at the (few?) users who want the "latest and greatest"
> security option, and will do a little work to get it. (Does anybody know
> what that file name is? Given that, I volunteer to update the Release
> Notes.)
>
> 4. Macro to toggle the settings.
>
> This could be distributed in a BASIC library (new or existing); no
> extension necessary. User instructions to find and run the macro are
> simple. I may be able to write this; preliminary investigation is
> promising but not certain. I volunteer to try. There are several real
> experts on this list, whom I might ask for help.
>
> /tj/
>>
>>
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>>
>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>> Hi,
>>>>>
>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>> default provides a better security than before when I understand it
>>>>> correct. And if people detect potential problems they can save the
>>>>> document again with other settings.
>>>>>
>>>>> I agree that this is important for interoperability but no show
>>>>> stopper.
>>>>>
>>>>> Any other opinion?
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>> Hi, Jürgen,
>>>>
>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>> mention in the Release Notes; something like,
>>>>
>>>> PLEASE NOTE: the default options for [technical details here] should
>>>> provide your best /individual/ security. However, if you intend to share
>>>> the document in secure fashion, the default mode cannot be read by
>>>> * previous versions of OpenOffice.org
>>>> * current versions of LibreOffice, at least through [version]
>>>> * Ms Office [version info]
>>>> For compatibility, use the options [details here].
>>>>
>>>
>>> I agree that it make sense to mention it in the release notes.
>>>
>>> Any volunteer for updating the release notes?
>>>
>>> Juergen
>>
>>
>
>


Mime
View raw message