full-disclosure - Re: Fwd: Google vulnerabilities with PoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 14 Mar 2014 21:05:22 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: Krzysztof Kotowicz <kkotowicz+fd@...il.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
 "Nicholas Lemonias." <lem.nikolas@...glemail.com>
Subject: Re: Fwd: Google vulnerabilities with PoC

Oh, wow :-)

To put things in perspective, it probably helps to understand that
virtually all video hosting sites perform batch, queue-based
conversions of uploaded content. There is a good reason for this
design: video conversions are extremely CPU-intensive - and an
orderly, capped-throughput queue gives you much better resilience to
DoS attacks.

Alas, this model is not very user-friendly: it may take good 20
minutes to upload a clip to Vimeo over my lowly DSL connection, and
then another 40 to wait my turn in the conversion queue. If the video
I uploaded turns out to be in an unsupported format (I'm still using
MS-CRAM), I have just wasted an hour of my time. A simple workaround
would be for Vimeo to have a client-side check that flags obvious
problems before sending any data to the server. It's not a security
feature, but it minimizes my pain.

Does it make sense to duplicate this check on the server, too? You
could, but I don't think it adds real value: after all, the converter
will sooner or later perform the same check anyway. And for users who
want to take Vimeo down, uploading tons of cat videos makes more
sense: after all, converting them will cost more than just bailing out
early on an invalid file. As for other attacks you mention: it's
fairly easy to construct valid videos that also work as file archives,
HTML documents, or shell scripts.

Ultimately, sites that deal with user-supplied content often have to
make tough decisions that don't fit in the neat defitions of ISO
standards or academic papers of the old. Mechanisms such as quotas,
various abuse-detection heuristics, rapid scalability - and even user
education and good UX design - go hand-in-hand with more traditional
approaches to minimizing risk.

/mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/