STATION ID - 7047/3.12 9x Datakit Network FOR OFFICIAL USE ONLY This is a 9x system, restricted to authorized persons and for official 9x business only. Anyone using this system, network or data is subject to being monitored at any time for system administration and for identifying unauthorized users or system misuse. Anyone using this system expressly consents to such monitoring and is advised that any evidence of criminal activity revealed through such monitoring may be provided to law enforcement for prosecution. *************************************************** *** 9x presents *** ********** **** Security Flaws and Fixes V.2 ***** ******************** By: Nino ******************* ** THIS ARTICLE CONTAINS SECRET SECURITY FLAWS IN THE SUNOS SYSTEM THAT THEY DONT WANT YOU TO KNOW . -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Greets: Debbie And Jim , Hybdrid, Substance, Gino spyder, and the whole 9x Crew. Wicked and all you Other people i am forgeting because of lack of sleep. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -= SunOs Security =- Written By Nino aka The 9x Security Sniffer ------------------------------------------------------------ --------------- 9x ----------------- Threw my studies with Sunos security i have found i am starting to dislike this Os Very much, The information i have Brought to you is from a month's work of testing, sniffing. portscanning. rooting, ....... Research, Contacts, And studies . This Article has Very good and Useful information in it so please read, Learn and like what u have Learned. -- SunOs Restore Flaw -- A security hole has been found in SunOs restore. This problem affects SunOs Versions.4.0, 4.0.1, and 4.0.3 systems. It does not howeverappear in SunOS 3.5. The problem occurs because restore is setuid to root. Without going into details, it is sufficient to say that this is a serious hole. And I am sure there is some way we can use this information to gain or to secure access to systems. ALL SunOS 4.0 installations should install this. Note that you need to have an existing account to exploit this hole. There are two ways that Admins will use to fix the problem. The first is slightly more secure but has some side-effects. 1) Admins will make restore non-setuid by becoming root and doing a chmod 750 /usr/etc/restore This makes restore non-setuid and unreadable and unexecutable by ordinary users. So make sure you understand this before rooting a sun. I will explain in detail so you understand.. Making restore non-setuid affects the restore command using a remote tape drive. You will no longer be able to run a restore from another machine as an ordinary user; instead, you'll have be root to do so. (The reason for this is that the remote tape drive daemon on the machine with the tape drive expects a request on a TCP privileged port. Under SunOs you can't get a privileged port unless you are root. (Write that down) By making restore non-setuid, when you run restore and request a remote tape drive, restore won't be able to get a privileged port,so the remote tape drive daemon won't talk to it.) 2) If the system you are running or rooting does need to have some users run restore from remote tape drives without being root, you can use the following method I found out that Admins were using !. cd /usr/etc chgrp operator restore chmod 4550 restore This allows the use of restore by some trusted group. In this case, I used the group 'operator', but you may use any other group that you trust with access to the tape drive. Thus, restore is still setuid and vulnerable, but only to the people in the trusted group. When I ran tests on such things i found that it was important to know this information because it helped out in later usage of rooting a SunOs box that used this method. The 4550 makes restore readable and executable by the group you specified, and unreadable by everyone else. Sun knows about this problem (Sun Bug 1019265) and will put in a more permanent fix in a future release of SunOs so be sure to do what you can nw to fully understand the new usages of the SunOs systems. -Nino- -= SunOS 4.0.x rcp Security Flaw =- There was a Security Flaw discovered in the SunOs 4.0.x RCP. If this security flaw is exploited Then this could allow users of other machines to gain root commands on a sun via rcp. This affects only SunOS 4.0.x systems; 3.5 systems are not affected. A Sun running 4.0.x rcp can be exploited by any other trusted host listed in /etc/hosts.equiv or /.rhosts. Note that the other machine exploiting this hole does not have to be running Unix; this vulnerability can be exploited by a PC running PC/NFS, for example. This bug will be fixed by Sun in version 4.1 (Sun Bug number 1017314), but for now the following workaround is suggested: Change the 'nobody' /etc/passwd file entry from nobody:*:-2:-2::/: to nobody:*:32767:32767:Mismatched NFS ID's:/nonexistant:/nosuchshell ***** SECRET FLAWS THAT WERENT RELEASED TO THE PUBLIC ******** Brought to you by 9x ""Sun has recently released a patch for a security hole in SunView. This problem affects SunView running on all versions of SunOS (3.5 and before, 4.0, 4.0.1, 4.0.3, and 4.1) and all platforms (Sun3, Sun4, 386i). This vulnerability allows any remote system to read selected files from the workstation running SunView. As noted below in the IMPACT section, the files that can be read are limited. This vulnerability is in the SunView (aka SunTools) selection_svc facility and can be exploited while SunView is in use; however, as noted below in the IMPACT section, this bug may be exploitable after the user quits using Sunview. This problem cannot be exploited while X11 is in use (unless the user runs X11 after running Sunview; see the IMPACT section). This problem is specific to Sun's SunView software; to our knowledge, this problem does NOT affect other vendor platforms or software. OBTAINING THE PATCH To obtain the patch, please call your local Sun Answer Center (in the USA, it's 1-800-USA-4SUN), and ask for patch number 100085-01. You can also reference Sun Bug ID 1039576. The patch is available for SunOS 4.0.1, 4.0.3 and SunOS 4.1, on Sun3, Sun4, and 386i architectures. Contact Sun for further details. IMPACT On Sun3 and Sun4 systems, a remote system can read any file that is readable to the user running SunView. On the 386i, a remote system can read any file on the workstation running SunView regardless of protections. Note that if root runs Sunview, all files are potentially accessible by a remote system. If the password file with the encrypted passwords is world readable, an intruder can take the password file and attempt to guess passwords. In the CERT/CC's experience, most systems have at least one password that can be guessed. Sunview does not kill the selection_svc process when the user quits from Sunview. Thus, unless the process is killed, remote systems can still read files that were readable to the last user that ran Sunview. Under these circumstances, once a user has run Sunview, start using another window system (such as X11), or even logoff, but still have files accessible to remote systems. However, even though selection_svc is not killed when Sunview exits, the patch still solves the security problem and prevents remote access. Sun Bug ID : 1008324 Synopsis : TIOCCONS redirection of console input/output is a security violation. Sun Patch ID : for SunOS 4.1, SunOS 4.1_PSR_A 100187-01 Sun Patch ID : for SunOS 4.1.1 100188-01 Available for: Sun3, Sun3x, Sun4 Sun4c SunOS 4.1, SunOS 4.1_PSR_A, SunOS 4.1.1 Checksum of compressed tarfile on ftp.uu.net:~ftp/sun-dist sum of SunOS 4.1 tarfile 100187-01.tar.Z : 14138 142 sum of SunOS 4.1.1 tarfile 100188-01.tar.Z: 24122 111 - -------------------------------------------------------------------------- README information follows: Patch-ID# 100188-01 Keywords: TIOCCONS Synopsis: SunOS 4.1.1: TIOCCONS redirection of console is a security violation. Date: 17/Dec/90 SunOS release: 4.1.1 Unbundled Product: Unbundled Release: Topic: BugId's fixed with this patch: 1008324 Architectures for which this patch is available: sun3 sun3x sun4 sun4c Patches which may conflict with this patch: Obsoleted by: Next major release of SunOS Problem Description: TIOCCONS can be used to re-direct console output/input away from "console" Patch contains kernel object modules for: /sys/sun?/OBJ/cons.o /sys/sun?/OBJ/zs_async.o /sys/sun?/OBJ/mcp_async.o /sys/sun?/OBJ/mti.o Where sun? is one of sun4, sun4c, sun3, sun3x, sun4/490-4.1_PSR_A NOTE: The sun4c does not use mti.o nor mcp_async.o since this architecture does not have VME slots and therefore cannot use the ALM-2 Asynchronous Line Multiplexor or Systech MTI-800/1600. So those modules are not needed. The fix consists of adding permission checking to setcons, the routine that does the work of console redirection, and changing its callers to supply additional information required for the check and to see whether or not the check succeeded. Setcons now uses uid and gid information supplied to it as new arguments to perform a VOP_ACCESS call for VREAD permission on the console. If the caller doesn't have permission to read from the console, setcons rejects the redirection attempt. INSTALL: AS ROOT: save aside the object modules from the FCS tapes as a precaution: # mv /sys/sun?/OBJ/cons.o /sys/sun?/OBJ/cons.o.orig # mv /sys/sun?/OBJ/tty_pty.o /sys/sun?/OBJ/tty_pty.o.orig # mv /sys/sun?/OBJ/zs_async.o /sys/sun?/OBJ/zs_async.o.orig # mv /sys/sun?/OBJ/mcp_async.o /sys/sun?/OBJ/mcp_async.o.orig # mv /sys/sun?/OBJ/mti.o /sys/sun?/OBJ/mti.o.orig copy the new ".o" files to the OBJ directory: # cp sun?/*.o /sys/sun?/OBJ/ build and install a new kernel: rerun /etc/config and do a "make" for the new kernel Please refer to the System and Network Administration Manual for details on how to configure and install a custom kernel. - ------------------------------------------------------------------------- Patch-ID# 100187-01 Keywords: TIOCCONS Synopsis: SunOS 4.1 4.1_PSR_A: TIOCCONS redirection of console is a security violation. Date: 17/Dec/90 SunOS release: 4.1 4.1_PSR_A Unbundled Product: Unbundled Release: Topic: BugId's fixed with this patch: 1008324 Architectures for which this patch is available: sun3 sun3x sun4 sun4c sun4-490_4.1_PSR_A Patches which may conflict with this patch: Obsoleted by: Next major release of SunOS Problem Description: TIOCCONS can be used to re-direct console output/input away from "console" Patch contains kernel object modules for: /sys/sun?/OBJ/cons.o /sys/sun?/OBJ/zs_async.o /sys/sun?/OBJ/mcp_async.o /sys/sun?/OBJ/mti.o Where sun? is one of sun4, sun4c, sun3, sun3x, sun4/490-4.1_PSR_A NOTE: The sun4c does not use mti.o nor mcp_async.o since this architecture does not have VME slots and therefore cannot use the ALM-2 Asynchronous Line Multiplexed or Systech MTI-800/1600. So those modules are not needed. The fix consists of adding permission checking to setcons, the routine that does the work of console redirection, and changing its callers to supply additional information required for the check and to see whether or not the check succeeded. Setcons now uses uid and gid information supplied to it as new arguments to perform a VOP_ACCESS call for VREAD permission on the console. If the caller doesn't have permission to read from the console, setcons rejects the redirection attempt. INSTALL: AS ROOT: save aside the object modules from the FCS tapes as a precaution: # mv /sys/sun?/OBJ/cons.o /sys/sun?/OBJ/cons.o.orig # mv /sys/sun?/OBJ/tty_pty.o /sys/sun?/OBJ/tty_pty.o.orig # mv /sys/sun?/OBJ/zs_async.o /sys/sun?/OBJ/zs_async.o.orig # mv /sys/sun?/OBJ/mcp_async.o /sys/sun?/OBJ/mcp_async.o.orig # mv /sys/sun?/OBJ/mti.o /sys/sun?/OBJ/mti.o.orig copy the new ".o" files to the OBJ directory: # cp sun?/*.o /sys/sun?/OBJ/ build and install a new kernel: rerun /etc/config and do a "make" for the new kernel Please refer to the System and Network Administration Manual for details on how to configure and install a custom kernel. - ------------------------------------------------------------------------- Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Internet E-mail: cert@cert.org Telephone: 412-268-7090 24-hour hotline: CERT personnel answer 7:30a.m.-6:00p.m. EST, on call for emergencies during other hours. Past advisories and other information are available for anonymous ftp from cert.org (192.88.209.5). IMPACT: The vulnerability allows a user on the system to gain unauthorized access to other accounts, including root. SOLUTION for SunOS 4.0.3 and 4.0.3c: Sun Microsystems, Inc. has patched versions of in.telnetd and in.rlogind available for SunOS 4.0.3 on all Sun 3 and Sun 4 architectures. The Sun Patch ID is 100125-03 which is needed when ordering the patch from a Sun Answer Center. In the US, telephone (800) USA-4SUN. The checksum of the compressed tarfile (filename 100125-03.tar.Z) is 17128 102. The compressed tarfile is available by anonymous FTP on uunet.uu.net (192.48.96.2) in sun-dist/100125-03.tar.Z. Please note: This compressed tarfile also includes patched versions of in.telnetd for SunOS 4.1 and 4.1.1. Please disregard these files. SunOS 4.0.3 patch installation instructions are as follows: # mv /usr/etc/in.telnetd /usr/etc/in.telnetd.FCS # mv /usr/etc/in.rlogind /usr/etc/in.rlogind.FCS # chmod 600 /usr/etc/in.telnetd.FCS # chmod 600 /usr/etc/in.rlogind.FCS (These four steps store the old versions as a precaution and change the file modes so that the old versions cannot be executed. After verifying the new versions, the old versions should be removed.) # cp sun{3,3x,4,4c}/{4.0.3,4.0.3c}/in.telnetd /usr/etc/in.telnetd # cp sun{3,3x,4,4c}/{4.0.3,4.0.3c}/in.rlogind /usr/etc/in.rlogind (Be sure to copy the appropriate versions for your architecture.) # chmod 711 /usr/etc/in.telnetd # chmod 711 /usr/etc/in.rlogind # chown root /usr/etc/in.telnetd # chown root /usr/etc/in.rlogind # chgrp staff /usr/etc/in.telnetd # chgrp staff /usr/etc/in.rlogind # kill {any executing in.telnetd and in.rlogind process(es) (SEE NOTE)} NOTE: Be careful in killing existing in.telnetd and in.rlogind processes, as they may be legitimate users attempting to login to the system. Sun Bug ID : 1059621 Synopsis : security hole created by installing sunsrc Sun Patch ID: Not applicable see fix below. This applies to sites that have installed Sun Source tapes only. The Sun distribution of sources (sunsrc) has an installation procedure which creates the directory /usr/release/bin and installs two setuid root files in it: makeinstall and winstall. These are both binary files which exec other programs: "make -k install" (makeinstall) or "install" (winstall). This makes it possible for users on that system to become root. The solution: chmod ug-s /usr/release/bin/{makeinstall, winstall} (if the sources have already been installed) and/or edit the makefile in sunsrc/release and change the SETUID definition (if the sources have been extracted from tape but not installed yet) An lpd bug was discovered where lpd could be used to remove system files (/etc/passwd or /.rhosts as examples). This bug was fixed with 100305-01. A second bug was also shown that could still be used to remove system files. This fix was rolled into 100305-02. An lpc problem that touched one of the same modules as in the lpd fix was fixed and the subsequent change rolled into the lpd patch 100305-03. Two additional problems were sent to Sun: one having to do with RPC calls to lpd and the second having to do with postscript calls to lpd, thus 100305-04. It was in creating the -04 version that we unknowingly introduced a remote spool problem on the SunOS 4.1.1 version of the patch. The problem was that if the remote queue had jobs in it, the local job sent was often truncated to zero length. The -05 version was an attempt to back out the last few changes to remove the remote print problem. Unfortunately, it did not. It was at this time that we decided to do a lengthy evaluation and test cycle to ensure that the newest version fixed all the reported problems as well as fixed the remote spool bug we had introduced. The 100305-06 patch is the result of that lengthy test cycle."" THE ABOVE INFORMATION IN QUOTE WAS NOT SUPPOSED TO BE RELEASED BY SUNS ALLIES, UNFORTANATLY NINO FOUND OUT ABOUT THIS INFORMATION AND IS GIVING IT TO YOU AS OF NOW PLEASE ENJOY. THEY THINK THEY CAN KEEP STUFF HIDDEN WITH ALL THOSE FLAWS ?. NAH DONT THINK SO. ENJOY THE INORMATION. -=Nino=- Bringing Security News live to you right from the systems of 9x --------------------------------------------------------------------------------------------------------------- Note: This information in ("<) is not supposed to be distributed to the public. Nino felt you all had a right to know about these secret bugs and flaws In the SunOs systems. 9x is not reasponsible for any use or misuse of The information containing in this article. This is for informational Use Only, Any subject abusing this information is subject to getting caught And prosecuted. Please use at your own risk, Do no blame 9x for your Actions Thankyou --Nino-- --9x--