Issue 44245 - Basic macro security : a tree can't be a trusted source
Summary: Basic macro security : a tree can't be a trusted source
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.0 Beta
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 2.0.1
Assignee: joerg.skottke
QA Contact: issues@framework
URL:
Keywords:
: 51495 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-03-06 19:51 UTC by bmarcelly
Modified: 2006-01-02 12:30 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bmarcelly 2005-03-06 19:51:47 UTC
If you set a given directory as trusted source, only macros from documents in that 
directory are accepted to run. Macros from documents in a sub-directory are still 
prevented to run (unless manual confirmation if security level = medium).
In OOo 1.1 all macro documents in sub-directories are allowed to run.
In OOo 2.0 it is necessary to add each sub-directory as trusted source. This can be 
very cumbersome for the user, especially if he/she changes/adds the subdirectories. I 
suppose this is not a feature but a design error.
Comment 1 jack.warchold 2005-05-31 14:37:12 UTC
reassigned to jsk
Comment 2 joerg.skottke 2005-06-24 11:07:41 UTC
jsk->mba: Shouldn't we maintain the "old" behaviour? I'm not deeply involved in
the macro security stuff, so i reassign the issue to you for evaluation. 

Note: I'm on vacation the next three weeks.
Comment 3 Mathias_Bauer 2005-06-27 16:40:31 UTC
Mikhail, can you evaluate why the setting does not work recursive anymore? The
target we can assign to this issue depends on the risk that is caused by the bug
fix-
Comment 4 mikhail.voytenko 2005-06-28 11:23:58 UTC
MAV->MT: The decision whether the location is trusted one is done currently
using XDocumentDigitalSignatures::isLocationTrusted() call implemented in the
'xmlsecurity' project. Please take a look.
Comment 5 malte_timmermann 2005-06-29 08:59:18 UTC
MAV volunteered to fix :)
Comment 6 malte_timmermann 2005-06-29 11:07:55 UTC
2.0...
Comment 7 mikhail.voytenko 2005-06-30 14:00:14 UTC
After discussing with HRO it looks like the detection, whether a folder provided
by user ( the folder that contains the document with macro in this case ) is
defenitly in the list of the trusted folder, seems to be impossible on Windows
platform in some cases. 

If the folder points to a volume with case sencitive naming the normalized name
can not really be retrieved by windows functionality, actually it can, but the
retrieved name might point to a different folder with the same name containing
letters in different case. That means that a document that is in a folder that
is not registered as trusted could be accepted as trusted one.

So it looks like in such cases, the office should detect whether the path to the
document points to a location for wich the nonambiguous normalized path can be
retrieved, if not no further comparing should be done.
Or it should be a documented design feature, that such pathes should be entered
in case insencitive way in the configuration in general, in this case it is more
correct to name them patterns not pathes.

Changing the target as discussed with MT and MBA to OOo2.0.1 for now.
Comment 8 bmarcelly 2005-07-02 09:46:27 UTC
This is a general case with MS-Windows, where folder and file names are treated as 
case insensitive.
Suppose you have a macro folder C:\OOo 
- add it to the list of secure folders.
- then rename the folder as C:\Ooo
The folder is no more recognized as secure. This can be seen as annoyance for a MS-
Windows user.
Your argument of a folder pointing to a case-sensitive volume is far-fetched, it is 
rather a network configuration error because it can facilitate malicious changes or 
hard to detect anomalies.
In my opinion MS-Windows folder names comparison should be case insensitive, and that 
should be documented. The case-sensitive security risk is beyond OpenOffice scope.
Comment 9 bmarcelly 2005-07-02 13:51:02 UTC
I issued IZ 51495 for my previous comment on folder name case-sensitivity because it is 
another defect.
Comment 10 mikhail.voytenko 2005-07-04 09:09:45 UTC
mav->bmarcelly:
Case insencitivity is not a general case on Windows. It is a general case only
on local windows machine.
The case when an nfs or a samba volume is mounted on a windows machine one of
the most common for enterprize users. I agree that this will not happen for a
user who uses his windows machine offline, but that does not mean that we should
not care about it.

By the way, please read my previous comment carefully, the suggestion about
using case insencitive pattern is already there as the second alternative. Doing
so only on Windows platform would be just a hack from my point of view, just
because as I have mentiontioned already, it _is_ possible to have case sencitive
file system even on Windows, thus if we are going to document and implement case
insencitivity for this case it should be done for all platforms.

Comment 11 mikhail.voytenko 2005-08-17 10:24:40 UTC
The final decision is to retrieve normalized pathes and compare them as
described above. So the office will behave itself correctly, and if a system is
not able to provide the correct information, it is indeed the problem of the
system and out of the scope of the office implementation.

There seems to be no need to document anything related to the office behaviour
in this case, since the possible problem during normalized path retrieving
happens on Windows side.
Comment 12 mikhail.voytenko 2005-08-17 10:27:36 UTC
*** Issue 51495 has been marked as a duplicate of this issue. ***
Comment 13 mikhail.voytenko 2005-08-31 13:31:26 UTC
Please verify the issue.

re-open issue and reassign to jsk@openoffice.org
Comment 14 mikhail.voytenko 2005-08-31 13:31:32 UTC
reassign to jsk@openoffice.org
Comment 15 mikhail.voytenko 2005-08-31 13:31:38 UTC
reset resolution to FIXED
Comment 16 mikhail.voytenko 2005-09-28 10:15:52 UTC
MAV->JSK:
One of simple scenarios to test the issue may be following: 
Please create a folder and a subfolder, copy a document with a macro executed on
loading into the folder and into the subfolder. After that please set in the
office options dialog the macro security settings to the most strict value (
execute macro from the trusted locations only )  and update the list of the
trusted locations with the path to the created folder. After that if a document
either from the folder or from the subfolder is opened the macro must be
executed, if the same document is opened from any other location the macro must
not be executed.
After that please rename the created folder in the way, that one or more letters
in it name has changed case ( described by the issue 51495 ). After that for the
document from the folder opened on Unix platforms the macro must not be
executed, and on Windows platform it must be executed.
Comment 17 joerg.skottke 2005-09-28 12:10:04 UTC
Setting verified. Tested on Windows 2000 (Case insensitive) and Linux (Case
sensitive). In both cases the security setting/trusted path combination works as
expected.
Comment 18 joerg.skottke 2006-01-02 12:30:55 UTC
fixed.