> On 11 Feb 2016, at 9:14 PM, Michael Stahl <mst...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
