[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUAZEte8JS8GrVOzaC4_Uh39faqwEYMSJP0EfCfkGdLkWg@mail.gmail.com>
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/
Powered by blists - more mailing lists