Return-Path: Delivered-To: apache-bugdb-archive@hyperreal.org Received: (qmail 28591 invoked by uid 6000); 6 Sep 1999 03:00:04 -0000 Received: (qmail 28568 invoked by uid 2001); 6 Sep 1999 03:00:01 -0000 Received: (qmail 22826 invoked by uid 2012); 6 Sep 1999 02:51:00 -0000 Message-Id: <19990906025100.22825.qmail@hyperreal.org> Date: 6 Sep 1999 02:51:00 -0000 From: Jeff Barry Reply-To: jeff@world.std.com To: apbugs@hyperreal.org X-Send-Pr-Version: 3.2 Subject: mod_rewrite/4963: Multiple time variables can expand incorrectly in a URL rewrite. Sender: apache-bugdb-owner@apache.org Precedence: bulk >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 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! ]