mod_rewrite/4963: Multiple time variables can expand incorrectly in a URL rewrite.

[Jeff Barry <je...@world.std.com>]

>Number:         4963
>Category:       mod_rewrite
>Synopsis:       Multiple time variables can expand incorrectly in a URL rewrite.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sun Sep  5 20:00:01 PDT 1999
>Last-Modified:
>Originator:     jeff@world.std.com
>Organization:
apache
>Release:        from 1.2 to latest
>Environment:
Any environment where URL rewrites are going on and those rewrites
involve the expansion of time variables.
>Description:
Hi,

While analyzing the Apache 1.2.6 source code for Y2K bugs I found 
a bug which CAN (but won't necessarily) occur at the end of any 
minute including, therefore, critical Y2K rollovers.  My estimation 
is that the probability of the bug having an effect is very low, 
but it is still greater than zero.  It only affects URL rewrites 
which include time variables, but over the fullness of time....  

This bug can appear to make time run backwards and create impossible 
dates, eg Saturday, 5-Sep-99.  What the effect on the application 
attempting to use the rewritten URL would be is, of course, 
application dependent.

Here is a FRAGMENT of the offending code to give you an idea of 
what it does.  I had to reformat it since my eMail decided to 
concatenate it all....

=======================================================================

#define MKTIMESTR(format, tmfield) \
    tc = time(NULL); \
    tm = localtime(&tc); \
    ap_snprintf(resultbuf, sizeof(resultbuf), format, tm->tmfield); \
    result = resultbuf;

else if (strcasecmp(var, "TIME_MON") == 0) 
     { MKTIMESTR("%02d", tm_mon+1) } 
else if (strcasecmp(var, "TIME_DAY") == 0) 
     { MKTIMESTR("%02d", tm_mday) } 
else if (strcasecmp(var, "TIME_HOUR") == 0) 
     { MKTIMESTR("%02d", tm_hour) }
else if (strcasecmp(var, "TIME_MIN") == 0) 
     { MKTIMESTR("%02d", tm_min) } 
else if (strcasecmp(var, "TIME_SEC") == 0)
     { MKTIMESTR("%02d", tm_sec) } 
else if (strcasecmp(var, "TIME_WDAY") == 0) 
     { MKTIMESTR("%d", tm_wday) }
. . .
=======================================================================

The function containing the above code fragment, lookup_variable() in 
mod_rewrite.c, is called once for every variable expansion within a URL 
rewrite.  If N > 1 time variables are expanded within one URL rewrite 
then the time() and localtime() within the MKTIMESTR macro will be 
executed N times.  Aside from inefficiency it means that one of those 
time() calls could potentially be in a minute, hour, day, month, year, 
century or millennium later than the preceding time() call, and the 
result will therefore be mixed date and/or time components within that 
one URL rewrite. The bug can be provoked at the end of any minute, 
depending on the specifics of the URL rewrite and bad luck.

This function is local to the module, so the bug can only occur 
during URL rewrites.  I checked and this bug also exists in the latest 
Apache sources (1.3.9). I would not expect URL rewrites in intervening 
or earlier versions to be correct.

Jeff Barry
jeff@world.std.com
>How-To-Repeat:
By creating a URL rewrite which expands and depends upon multiple 
time variables, including seconds and minutes, and then exercising
that rewrite at the end of every minute.  It is more likely to occur
if the system is heavily loaded and/or the rewrite is doing something
which interrupts the server process between expansion of time variables.

Best to just look at the code.
>Fix:
Capture the time ONCE at the start of each URL rewrite and use that
time for that entire rewrite.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]