From owner-freebsd-security-notifications Mon Nov 13 15:55: 7 2000 Delivered-To: freebsd-security-notifications@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B39D637B479; Mon, 13 Nov 2000 15:54:53 -0800 (PST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory: FreeBSD-SA-00:68.ncurses Message-Id: <20001113235453.B39D637B479@hub.freebsd.org> Date: Mon, 13 Nov 2000 15:54:53 -0800 (PST) Sender: owner-freebsd-security-notifications@FreeBSD.ORG Precedence: bulk Reply-To: postmaster@freebsd.org X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:68 Security Advisory FreeBSD, Inc. Topic: ncurses allows local privilege escalation Category: core Module: ncurses Announced: 2000-11-13 Affects: FreeBSD 5.0-CURRENT, 4.x prior to the correction date. FreeBSD 3.x vulnerability status currently unconfirmed. Corrected: 2000-10-11 (FreeBSD 4.1.1-STABLE) Credits: Jouko Pynnonen FreeBSD only: NO I. Background ncurses is a text-mode display library used for formatting the output of applications on a variety of terminals. It is externally maintained, contributed code which is included in FreeBSD by default. II. Problem Description There exists an overflowable buffer in the libncurses library in the processing of cursor movement capabilities. An attacker can force a privileged application to use the attacker's termcap file containing a specially crafted terminal entry, which will trigger the vulnerability when the vulnerable ncurses code is called. This allows them to execute arbitrary code on the local system with the privileges of the exploited binary. The systat utility included in the FreeBSD base system is known to use vulnerable ncurses routines. It runs with increased privileges as a member of the kmem group, which allows it to read from kernel memory (but not write to it). A process with the ability to read from kernel memory can monitor privileged data such as network traffic, disk buffers and terminal activity, and may be able to leverage this to obtain further privileges on the local system or on other systems, including root privileges. There may be other vulnerable applications included in the FreeBSD 4.x base system, but no others are confirmed to be vulnerable due to the difficulty in identifying a complete list of vulnerable ncurses functions. However the following is a complete list of FreeBSD system binaries which link against ncurses and run with increased privileges. They may or may not be vulnerable to exploitation. /usr/sbin/lpc /usr/bin/top /usr/bin/systat FreeBSD 3.x and earlier versions use a very old, customized version of ncurses which is difficult to update without breaking backwards-compatibility. The update was made for FreeBSD 4.0, but 3.x will not be updated to the newer version. At this stage the vulnerability has not been confirmed in FreeBSD 3.x. III. Impact Certain setuid/setgid software (including FreeBSD base system utilities and third party ports/packages) may be vulnerable to a local exploit yielding privileged access. The /usr/bin/systat utility is known to be vulnerable to this problem in ncurses. At this time is unknown whether /usr/bin/top and /usr/sbin/lpc are also affected. The problems were corrected prior to the release of FreeBSD 4.2. IV. Workaround It is not feasible to reliably detect binaries which are vulnerable to the ncurses vulnerability, however the provided utility will scan for privileged binaries which use ncurses and which may potentially be vulnerable. Some of the binaries reported may not in fact be vulnerable, but should be recompiled anyway for maximum assurance of security. Statically linked binaries which are identified as potentially vulnerable should be recompiled from source code if possible, after patching and recompiling libncurses, in order to correct the vulnerability. Dynamically linked binaries will be corrected by simply patching and recompiling libncurses as described below. As an interim measure, consider removing any identified setuid or setgid binary, removing set[ug]id privileges from the file, or limiting the file access permissions, as appropriate. Of course, it is possible that some of the identified files may be required for the correct operation of your local system, in which case there is no clear workaround except for limiting the set of users who may run the binaries, by an appropriate use of user groups and removing the "o+x" file permission bit. 1) Download the 'scan_ncurses.sh' and 'test_ncurses.sh' scripts from ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/scan_ncurses.sh ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/test_ncurses.sh e.g. with the fetch(1) command: # fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/scan_ncurses.sh Receiving scan_ncurses.sh (381 bytes): 100% 381 bytes transferred in 0.1 seconds (7.03 kBps) # fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/test_ncurses.sh Receiving test_ncurses.sh (604 bytes): 100% 604 bytes transferred in 0.1 seconds (6.55 kBps) 2) Verify the md5 checksums and compare to the value below: # md5 scan_ncurses.sh MD5 (scan_ncurses.sh) = 597f63af701253f053581aa1821cbac1 # md5 test_ncurses.sh MD5 (test_ncurses.sh) = 12491ceb15415df7682e3797de53223e 3) Run the scan_ncurses.sh script against your system: # chmod a+x ./test_ncurses.sh # sh scan_ncurses.sh ./test_ncurses.sh / This will scan your entire system for setuid or setgid binaries which make use of the ncurses library. Each returned binary should be examined (e.g. with 'ls -l' and/or other tools) to determine what security risk it poses to your local environment, e.g. whether it can be run by arbitrary local users who may be able to exploit it to gain privileges. 4) Remove the binaries, or reduce their file permissions, as appropriate. V. Solution Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE after the correction date, or patch your present system source code and rebuild. Then run the scan_ncurses.sh script as instructed in section IV and identify any statically-linked binaries as reported by the script. These should either be removed, recompiled, or have privileges restricted to secure them against this vulnerability (since statically-linked binaries will not be affected by simply recompiling the shared libncurses library). To patch your present system: download the updated ncurses code from the below location, and execute the following commands as root: # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:68/ncurses.tar.gz # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:68/ncurses.tar.gz.asc Verify the detached PGP signature using your PGP utility. cd /usr/src tar xvfz /path/to/ncurses.tar.gz cd /usr/src/lib/libncurses make all make install In contrast to the usual practise, a simple patch fixing the security vulnerability is not provided because the vendor did not make one available, and the updated ncurses snapshot which fixed the vulnerability contains numerous other changes whose purpose and relation to the fix was unclear. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBOhB+8lUuHi5z0oilAQHjtwP9EIqTrWGcF4hzT7o7CrqGSTBWkQ6QhH2g DfIef15FLYXOoFImpyi1Jlk0V5RcuTTWez+Kpj8/+Yk3+TYuoYT1k08k1YBuBlCH HYGvhTAdTO9lflUS6uxZzmiRL3ZOjHPS5OXA6ualnaohMVvBjq/f3V7/cSYZLZ1p KmHPlYgvFPA= =SlgT -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security-notifications" in the body of the message From owner-freebsd-security-notifications Tue Nov 14 14:31:11 2000 Delivered-To: freebsd-security-notifications@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 4FA8837B479; Tue, 14 Nov 2000 14:30:59 -0800 (PST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory: FreeBSD-SA-00:69.telnetd Message-Id: <20001114223059.4FA8837B479@hub.freebsd.org> Date: Tue, 14 Nov 2000 14:30:59 -0800 (PST) Sender: owner-freebsd-security-notifications@FreeBSD.ORG Precedence: bulk Reply-To: postmaster@freebsd.org X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:69 Security Advisory FreeBSD, Inc. Topic: telnetd allows remote system resource consumption. Category: core Module: telnetd Announced: 2000-11-14 Credits: Jouko Pynnonen Affects: FreeBSD 3.x (all releases), FreeBSD 4.x (all releases prior to 4.2), FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior to the correction date. Corrected: 2000-10-30 (FreeBSD 4.1.1-STABLE) 2000-11-01 (FreeBSD 3.5.1-STABLE) FreeBSD only: NO I. Background telnetd is the server for the telnet remote login protocol. II. Problem Description The telnet protocol allows for UNIX environment variables to be passed from the client to the user login session on the server. However, some of these environment variables have special meaning to the telnetd child process itself and may be used to affect its operation. Of particular relevance is the ability for remote users to cause an arbitrary file on the system to be searched for termcap data by passing the TERMCAP environment variable. Although any file on the local system can be read since the telnetd server runs as root, the contents of the file will not be reported in any way to the remote user unless it contains a valid termcap entry, in which case the corresponding termcap sequences will be used to format the output sent to the client. It is believed there is no risk of data disclosure through this vulnerability. However, an attacker who forces the server to search through a large file or to read from a device can cause resources to be spent by the server, including CPU cycles and disk read bandwidth, which can increase the server load and may prevent it from servicing legitimate user requests. Since the vulnerability occurs before the login(1) utility is spawned, it does not require authentication to a valid account on the server in order to exploit. All released versions of FreeBSD prior to the correction date including 4.0, 4.1, 4.1.1 and 3.5.1 are vulnerable to this problem, but it was fixed in the 4.1.1-STABLE branch prior to the release of FreeBSD 4.2-RELEASE. III. Impact Remote users without a valid login account on the server can cause resources such as CPU and disk read bandwidth to be consumed, causing increased server load and possibly denying service to legitimate users. IV. Workaround 1) Disable the telnet service, which is usually run out of inetd: comment out the following lines in /etc/inetd.conf, if present. telnet stream tcp nowait root /usr/libexec/telnetd telnetd telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd 2) Impose access restrictions using TCP wrappers (/etc/hosts.allow), or a network-level packet filter such as ipfw(8) or ipf(8) on the perimeter firewall or the local machine, to limit access to the telnet service to trusted machines. V. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or 3.5.1-STABLE after the respective correction dates. 2) Apply the patch below and recompile the relevant files: Either save this advisory to a file, or download the patch and detached PGP signature from the following locations, and verify the signature using your PGP utility. ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:69/telnetd.patch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:69/telnetd.patch.asc Execute the following commands as root: # cd /usr/src/libexec/telnetd # patch -p < /path/to/patch_or_advisory # make depend && make all install Patch for vulnerable systems: Index: sys_term.c =================================================================== RCS file: /mnt/ncvs/src/libexec/telnetd/sys_term.c,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- sys_term.c 1999/08/28 00:10:24 1.24 +++ sys_term.c 2000/10/31 05:29:54 1.25 @@ -1799,6 +1799,13 @@ strncmp(*cpp, "_RLD_", 5) && strncmp(*cpp, "LIBPATH=", 8) && #endif + strncmp(*cpp, "LOCALDOMAIN=", 12) && + strncmp(*cpp, "RES_OPTIONS=", 12) && + strncmp(*cpp, "TERMINFO=", 9) && + strncmp(*cpp, "TERMINFO_DIRS=", 14) && + strncmp(*cpp, "TERMPATH=", 9) && + strncmp(*cpp, "TERMCAP=/", 9) && + strncmp(*cpp, "ENV=", 4) && strncmp(*cpp, "IFS=", 4)) *cpp2++ = *cpp; } Index: telnetd.c =================================================================== RCS file: /mnt/ncvs/src/libexec/telnetd/telnetd.c,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- telnetd.c 2000/01/25 14:52:00 1.22 +++ telnetd.c 2000/10/31 05:29:54 1.23 @@ -811,7 +811,7 @@ fatal(net, "Out of ptys"); if ((pty = open(lp, 2)) >= 0) { - strcpy(line,lp); + strlcpy(line,lp,sizeof(line)); line[5] = 't'; break; } @@ -1115,7 +1115,7 @@ IM = Getstr("im", &cp); IF = Getstr("if", &cp); if (HN && *HN) - (void) strcpy(host_name, HN); + (void) strlcpy(host_name, HN, sizeof(host_name)); if (IF && (if_fd = open(IF, O_RDONLY, 000)) != -1) IM = 0; if (IM == 0) Index: utility.c =================================================================== RCS file: /mnt/ncvs/src/libexec/telnetd/utility.c,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- utility.c 1999/08/28 00:10:25 1.13 +++ utility.c 2000/10/31 05:29:54 1.14 @@ -330,7 +330,7 @@ { char buf[BUFSIZ]; - (void) sprintf(buf, "telnetd: %s.\r\n", msg); + (void) snprintf(buf, sizeof(buf), "telnetd: %s.\r\n", msg); (void) write(f, buf, (int)strlen(buf)); sleep(1); /*XXX*/ exit(1); @@ -343,7 +343,7 @@ { char buf[BUFSIZ], *strerror(); - (void) sprintf(buf, "%s: %s", msg, strerror(errno)); + (void) snprintf(buf, sizeof(buf), "%s: %s", msg, strerror(errno)); fatal(f, buf); } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBOhG9KFUuHi5z0oilAQHUZwP/Xmo3EDteE4HwZovAO6UFzNtc3xVsFaUr Thf5XvpPThIOKmyYsUOL/kRbfnU3vJUdPA21uDYKyUEil5+x8+ZAuDzJXfMxHwu8 MMD1/d5QFfvuWN5W+/msdT7XKEjTmm4f09/tMxRAEyIMeKRj2H4gWxEGmaivJtvT 6bFKtbsSW1Q= =UltL -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security-notifications" in the body of the message From owner-freebsd-security-notifications Tue Nov 14 14:32:15 2000 Delivered-To: freebsd-security-notifications@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 72E6B37B4D7; Tue, 14 Nov 2000 14:32:03 -0800 (PST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory: FreeBSD-SA-00:70.ppp-nat Message-Id: <20001114223203.72E6B37B4D7@hub.freebsd.org> Date: Tue, 14 Nov 2000 14:32:03 -0800 (PST) Sender: owner-freebsd-security-notifications@FreeBSD.ORG Precedence: bulk Reply-To: postmaster@freebsd.org X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:70 Security Advisory FreeBSD, Inc. Topic: ppp "deny_incoming" does not correctly deny incoming packets Category: core Module: ppp Announced: 2000-11-14 Credits: Robin Melville Affects: FreeBSD 3.5, 3.5.1, 4.1, 4.1.1 FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior to the correction date. Corrected: 2000-10-30 (FreeBSD 4.1.1-STABLE) 2000-10-30 (FreeBSD 3.5.1-STABLE) FreeBSD only: Yes I. Background The ppp(8) utility includes network address translation functionality for translating between public and private IP address ranges. It uses the libalias library to perform translation services. II. Problem Description The "nat deny_incoming" command is documented as "refusing all incoming connections" and is commonly used as a simple "firewall" to prevent outside users from connecting to services on the internal network. However the behaviour of the ppp code was changed in the 4.x and 3.x branches prior to the release of FreeBSD 4.1 and 3.5 (on 2000-06-05 and 2000-06-03 respectively) to allow passing of packets which are not understood, such as IPSEC packets and other IP protocol traffic not explicitly recognised by the code as being an "incoming connection attempt". While this was arguably incorrect behaviour in itself, the code also incorrectly allowed through ALL incoming traffic, effectively turning "deny_incoming" into a no-op. Thus, users who are using the deny_incoming functionality in the expectation that it provides a "deny by default" firewall which only allows through packets known to be part of an existing NAT session, are in fact allowing other types of unsolicited IP traffic into their internal network. The behaviour of ppp was corrected to only allow incoming packets which are known to be part of a valid NAT session, which gives the desired packet filtering behaviour in the general case. Outgoing IP traffic which is not understood by libalias (such as an outgoing IPSEC packet part of a VPN) will cause a NAT session to be established which will allow incoming packets with the corresponding source and destination IP addresses and protocol number to pass, but all others to be denied. This behaviour may be sufficient for the security needs of many users, although users with advanced filtering or security policy requirements are advised to use a more configurable packet filter such as those provided by ipfw(8) or ipf(8) which can meet their needs. The following released versions of FreeBSD are the only releases vulnerable to this problem: 3.5, 3.5.1, 4.1, 4.1.1. It was fixed in the 4.1.1-STABLE branch prior to the release of FreeBSD 4.2-RELEASE. III. Impact Remote users can cause incoming traffic which is not part of an existing NAT session to pass the NAT gateway, which may constitute a breach of security policy. IV. Workaround Use a true packet filter such as ipfw(8) or ipf(8) on the PPP gateway to deny incoming traffic according to the desired security policy. V. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or 3.5.1-STABLE after the respective correction dates. 2) Apply the patch below and recompile the relevant files: Either save this advisory to a file, or download the patch and detached PGP signature from the following locations, and verify the signature using your PGP utility. ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch.asc Execute the following commands as root: # cd /usr/src/usr.sbin/ppp # patch -p < /path/to/patch_or_advisory # make depend && make all install Patch for vulnerable systems: Index: nat_cmd.c =================================================================== RCS file: /mnt/ncvs/src/usr.sbin/ppp/nat_cmd.c,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 - --- nat_cmd.c 2000/07/11 22:11:31 1.49 +++ nat_cmd.c 2000/10/30 18:02:01 1.50 @@ -421,7 +421,11 @@ break; case PKT_ALIAS_IGNORED: - - if (log_IsKept(LogTCPIP)) { + if (PacketAliasSetMode(0, 0) & PKT_ALIAS_DENY_INCOMING) { + log_Printf(LogTCPIP, "NAT engine denied data:\n"); + m_freem(bp); + bp = NULL; + } else if (log_IsKept(LogTCPIP)) { log_Printf(LogTCPIP, "NAT engine ignored data:\n"); PacketCheck(bundle, MBUF_CTOP(bp), bp->m_len, NULL, NULL, NULL); } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBOhG88FUuHi5z0oilAQFcaAP8D9gkr5GbGfj0visocGTMzKmhbXCwtgVX B5qwVdDKYSx3sAicK32gsnKdxJYno5D7Vd8ic0/N28DfuR+rw7tyGKPkgZZQiptL CTODBugeHFV/XZ3CyES+orkRN78Wgc6kBZtvyudaXtYHbzRo2K48acOGnQN/X4tR Tt613Vl57rY= =SCKm -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security-notifications" in the body of the message