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  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 <>
To: Krzysztof Kotowicz <>
Cc: full-disclosure <>,
 "Nicholas Lemonias." <>
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.


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists