Dear All, I'll attempt a multi-level reply here :-)
On Sat, May 29, 2021 at 12:26:52PM -0700, Dave Fisher wrote: > > 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 ? I am not sure I understand your question, Peter. > >> 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. Ok. I will look for them. > 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 Yes Dave, I believe that this is an important question. > 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? It seems to me, that Kind is used to distinguish between ``official'' prefixes, like "http", that anyone should know, from other prefixes, specific to AOO. > 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 do not seem to be able to open your links, sorry... Now to Carl: > > I think the file protocol as a hyperlink was considered safe by > > the office right up until this fix. Yes, there were no checks. We (re-)enabled them in AOO 4.1.10. > > It seems the uno and file protocols were caught up in the fix and are the > > primary ones causing the users problems. Correct. > > 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. Well, the title of the latest CVE was about "non-http(s) schemes". So it did include file:// links. But let's remember that there were no checks on the target file's extension! > > 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. Please see branch bug128453, just pushed. I will look for older CVE's in the next days. I hope this helps. Best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
