I have discovered a potential DOS attack for all Perl applications which use
DateTime and time zones.
Last July I reported that getting a localized date in the future was very slow.
http://rt.cpan.org/Public/Bug/Display.html?id=47671
$ time perl -wle 'use DateTime; print DateTime->new( year => 3058, time_zone
=> "local" );'
3058-01-01T00:00:00
real 0m7.820s
user 0m7.747s
sys 0m0.047s
At the time this just an oddity of my playing around with y2038 and far future
dates. Later I realized that because DateTime is chewing up CPU and memory
during the calculation this can be used as a DOS attack on a server running
DateTime. A lot of things use DateTime and a lot of things use time zones.
I'll let somebody else get into the details why it happens, but if I can get a
Perl web app to accept a year of, say, 30000 I can get it to consume the CPU
for a few hundred seconds (YMMV) and about 150 megs of memory. If the process
remains in memory subsequent calls will be fast, but the memory will still be
consumed. This provides a very low-bandwidth way to swamp a server using Perl
and DateTime.
Clever watchdogs can prevent this from bringing down a server, but I think we
can all agree that a date library should not be the source of DOS attacks.
I know efficient 64 bit local time calculations are possible because the
standard C library does it. Its not because its written in C, its because its
using a non-O(n) algorithm.
This upgrades the problem from "kooky date wonk problem" to "cross-site attack".
--
Whip me, beat me, make my code compatible with VMS!
