Re: Old/Obsolete file format import still needed?

[Chris Sherlock]

> On 11 Feb 2016, at 9:14 PM, Michael Stahl  wrote:
> 
> but that is just a measure of where white-hat "security researchers"
> have been looking for bugs; i find that the idea that black hats don't
> do their own independent research to find vulnerabilities is wishful
> thinking.

I do wonder what sort of vulnerabilities they find though. Not that in any way 
do I think we should encourage insecure programming or a review of old code 
that has a higher risk attack surface (in particular import code), but I do 
wonder what sort of things they can compromise from within LibreOffice. Of 
course, my imagination is probably not as good as that of top-notch black hat 
crackers. :-)

> serious vulnerabilities are easiest to find in code that is very rarely
> used and almost unknown even to most of the developers of the project,
> but enabled by default; see Heartbleed for an illustrative example.

Closer to home, there were a number of security issues that Microsoft picked up 
due to WMF processing. 

> 
> what i think actually matters is this: if random users get an email with
> a file in FOOBAR format attached to it, does it open in LibreOffice when
> they click on it?
> 
> and how many documents are actually legitimately mailed around in the
> appropriately named "GreatWorks" format?

Isn’t this a problem of the default extensions we associate with via the 
installer though?

Should it be the case that we make folks open LibreOffice, then manually open 
the file? That sort of extra step literally stops people from double-clicking 
on emails - only those who really want to open the file will actually open 
LibreOffice and then use file -> open to access the file.
 
> from that point of view disabling some import filters *does* reduce the
> attack surface.
> 
> (another approach would be to implement the import filters not in a
> glorified portable macro assembler like C++ but in say Java, but i'd be
> accused of trolling and being intolerant of other people's freedom to
> shoot themselves in the foot if i would propose that, so consider it
> more of a theoretical thought experiment.  well at least you and Caolan
> have spent many hours running afl-fuzz, which is the best we can do
> currently.)

Microsoft has handled opening things like .reg files in Outlook by making 
people implement registry keys to get around it. 

I was wondering however, can you currently embed a .MET file into an ODF file 
natively? If you can, then we presumably allow people to open the ODF file 
directly, and then during the load the MET file then invokes import code so we 
have the same issue, only sort of more hidden. 

If this is the case, then I’d still like the import code to exist, but have the 
ability to disable it by default. An option to right click on the image to show 
it would be a nice touch :-) 

Extra work I know, but that’s my 0.02c (which is about 4 cents in AUD).

Chris
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Bjoern Michaelsen]

Hi,

On Thu, Feb 11, 2016 at 11:16:40AM +0100, Michael Stahl wrote:
> i think you misunderstood that this wasn't about "configure" options but
> about "officecfg" runtime configuration.

Right. Assuming the later, it seems like a good thing to me: Makes the
enterprisey sysadmins happy without getting in the way of either devs
(./configure) or endusers (more GUI config).

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Michael Stahl]

On 11.02.2016 07:34, David Tardon wrote:
> Hi,
> 
> On Wed, Feb 10, 2016 at 02:20:50PM -0500, Bryan Quigley wrote:
>>> Anyhow - I share your concern wrt. the attack surface that all these
>>> old file filters provide for us; I attach a prototype patch that adds an
>>> 'EXOTIC' annotation to our filter descriptions. It is missing a UI
>>> Interaction Handler piece (cf. the hole with the notes and so on in
>>> there ;-) - we'll need a new request type I guess.
>>>
>>> My ideal would be to pop up a dialog saying:
>>>
>>> "You're asking LibreOffice to open a very unusual file-type.
>>>  Unless you are certain that this file is indeed a >>  Word Pro> file it is safest to not open it.
>>>
>>>  [ ] - never show this again
>>>
>>>   [ this is an unusual file ] [get me out of here ]"
>>>
>>> Of some kind =) is that something you'd be interested in working on 
>>> ?
>> Thanks for the first pass code.  I generally don't find dialouges like
>> that to be super useful (many users just click right through).
>> However, in labeling them Exotic we could add a configuration option
>> to let system administrators disable them all in one go for a secure
>> site, etc.  I'll look into that more.
> 
> This of course makes the assumption that filters for common formats
> (like .doc etc.) do not contain vulnerabilities, which is IMHO just
> wishful thinking. IIRC there was exactly 1 CVE for import of non-MS file
> format during the ~8 years I have been working on this code base. And I
> think the likelihood to encounter a malformed (or even malicious) MS
> Word document is far greater than, e.g., Hangul Word or AppleWorks
> document. So the "secure site" aspect seems rather dubious to me.

