> On May 28, 2021, at 3:01 PM, Carl Marcum <cmar...@apache.org> wrote:
>
> Hi All,
>
> On 5/28/21 4:46 PM, Peter Kovacs wrote:
>>
>> On 28.05.21 22:04, Arrigo Marchiori wrote:
>>> Hello all,
>>>
>>> replying to an older message in this thread.
>>>
>>> On Thu, May 13, 2021 at 07:23:16PM -0400, Carl Marcum wrote:
>>>
>>> [...]
>>>> Hopefully we can collect the exceptions in the BZ issue noted in this
>>>> thread
>>>> and then agree on the direction.
>>>>
>>>> The few I see so far are:
>>>> 1. in-document links beginning with #.
>>>> 2. .uno:XXX links
>>>> 3. Links to local files.
>>>>
>>>> I think all 3 are candidates but that's just me.
>>> I have bad news about number 1. Apparently, when the link is indicated
>>> as "#anchor", it is transformed into "file://path/document.ods#anchor"
>>> and then passed to SfxApplication::OpenDocExec_Impl()
>>>
>>> This means that if we want to have warning-less links to the same
>>> document, then we may have to consider the file:// protocol possibly
>>> safe. We should then rely on extensions.
>>>
>>> Suprisingly, the OpenDocument extensions do not seem to be included in
>>> the standard list of safe extensions. Such list should be in
>>> main/officecfg/registry/data/org/openoffice/Office/Security.xcu -- I
>>> cannot recall who brought this to my attention and therefore I am
>>> unable to credit him/her, I am sorry.
>>>
>>> Does anyone see any possible security issues in considering the
>>> file:// protocol safe and deciding on the target file's extension
>>> whether to show a warning or not?
>>
>> I would not go for file://. Can we go for a pattern derivated from
>> file://path/document.ods#anchor ?
>>
>>
>> We had CVEs in the past working with file links, based odf definition and
>> UNO. Maybe you can try the test files from those CVEs.
>>
I think that we should evaluate which protocols are “safe”:
The full list is here:
http://opengrok.openoffice.org/xref/aoo4110/main/tools/inc/tools/urlobj.hxx?r=b1cdbd2c#104
There is this large source file that seems to encode all things to do with a
url:
http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#2080
main/tools/source/fsys/urlobj.cxx has a getPrefix method which returns:
http://opengrok.openoffice.org/xref/aoo4110/main/tools/source/fsys/urlobj.cxx?r=b1cdbd2c#349
348
//============================================================================
349 struct INetURLObject::PrefixInfo
350 {
351 enum Kind { OFFICIAL, INTERNAL, EXTERNAL, ALIAS }; // order is
important!
352
353 sal_Char const * m_pPrefix;
354 sal_Char const * m_pTranslatedPrefix;
355 INetProtocol m_eScheme;
356 Kind m_eKind;
357 };
I wonder if Kind is helpful for what should be trusted?
We are grabbing an INetURLObject here:
http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#929
The code after here
http://opengrok.openoffice.org/xref/aoo4110/main/sfx2/source/appl/appopen.cxx?r=b1cdbd2c#1040
may be helpful.
>
> I think the file protocol as a hyperlink was considered safe by the office
> right up until this fix.
>
> It seems the uno and file protocols were caught up in the fix and are the
> primary ones causing the users problems.
> I don't believe either of these were the subject of the CVE that was fixed so
> I don't think we're harming that one.
>
> I would think we could allow these at least for a test build while also going
> back and verify the previous CVE's didn't get opened up.
>
>
> Just my thoughts.
> Carl
>
> ---------------------------------------------------------------------
> 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
