<<On Fri, 10 Jan 1997 15:38:45 -0800, Paul Eggert <eggert@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@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@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@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