but that is just a measure of where white-hat "security researchers"
have been looking for bugs; i find that the idea that black hats don't
do their own independent research to find vulnerabilities is wishful
thinking.

serious vulnerabilities are easiest to find in code that is very rarely
used and almost unknown even to most of the developers of the project,
but enabled by default; see Heartbleed for an illustrative example.

what i think actually matters is this: if random users get an email with
a file in FOOBAR format attached to it, does it open in LibreOffice when
they click on it?

and how many documents are actually legitimately mailed around in the
appropriately named "GreatWorks" format?

from that point of view disabling some import filters *does* reduce the
attack surface.

(another approach would be to implement the import filters not in a
glorified portable macro assembler like C++ but in say Java, but i'd be
accused of trolling and being intolerant of other people's freedom to
shoot themselves in the foot if i would propose that, so consider it
more of a theoretical thought experiment.  well at least you and Caolan
have spent many hours running afl-fuzz, which is the best we can do
currently.)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Michael Stahl]

On 11.02.2016 07:39, Tor Lillqvist wrote:
> 
> > we could add a configuration option
> 
> We don't need more configuration options.
> 
> > to let system administrators disable them all in one go for a secure
> > site, etc. 
> 
> I think you misunderstand what a typical "system administrator" does,
> for the vast majority of our user base (counting just the part of it
> that even has hired sysadmins). Hint: They don't build software from
> sources.

i think you misunderstood that this wasn't about "configure" options but
about "officecfg" runtime configuration.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Bryan Quigley]

>However if the filter is broken, lack significant features or otherwise call 
>for support, that makes it a candidate for removal.
I'll try to find some more in the wild instances of these formats and
determine just how bad the support is.  OS/2 Metafile was the worst in
my previous testing so I'll look there first.

> As JanI says, cf. the ESC minutes - being the swiss-army-knife of file
> formats that loads ~anything you can throw at it is quite important.

Understood.  Sorry I missed those ESC minutes.

> Anyhow - I share your concern wrt. the attack surface that all these
> old file filters provide for us; I attach a prototype patch that adds an
> 'EXOTIC' annotation to our filter descriptions. It is missing a UI
> Interaction Handler piece (cf. the hole with the notes and so on in
> there ;-) - we'll need a new request type I guess.
>
> My ideal would be to pop up a dialog saying:
>
> "You're asking LibreOffice to open a very unusual file-type.
>  Unless you are certain that this file is indeed a   Word Pro> file it is safest to not open it.
>
>  [ ] - never show this again
>
>   [ this is an unusual file ] [get me out of here ]"
>
> Of some kind =) is that something you'd be interested in working on ?
Thanks for the first pass code.  I generally don't find dialouges like
that to be super useful (many users just click right through).
However, in labeling them Exotic we could add a configuration option
to let system administrators disable them all in one go for a secure
site, etc.  I'll look into that more.

Thanks again both,
Bryan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Michael Meeks]

On Wed, 2016-02-10 at 14:20 -0500, Bryan Quigley wrote:
> Thanks for the first pass code.  I generally don't find dialouges like
> that to be super useful (many users just click right through).

Heh - true; but at least it reduces the severity of any related
security advisory which is pleasant.

> However, in labeling them Exotic we could add a configuration option
> to let system administrators disable them all in one go for a secure
> site, etc.  I'll look into that more.

Right - good thought =) would be easy to do that too; can just
filter[sic] them out of the filter list.

ATB,

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Tor Lillqvist]

> > we could add a configuration option
>

We don't need more configuration options.


> > to let system administrators disable them all in one go for a secure
> > site, etc.


I think you misunderstand what a typical "system administrator" does, for
the vast majority of our user base (counting just the part of it that even
has hired sysadmins). Hint: They don't build software from sources.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[David Tardon]

Hi,

