[ ijbswa-Bugs-3403560 ] session-cookies-only and expires with a two digit year

Bugs item #3403560, was opened at 2011-09-03 04:49
Message generated for change (Comment added) made by vah78
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=3403560&group_id=11118

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: version 3.0.17
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Väinö (vah78)
Assigned to: Fabian Keil (fabiankeil)
Summary: session-cookies-only and expires with a two digit year

Initial Comment:
I noticed that if cookie's expires date has a two digit year, the expires date is not removed, and thus, the cookies are not converted to session only cookies.

For example, if a server sets these headers:
Set-Cookie: test1=37; expires=Tue, 02-Jun-37 20:00:00 GMT
Set-Cookie: test2=2037; expires=Tue, 02-Jun-2037 20:00:00 GMT

They will come trough Privoxy with session-cookies-only enabled as:
Set-Cookie: test1=37; expires=Tue, 02-Jun-37 20:00:00 GMT
Set-Cookie: test2=2037;

I believe the problem is in the parse_header_time() function (in parsetime.c). It uses strptime() which will parse the two digit year incorrectly and gmt.tm_year will become negative (-1863). This will cause the rest of the logic to believe that the date is in the past and the server wants to delete the cookie.

A possible fix is to reorder the strptime() calls to try the two digit year format first. Or the function could be hacked to give correct results by adding 2000 to tm_year if it is negative. It might be a bit faster to keep the most often used date format at the top but it would be ugly.

If you want to see such a cookie in the wild, you can try this but I'm sure there are other examples:
% curl -I www.mtv3.fi

I'm using 64-bit Linux (Debian and Arch) in case the strptime() functions differently in other platforms. My Privoxy is version 3.0.17 from Debian repositories. I also downloaded the lastest stable source directly from sf.net for finding where the bug is.

----------------------------------------------------------------------

>Comment By: Väinö (vah78)
Date: 2011-09-03 15:35

Message:
The problem is that format with %Y will also "successfully" parse the year
as literally 37 (not 2037) and we will get wrong result because it is tried
first.

Here is a tiny test program:

#include <stdio.h>
#include <string.h>
#include <time.h>

int main(void)
{
  const char *date = "Tue, 02-Jun-37 20:00:00";
  struct tm gmt;

  memset(&gmt, 0, sizeof gmt);

  if(strptime(date, "%a, %d-%b-%y %H:%M:%S", &gmt)) {
    printf("%%y => %d, %s\n", gmt.tm_year, asctime(&gmt));
  }

  if(strptime(date, "%a, %d-%b-%Y %H:%M:%S", &gmt)) {
    printf("%%Y => %d, %s\n", gmt.tm_year, asctime(&gmt));
  }

  return 0;
}

Both strptime() will succeed and this prints:
%y => 137, Tue Jun  2 20:00:00 2037

%Y => -1863, Tue Jun  2 20:00:00 37

The format with %y fails if we change the date to 02-Jun-2037 and,
obviously, %Y will then produce the correct result.

----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2011-09-03 13:03

Message:
Thanks a lot for the detailed report.

I can't reproduce the problem using FreeBSD 9.0. Quoting its strptime(3):

| Two-digit year values, including formats %y and %D, are now
| interpreted as beginning at 1969 per POSIX requirements. 
| Years 69-00 are interpreted in the 20th century (1969-2000),
| years 01-68 in the 21st century (2001-2068).

Apparently the GNU libc behavior for %y is similar, except that it's
undefined for some input data:
| The strptime function does regard input values in the range 68 to 99
| as the years 1969 to 1999 and the values 0 to 68 as the years 2000
| to 2068. But maybe this heuristic fails for some input data. 
http://www.gnu.org/s/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html

parse_header_time() is not a hot code path, so the strptime() call
ordering
shouldn't matter that much, however I'm not sure why checking for two
digit
years first should work around this glibc issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=3403560&group_id=11118

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Ijbswa-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers