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@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@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