On Wed, Feb 10, 2016 at 02:20:50PM -0500, Bryan Quigley wrote:
> > Anyhow - I share your concern wrt. the attack surface that all these
> > old file filters provide for us; I attach a prototype patch that adds an
> > 'EXOTIC' annotation to our filter descriptions. It is missing a UI
> > Interaction Handler piece (cf. the hole with the notes and so on in
> > there ;-) - we'll need a new request type I guess.
> >
> > My ideal would be to pop up a dialog saying:
> >
> > "You're asking LibreOffice to open a very unusual file-type.
> >  Unless you are certain that this file is indeed a  >  Word Pro> file it is safest to not open it.
> >
> >  [ ] - never show this again
> >
> >   [ this is an unusual file ] [get me out of here ]"
> >
> > Of some kind =) is that something you'd be interested in working on 
> > ?
> Thanks for the first pass code.  I generally don't find dialouges like
> that to be super useful (many users just click right through).
> However, in labeling them Exotic we could add a configuration option
> to let system administrators disable them all in one go for a secure
> site, etc.  I'll look into that more.

This of course makes the assumption that filters for common formats
(like .doc etc.) do not contain vulnerabilities, which is IMHO just
wishful thinking. IIRC there was exactly 1 CVE for import of non-MS file
format during the ~8 years I have been working on this code base. And I
think the likelihood to encounter a malformed (or even malicious) MS
Word document is far greater than, e.g., Hangul Word or AppleWorks
document. So the "secure site" aspect seems rather dubious to me.

Not to mention that users/admins in different countries (or even in
different professions) may have different ideas about which formats
should be considered "exotic".

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Old/Obsolete file format import still needed?

[Michael Meeks]

Hi Bryan,

On Tue, 2016-02-09 at 01:38 -0500, Bryan Quigley wrote:
> While working on the easyhack[1] to remove export of obsolete formats

Its prolly a good idea to close that easy-hack ;-)

> There also might be a security benefit by not having to
> consider these formats (less import code to harden).

As JanI says, cf. the ESC minutes - being the swiss-army-knife of file
formats that loads ~anything you can throw at it is quite important.

> P.S. Please copy me on replies.

Hopefully the list is configured to do that ;-)

Anyhow - I share your concern wrt. the attack surface that all these
old file filters provide for us; I attach a prototype patch that adds an
'EXOTIC' annotation to our filter descriptions. It is missing a UI
Interaction Handler piece (cf. the hole with the notes and so on in
there ;-) - we'll need a new request type I guess.

My ideal would be to pop up a dialog saying:

"You're asking LibreOffice to open a very unusual file-type.
 Unless you are certain that this file is indeed a  file it is safest to not open it.

 [ ] - never show this again

  [ this is an unusual file ] [get me out of here ]"

Of some kind =) is that something you'd be interested in working on ?

All the best,

Michael.

-- 
 michael.me...@collabora.com  <><, Pseudo Engineer, itinerant idiot
From 637f57758b1bb4b951fb48cc49fe5071f9533953 Mon Sep 17 00:00:00 2001
From: Michael Meeks 
Date: Wed, 25 Feb 2015 15:07:19 +
Subject: [PATCH] First cut at annotating 'exotic' filters.

The idea being that we can improve security by warning for these.

Change-Id: I7d993417bfb6a8fe868bc3e07ccbcfe71bf285ff
---
 filter/source/config/cache/constant.hxx| 2 ++
 filter/source/config/cache/filtercache.cxx | 6 ++
 filter/source/config/fragments/filters/AbiWord.xcu | 2 +-
 filter/source/config/fragments/filters/StarOffice_XML__Base_.xcu   | 2 +-
 filter/source/config/fragments/filters/StarOffice_XML__Writer_.xcu | 2 +-
 filter/source/config/fragments/filters/T602Document.xcu| 2 +-
 filter/source/config/fragments/filters/XPM.xcu | 2 +-
 filter/source/config/fragments/filters/writer_MIZI_Hwp_97.xcu  | 2 +-
 include/comphelper/documentconstants.hxx   | 2 ++
 include/sfx2/docfilt.hxx   | 3 +++
 10 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/filter/source/config/cache/constant.hxx b/filter/source/config/cache/constant.hxx
index 98327f0..f21ee55 100644
--- a/filter/source/config/cache/constant.hxx
+++ b/filter/source/config/cache/constant.hxx
@@ -124,6 +124,7 @@
 #define  FLAGNAME_TEMPLATEPATH  "TEMPLATEPATH"
 #define  FLAGNAME_USESOPTIONS   "USESOPTIONS"
 #define  FLAGNAME_COMBINED  "COMBINED"
