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

There is this large source file that seems to encode all things to do with a 

main/tools/source/fsys/urlobj.cxx has a getPrefix method which returns:

349  struct INetURLObject::PrefixInfo
350  {
351     enum Kind { OFFICIAL, INTERNAL, EXTERNAL, ALIAS }; // order is 
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:

The code after here 
 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

Reply via email to