bug#79705: denial of service bug in date(1)

Hi Jeff,

"Jeff Epler" <[email protected]> writes:

> It is possible to specify a date format string that will produce truly unreasonable amounts of output:
>
> $ date +`python -c 'print("%2147483648c" * 10000)'`
>
> (the format string here is 10,000 repetitions of "%2147483648c"). This
> will produce around 20,000GiB of output (20TiB). On my system,
> producing 10 repetitions takes 33 seconds, so the full 10,000 would
> take about 9 hours. A repetition factor of 11000 did not work on my
> system due to the operating system limitation on the total size of
> arguments.

I wouldn't consider it a denial of service. It can be easily
interrupted by a signal, such as a SIGPIPE:

   $ date +`python -c 'print("%2147483648c" * 10000)'` \
       | head -c 1 | wc -c
   1

If we used strtftime that would mean allocating 20TiB of memory and
then storing the resulting string, which would be a problem. However, we
use fprintftime which turns each individual format specifier into a
string and then prints it.

If someone wanted to redirect it to a file to fill your disks, they
could choose much quicker method:

    $ timeout 5 dd bs=`getconf PAGE_SIZE` if=/dev/zero of=dd-output \
        status=none
    $ timeout 5 date +`python -c 'print("%2147483648c" * 10000)'` \
        > date-output
    $ ls -la --human-readable dd-output date-output
    -rw-r--r--. 1 collin collin 1.5G Oct 26 23:15 date-output
    -rw-r--r--. 1 collin collin 3.0G Oct 26 23:14 dd-output

> I noticed that another implementation of time (uutils) caps the field
> width of any given "resource specifier" at 255 characters, meaning
> that the biggest length of output is probably under 10MiB (but still a
> non trivial amount of output)

I would consider that a bug in that implementation (albeit low
importance). As Paul mentioned, we try to avoid arbitrary limits.

Thanks,
Collin