[J. Wunsch: hey (fwd)]

Garrett Wollman wollman at lcs.mit.edu
Mon Jan 13 16:51:26 UTC 1997


<<On Fri, 10 Jan 1997 15:38:45 -0800, Paul Eggert <eggert at twinsun.com> said:

> report is too sketchy to see what the problem might be.  I could not
> reproduce it with the elsie localtime.c under Solaris 2.5.1.

Here is a typescript which demonstrates it...

root at khavrinen(31)# TZ=/etc/master.passwd gdb obj/date
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd2.2), 
Copyright 1996 Free Software Foundation, Inc...
(gdb) br main
Breakpoint 1 at 0x119c: file /usr/wd1/src/bin/date/date.c, line 83.
(gdb) run
Starting program: /usr/wd1/src/bin/date/obj/date 

Breakpoint 1, main (argc=1, argv=0xefbfd8a8) at /usr/wd1/src/bin/date/date.c:83
83              (void) setlocale(LC_TIME, "");
[deletia]
(gdb) n
144             (void)strftime(buf, sizeof(buf), format, localtime(&tval));
(gdb) br localtime
Breakpoint 2 at 0x139ab: file /usr/wd1/src/lib/libc/stdtime/localtime.c, line 1125.
(gdb) cont
Continuing.

Breakpoint 2, localtime (timep=0x28534)
    at /usr/wd1/src/lib/libc/stdtime/localtime.c:1125
1125            tzset();
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x1293d in settzname () at /usr/wd1/src/lib/libc/stdtime/localtime.c:241
241                     tzname[ttisp->tt_isdst] =
(gdb) bt
#0  0x1293d in settzname () at /usr/wd1/src/lib/libc/stdtime/localtime.c:241
#1  0x138e1 in tzset () at /usr/wd1/src/lib/libc/stdtime/localtime.c:1010
#2  0x139b0 in localtime (timep=0x28534)
    at /usr/wd1/src/lib/libc/stdtime/localtime.c:1125
#3  0x139a in main (argc=1, argv=0xefbfd8a8)
    at /usr/wd1/src/bin/date/date.c:144
(gdb) 

`ttisp' appears to point off into nowhere land... `lclmem' contains
the following data:

$2 = {leapcnt = 0x726f6f74, timecnt = 0x206f6e20, typecnt = 0x6b686176, 
  charcnt = 0x72696e65, ats = {0x0 <repeats 370 times>}, types = {
    0x0 <repeats 370 times>}, ttis = {{tt_gmtoff = 0x0, tt_isdst = 0x0, 
      tt_abbrind = 0x0, tt_ttisstd = 0x0, 
      tt_ttisgmt = 0x0} <repeats 256 times>}, chars = {
    0x0 <repeats 512 times>}, lsis = {{ls_trans = 0x0, 
      ls_corr = 0x0} <repeats 50 times>}}

...which manifestly makes no sense whatsoever.

> 	* The FreeBSD edition refuses to read a timezone file if it is
> 	  not a regular file.  (I don't know why this restriction is
> 	  needed.)

As I look in the problem-report database, it is clear that this change
results from a previous attempt at dealing with the same bug.  The
description from our PR#1740 is:

>Description:
Setting TZ to unusual values like "Europe" crashes all applications
using the localtime routine. This is because the tzload routine
happily opens any file, even directories, as valid timezone files.
"Europe" happens to be a directory under /usr/share/zoneinfo.
>How-To-Repeat:
TZ=Europe date

> Perhaps the bug is in the FreeBSD mutex handling.

Unlikely, since neither the reporters in question nor I am using the
thread-safe version of libc.

>    From: Adam Kubicki <mikee at solozzo.tele.pw.edu.pl>
>    Date: Thu, 09 Jan 1997 23:02:44 MET

>    And, setting TZ to /etc/master.passwd you will find whole master.passwd
>    in core file (touch login.core first to fool default umask/owner core 
>    flags).

> I presume that /etc/master.password is not supposed to be readable to
> ordinary users.  That's odd.  In both elsie tz and FreeBSD-current,
> tzload uses access() as well as open() to check whether the file is
> readable.  There is of course a window of vulnerability here, but it
> doesn't sound like Kubicki is trying to exploit it.

Recall that the `login' program prints out the time of last login.
Because it has previously opened the password database, that data may
still be floating around its memory image, and thus would be stored in
the core file even though it is created after login has switched to
the user's ID.  I don't think that this bug is still present;
writecore() should refuse to operate if the process's P_SUGID flag is
set, which is supposed to happen any time setuid(2) or setgid(2) is
successful.  It is possible to use the TELNET Environment Variable
option to pass a bogus TZ variable to the login process on the other
end.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman at lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, ANA, or NSA|                     - Susan Aglukark and Chad Irschick



More information about the tz mailing list