[Secure-testing-team] Bug#856635: apt-cacher-ng: amplified remote disk space exhaustion on filesystems that support fallocate

[Helmut Grohne]

Package: apt-cacher-ng
Version: 0.4.1
Severity: important
Tags: security

Summary
-------

I accidentally stumbled into what I believe to be a pretty bad denial of
service vulnerability in apt-cacher-ng. If an attacker is able to issue
http requests to apt-cacher-ng and apt-cacher-ng stores its data on a
filesystem that supports fallocate, then the attacker is able to consume
disk space with an amplification factor of ~10000 (observed) over what
he is downloading from apt-cacher-ng. A http request of 1 KB can fill 1
GB of disk space.

I acknowledge that an attacker able to issue http requests to
apt-cacher-ng can fill its disk by design. However, this particular
issue is concerned with the amplification factor that may be unexpected
by its users.

Details
-------

apt-cacher-ng tries to be a nice citizen and tells the filesystem about
its expected space requirements using fallocate. Thus filesystems
allocate blocks in advance and these are marked as consumed. Now an
attacker can abort the download after seeing a few bytes. apt-cacher-ng
notices the broken connection and likewise closes its upstream request.
Then it closes the cached file and leaves a .deb with a very small
total size (roughly the amount downloaded by the attacker) and a very
large number of blocks (roughly the amount needed for storing the full
.deb). By choosing a few very large .debs (and we have some that are
over 1 GB), the attacker can quickly fill the filesystem.

Mitigation
----------

The attack scenario can be significantly weakened if excess space is
returned upon closing (partially) downloaded files. Thus the attack
would no longer persist. Space would only be allocated for the duration
of the http request, putting more effort on the attacker. According to
man 2 fallocate, excess space can be returned by truncating files. I
guess that adding a suitable truncation to the fileitem destructor would
be sufficient already. Simply observing its actual size and truncating
to that size should work.

If you happen to be hit by such an attack the following command can be
used to reclaim space:

    find /var/cache/apt-cacher-ng/ -type f -printf "%b %s %p\n" |
    while read b s p; do
        test $b -gt $((s / 512 + 20)) || continue
        truncate --size $s "$p"
    done

Disclosure timeline
-------------------

Since the impact of the vulnerability is limited (its only DoS after
all) and apt-cacher-ng is likely used in access-limited environments, no
attempt at reporting it confidentially has been made. This is my first
public report about it. No CVE is allocated at the time of this writing.

Helmut