Arch Linux

We can also access the uncompressed size of a gzip'ed file directly via PHP (it's like 4-5 lines of code). The problem is that the size is only stored in a 4 byte integer, so it's actually the uncompressed size modulo 2^32. Just tested that with `dd if=/dev/zero bs=1048576 count=4096 of=foo; gzip foo`. After that, `gzip -l foo` reports a uncompressed size of 0 bytes and a compression ratio of 0%.

That means our check will be easy to bypass by just using source files with a total size of 2^32 * m + n (m being a natural number and n being very small).

So we have a few red flags we can look for:
* Uncompressed size zero.
* Compressed size significantly larger than uncompressed size.
* Compression ratio less than or equal to zero.

Well... I noticed that my 4GiB test file has a compressed size of about 4.0MiB. As it's only a bunch of 0-bytes from "/dev/zero", my guess is that DEFLATE has a best case compression ratio of about 1/1000 (haven't proved that). So how about just having two settings "$MAX_FILESIZE" and "$MAX_FILESIZE_UNCOMPRESSED" and setting "$MAX_FILESIZE" to something below 2-3MiB? That way, we could really ensure that there won't be any source packages that have a uncompressed size of more than "$MAX_FILESIZE_UNCOMPRESSED" (keeping that value below 4GiB, of course) without using any weird heuristics.

I also traversed the whole incoming package directory of our official AUR setup and there isn't a single tarball that's bigger than 2MiB, so that should be fine.

Yes, the red flags Loui spoke of are not enough:
"dd if=/dev/zero bs=1048576 count=4100 of=foo; gzip foo"
gives:
compressed uncompressed ratio uncompressed_name
4172243 4194304 0.5% foo
We have a 4MB compressed archive with an apparent uncompressed size slightly larger and thus a compression ratio above zero.

What about doing something like "gunzip -c" piped into a dd with a count of the compressed size? If the compressed file is a "normal" file, it will works fine. If the compressed file is malicious, it will be limited to a reasonable size (configurable).

Xdark: Uncompressing parts of the tarball would be vulnerable to DoS, again. I think having both compressed and uncompressed file size limits is the best way to go.

I noticed that "upload_max_filesize" defaults to "2M" for current PHP releases, so it might be sufficient to have a uncompressed file size limit in "web/lib/config.inc" and some comment about keeping "upload_max_filesize" below 3MiB to have real protection. Any objections?

Any suggestions for a reasonable uncompressed file size limit? 4MiB? 8MiB? 32MiB? 128MiB?

Implemented [1].

[1] http://projects.archlinux.org/aur.git/commit/?id=09d8128f99c2edc27dd81efc63e9b3c797603ca1