libwww integer truncation error leads to bad behavior, segfault

Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

libwww integer truncation error leads to bad behavior, segfault

Will Dietz
Hi all,

While doing research on integer overflows in software I encountered
the following issue with libwww related to the way it represents time
on 32bit systems:

Normal behavior:

$ sudo date -s "Sat Jun  1 09:50:20 2013"; install/bin/w3c http://localhost
Sat Jun  1 09:50:20 EDT 2013
Looking up localhost
Looking up localhost
Contacting localhost
Fatal Error: connect operation failed (Connection refused)

Triggering the bug:

$ sudo date -s "Sat Jun  1 09:49:20 2013"; install/bin/w3c http://localhost
Sat Jun  1 09:49:20 EDT 2013
Looking up localhost
Looking up localhost
Contacting localhost
Segmentation fault

The underlying issue is that w3c tracks time as
milliseconds-since-epoch but on 32bit systems stores that value in a
32bit integer.  Quick math suggests this means every 50 days time
wraps, which is the cause of the failure shown above.  It's likely
there are other issues related to timing bugs when time unexpectedly
wraps.  This seems moderately important as it means w3c has a chance
to fail or other act incorrectly once every 50 days.

The suggested solution is to simply always use a 64bit value for
representing time.

I have a shim library implementation of gettimeofday() that can be
used with LD_PRELOAD to cause this and related timing bugs without
having to play with the system time.  I've thrown this up on github in
case this is useful to someone[1].

Please let me know if you need more information or have any questions.

Thanks,

~Will

[1] https://github.com/dtzWill/gtod-shim