[liberationtech] Revised Liberationtech Mailing List Guidelines

Seth David Schoen schoen at eff.org
Sat Aug 4 19:17:58 PDT 2012


Greg Norcie writes:

> This is a good logic, but there is still a problem even if Google scans
> uploads.
> 
> Both state and nonstate actors often use zero day vulnerabilities. Since
> a zero day has never been seen before, there is no signature for it in
> any virus database.

This is totally true in general, and of course these zero days have been
used in real attacks, and of course Google can't necessarily recognize
zero-day vulnerabilities.

In the particular case of text documents shared through Google Docs -- as
opposed to Word files hosted for download with some sort of file sharing
site! -- I think malware is a comparatively minor risk.  The reason is that
when you upload a document to Google Docs, Google imports the content of
the document into Google's own internal format.  When you then download a
document from Google Docs, Google is generating _a new document from
scratch_ with the same text and formatting content as the original, but
the result is not the same file that was originally uploaded.

If someone mails you an attachment, or hosts a document file of their own
creation on a web site, your word processor could be compromised if there
are software vulnerabilities that the document exploits, like a buffer
overflow.  And this is also true of, say, a PDF document that you're going
to open in a PDF reader; we know that there have been exploits used in the
wild against PDF readers.

By contrast, if you were to import some Microsoft Word file into Google
Docs and then export the resulting Google Docs document in Microsoft Word
format, what you'd get back would _not_ be the original file or any
modified form of the original file.  Instead, you would get a completely
new Microsoft Word file, generated from scratch by Google, with essentially
the same textual content as the original.  (And if you were to export the
Google Docs document as a PDF, what you'd get would be a PDF that Google
generated from scratch.)

Since these documents are being generated by Google in this way, using
its own internally-developed software, Google will presumably create safe
and valid documents for its users, not ones that contain exploits and
malware.



We might still worry that someone could _upload_ a malicious document to
Google in order to attack Google's import process (and perhaps attack the
Google Docs servers in various ways, whether to disable other security
features or access private information), but I presume Google's security
folks have been very cautious about this aspect and Google Docs import
is probably much less vulnerable to malware and exploits than the file
import features in popular desktop word processors like Microsoft Word,
OpenOffice, and LibreOffice.  (Also, attackers can study the binary code
of Microsoft Word -- as well as Microsoft's security patches to it! --
or the source code of OpenOffice and LibreOffice -- as well as their
developers' security patches to them! -- in order to try to find specific
vulnerabilities.  It's harder for attackers to speculate usefully about
what vulnerabilities may exist in Google Docs import functionality because
the attackers probably don't have access to any of the Google Docs code,
whether source or binary.  So even if there are exploitable vulnerabilities
in the way Google Docs parses documents, it will be much harder for
attackers to find and exploit them than it would be for published desktop
software.)

(How do I square this with my observation that "Google can't necessarily
recognize vulnerabilities"?  I think the main point is that the zero-day
vulnerabilities we're likely to encounter are vulnerabilities in
desktop software.  Google may not be able to detect these, but it may not
be vulnerable to them either!  And with cautious programming, it can also
default to rejecting files that are suspicious in some general ways, even
if it doesn't know exactly what's bad about them.  For instance, Andreas
Bogk gave a talk last year at the CCC Camp about a PDF security scanner
he's been developing which is able to reject several kinds of invalid PDFs
automatically.  Some of those invalid PDFs may be innocent and not contain
any malware or exploits, but Google could still use a scanner like this to
reject them and refuse to import them out of an abundance of caution.)

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107
_______________________________________________
liberationtech mailing list
liberationtech at lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE





More information about the cypherpunks-legacy mailing list