+#define  FLAGNAME_EXOTIC"EXOTIC"
 
 /** @short  values of filter flags, sorted based on value */
 #define  FLAGVAL_IMPORT0x0001 // 1
@@ -144,6 +145,7 @@
 #define  FLAGVAL_CONSULTSERVICE0x0004 // 262144
 #define  FLAGVAL_3RDPARTYFILTER0x0008 // 524288
 #define  FLAGVAL_PACKED0x0010 // 1048576
+#define  FLAGVAL_EXOTIC0x0020 // 2097152
 #define  FLAGVAL_BROWSERPREFERRED  0x0040 // 4194304
 #define  FLAGVAL_COMBINED  0x0080 // 8388608
 #define  FLAGVAL_ENCRYPTION0x0100 // 16777216
diff --git a/filter/source/config/cache/filtercache.cxx b/filter/source/config/cache/filtercache.cxx
index 18115e4..06071bbc 100644
--- a/filter/source/config/cache/filtercache.cxx
+++ b/filter/source/config/cache/filtercache.cxx
@@ -1920,6 +1920,7 @@ css::uno::Sequence< OUString > FilterCache::impl_convertFlagField2FlagNames(sal_
 if ((nFlags & FLAGVAL_CONSULTSERVICE   ) == FLAGVAL_CONSULTSERVICE   ) lFlagNames.push_back(FLAGNAME_CONSULTSERVICE   );
 if ((nFlags & FLAGVAL_DEFAULT  ) == FLAGVAL_DEFAULT  ) lFlagNames.push_back(FLAGNAME_DEFAULT  );
 if ((nFlags & FLAGVAL_ENCRYPTION   ) == FLAGVAL_ENCRYPTION   ) lFlagNames.push_back(FLAGNAME_ENCRYPTION   );
+if ((nFlags & FLAGVAL_EXOTIC   ) == FLAGVAL_EXOTIC   ) lFlagNames.push_back(FLAGNAME_EXOTIC   );
 if ((nFlags & FLAGVAL_EXPORT   ) == FLAGVAL_EXPORT   ) lFlagNames.push_back(FLAGNAME_EXPORT   );
 if ((nFlags & FLAGVAL_IMPORT   ) == FLAGVAL_IMPORT   ) lFlagNames.push_back(FLAGNAME_IMPORT   );
 if ((nFlags & FLAGVAL_INTERNAL ) == FLAGVAL_INTERNAL ) lFlagNames.push_back(FLAGNAME_INTERNAL );
@@ -1992,6 +1993,11 @@ sal_Int32 FilterCache::impl_convertFlagNames2FlagField(const css::uno::Sequence<
 nField |= FLAGVAL_EXPORT;
 continue;
 }
+if (pNames[i] == FLAGNAME_EXOTIC)
+{
+

Re: Old/Obsolete file format import still needed?

[jan iversen]

Hi

We discussed this in general at the ESC meeting a while ago, and I believe the 
general concensus was not to remove filters that works and thereby cause no 
extra support.

Reason was that there might still be users out there having reasons for using 
these filters.

However if the filter is broken, lack significant features or otherwise call 
for support, that makes it a candidate for removal.

I have no opinion on the filters you list, and hope others have more knowledge 
on the status.

rgds
jan i.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Old/Obsolete file format import still needed?

[Bryan Quigley]

Hi all,

While working on the easyhack[1] to remove export of obsolete formats
I came across a few that I think we might want to drop import support
from as well. I cam across them again recently looking at another
cleanup bug[2].

They are:
Mac Pict (obsolete since Mac OS X)
https://en.wikipedia.org/wiki/PICT

PBM,PGM,PPM
From their website (below) there might be some users who still like
using this file format. But given the likely user I'm guessing they
will all just manually use ppmtojpeg to make it a jpeg before
importing into LibreOffice.
https://en.wikipedia.org/wiki/Netpbm_format
http://netpbm.sourceforge.net/doc/#formats

OS/2 Metafile (.MET)
Known bug - With MET files you can not export them as an image (a
different filetype) using "Save as image".  You can still export a new
image by saving the whole document.

In most cases I would expect a dedicated image program to be able to
do a better job with the above.   I was hoping to get some usage
statistics about these formats, but haven't found any (suggestions
welcome).  There also might be a security benefit by not having to
consider these formats (less import code to harden).

Thoughts?
Bryan

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=92925
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=38844

P.S. Please copy me on replies.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice