On Tue, Dec 15, 2009 at 4:54 PM, Michael G Schwern <schw...@pobox.com> wrote: > > 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!
Hi Schwern, What you've mentioned is actually in the DateTime pod in the "Time Zone Warnings" section: http://search.cpan.org/~drolsky/DateTime-0.53/lib/DateTime.pm#Time_Zone_Warnings Applicable snippet: Do not try to use named time zones (like "America/Chicago") with dates very far in the future (thousands of years). The current implementation ofDateTime::TimeZone will use a huge amount of memory calculating all the DST changes from now until the future date. Use UTC or the floating time zone and you will be safe. -J -- J. Shirley :: jshir...@gmail.com :: Killing two stones with one bird. http://our.coldhardcode.com/jshirley/
