Re: Fwd: Google vulnerabilities with PoC

[Michal Zalewski <lcamtuf () coredump cx>]

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/