Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index



On 11 Feb 2016, at 9:14 PM, Michael Stahl <mstahl@redhat.com> 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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.