A Practical Guide to Solaris Security pdf

As long as themachine is up and running the root user can change EEPROM password with the “eeprom”command: # eeprom security-password= Changing PROM password: New password: If you forget

A Practical Guide to Solaris Security

Who should read it? This paper assumes some knowledge of Solaris and is suitable for anyonewho has completed the ‘Solaris2.x System Administration’ course and would like to knowmore about Solaris2 security features

1 Executive Summary 4

2 Overview 4

3 Introduction 4

4 Physical Security 6

5 EEPROM Security 7

6 Login Security 9

6.1 Compromised Passwords 9

6.2 Good Passwords 9

6.3 Missing Passwords 9

6.4 Password Administration 10

6.5 Direct root login 10

6.6 Password Cracking 11

6.7 Groups 12

6.8 Shell Security 13

6.9 The Swap User Command 14

6.10 Modem Security 15

7 Application Security 16

7.1 Basic file permissions revisited 16

7.2 UMASK Setting 16

7.3 Automatic Start-up Wrappers 17

7.4 Setuid programs 18

7.5 Setuid Shell Scripts 18

7.6 Shared Library Security 19

7.7 Hidden directories and files 20

7.8 X11 Security 21

7.9 Loading files from Media 22

7.10 Device Allocation 23

8 Network Security 24

8.1 Machine cloning 24

8.2 Network Snooping 24

9 Network Authentication 25

9.1 Secure RPC 25

9.2 DES Authentication 25

9.3 Kerberos Authentication 26

10 Network Services 27

10.1 NFS Security 27

10.2 inetd 29

10.3 in.routed 29

10.4 sendmail 30

10.5 Remote Access Commands 30

11 Public Networks 31

11.1 Automatic Packet Forwarding 31

11.2 Firewall 31

11.3 Ftp & Telnet 32

12 Network Information Services 33

12.1 Solaris1 & Solaris 2 NIS 33

12.2 Moving NIS Map Source files 33

12.3 Solaris 2 & NIS+ 34

13 Logs & auditing 35

13.1 Console Servers 35

13.2 BSM auditing 35

13.3 The system logger “Syslog” 36

13.4 Accounting 37

14 Unbundled products 38

14.1 History of Solaris Security Products 38

14.2 Automatic Security Enhancement Tool (ASET) 38

14.3 Account Resource Management (ARM) 39

14.4 Compartmented Mode Workstation (CMW) 39

15 Hackers toolkit 40

15.1 Trojan Horse 40

15.2 Trojan Mule 40

15.3 Viruses 41

15.4 Worms 41

15.5 Back Doors 41

Appendices 42

Appendix A: Crack programs 42

1 Executive Summary

The UNIX* operating system is generally perceived to lack adequate security This is partly due

to its academic origins and partly due to its design goal to be inviting and flexible As UNIXhas matured more security features have evolved and today UNIX can provide similar levels ofsecurity to those found in proprietary systems

One of the main objectives of Solaris 2.3 is to take UNIX further into the commercial place where good security is a major concern Many new security features have been included

market-in Solaris 2.3 to achieve this goal As an example, Solaris 2.3 has a “Basic Security Module”which has “audit trail” functionality mandated by government groups

For some organisations security is important but not paramount They wish to have a bly secure system without losing the flexibility that attracted them to UNIX The Solaris2 ‘aset’command has been included for this type of user

reasona-2 Overview

This document guides the system administrator thought the issues of system security Each tion provides examples of the command used to setup the security feature Information on theimportant system files and commonly made mistakes have been highlighted At the end of eachsection a reference to the relevant Solaris manual set is provided for further information

sec-This document details several methods of attack and tools that are used to gain unlawful access

to computer systems (“hacking”) This information will prove useful to enable the system ministrators to guard against hacking

ad-Getting Help

Following the guidance of this document will result in a much tighter security for your system.however no system can be considered totally secure Sun have setup a Security Awareness Pro-gram As part of this an email alias “security-alert@sun.com” is available for customers totrack/report new security issues It is important to know that Sun will provide security patches

to anyone who requests them, even if they do not have a maintenance contract

3 Introduction

The dictionary defines secure as: to make safe from risk or damage; to guarantee against loss.The word security is defined as: freedom from danger, fear, or anxiety; protection: measurestaken to protect against espionage or sabotage

All these definitions of security apply to computer systems We need to physically protect ourcomputers from damage.We need to guard against loss of data as well as illegal access

UNIX* - Is a trademark of X/open

An organisation’s primary concern is the protection of its data rather than it’s computers tems Preventing unauthorised access is just a means of protecting data The loss of CPU timeand disk space is not the main concern, data integrity is Figure1 illustrates that the majority ofdata damage is caused by error rather than malicious intent It is clearly a security prerequisitethat a thorough backup strategy and comprehensive disaster recovery procedures exist.

sys-The task of protecting data involves more than making secure backups and preventing outsidersfrom logging in Figure2 illustrates that computer crime is predominately committed by em-ployees Account security is just the perimeter fence It is important to protect users from eachother with good file system security

Fig1: Causes Of Data Damage

Human Error

source: Data Processing Management Assoc 1992

Fig 2: Perpetrators Of Computer Crime

4 Physical Security

“A computer is only as secure as the room it’s locked in?”

The problem is that anyone with physical access to a machine can bring along their own diskand connect it Then it’s a simple matter of crashing the machine and booting from this disk.Once the system is up and running on their disk, the file systems on the original disks can bemounted and tampered with

This would be even easier if, like most SPARCservers, the machine had a CD-Rom player tached In this case all that is required is a copy of the Solaris CD The system is booted fromthe CD into single user mode where access to resident disks can be obtained The machine’soperating system could even be reinstalled!

at-The solution to this scenario is found in section 5 ‘EEPROM security’ However even if theEEPROM will not let them boot an external disk, cables and SCSI switches can be changed tomake the new disk appear to be the old disk

So to prevent this tampering with cables, the machines cabinet needs to be locked Larger SunServers have keys which need to be turned for the boot sequence to start but most are left in forconvenience Sun’s Data-centre cabinets also have connections for an electronic key on theback of the power supply, but few people utilise this

Servers can be locked in computer rooms However desktop systems often cannot For example

a teaching laboratory environment It is possible to secure the CPU box to a desk as all desktopSuns have a bolting point integral to the system This not only safe guards against theft of thebox but also prevents the lid from being opened and memory or disks removed

It may just be the intention of the assailant to crash the system It’s difficult to prevent someonepulling out the power cable However other ways of crashing the machine such as the “stop-a”sequence and unplugging the keyboard cable can be prevented by modifying the kernel

A similar problem is faced with the serial cable to console terminals Switching the console minal on/off will cause a server to crash It may even be worth buying a graphics head for yourserver to side step this potential hazard

ter-In conclusion machines with important data should be locked in a computer room - even if theydon’t need air-conditioning

!

5 EEPROM Security

All Sun system CPU boards have an EEPROM This EEPROM contains the ‘monitor’ programwhich controls the system during startup When a machine is powered on, the monitor firmwarewill automatically run system diagnostics then boot the system If this boot sequence is inter-rupted with “stop-a” (the break key if the console device is a dumb terminal), then the machinewill be left with the monitor’s interactive prompt:

“ok”

From this prompt you can instruct the monitor to boot the system from any device: CD-Rom,external disk or even another machine on the network To limit this, the monitor has three se-curity modes none-secure (the default), command-secure and fully-secure

In fully-secure mode a password, known as the “EEPROM-password” has to be given beforethe monitor will boot anything This is a little inconvenient on desktop machines which areprone to being accidentally halted or crashed The automatic reboot feature would be interrupt-

ed with a prompt for the EEPROM password To alleviate this the command-secure mode can

be used which allows only the boot command ‘b’ to be executed without entering the EEPROMpassword A suitable policy would be to set server systems to fully-secure and client worksta-tions to command-secure For example:

ok# setenv security-mode=command passwd = <type your password>

ok# printenv

A nice feature of the “monitor” is the ability to change the power on logo which normally plays the machine’s serial number You can set this to identify the machine as belonging to yourorganisation This would reduce the likelihood of a thief finding a buyer As long as the EEP-ROM password was set he could not change this banner message Note however if the EEP-ROM password is not set a thief could disguise the serial number An Example:

dis-ok# setenv oem-banner?=true ok# setenv oem-banner=”THIS IS MY MACHINE”

ok# printenv

It is possible to reset the EEPROM password without knowing the old password As long as themachine is up and running the root user can change EEPROM password with the “eeprom”command:

# eeprom security-password=

Changing PROM password:

New password:

If you forget the EEPROM password with the security-mode set to full and the machine is

halt-ed you will not be able to reboot the machine The only way then, to reset the EEPROM

pass-!

There is also a way to see if anyone has attempted to break into the EEPROM A variable called

“security-#badlogins” keeps a count of the failed attempts It can be set to zero by typing:

# eeprom security-#badlogins security-#badlogins=0

Early versions of the ‘Open Boot Prom’ (Version 1.x) had a security problem with specificbreak sequence This has been fixed in Version 2.x If you have one of these older EEPROM itshould be replaced Sun’s customer services should be contacted for advice on your particularmachine To display EEPROM revision type “banner” at the “ok” prompt

Accidental Interrupts

No matter which security mode you have set, it is always possible to use the continue command

“go” This assumes the machine has not been turned off As long as the memory and CPU isters have not been altered the machine will resume execution at the point that it was interrupt-

reg-ed this is the first thing to try if the break sequence has been used accidentally Users should

be informed of this to prevent the system administrator having to attend every accidentally

halt-ed machine

NOTE: If the EEPROM is in ‘old-mode’, the user will be prompted by the ‘>’ character instead

of ‘ok’ In this case the ‘c’ command is used instead of ‘go’ Alternatively to obtain an ‘ok’prompt the command ‘new-mode’ is used

en their account details to a new system by email If the new account is little used, rather thanremember this additional password, some users save the email or commit it to a file It may be

a low privilege account but it could often be the door for a hacker to greater things There aremany other factors that drive users to committing their password to paper/disk:

1 They have a too many different passwords for too many different machines

2 For the password to be any good it has to be unintelligible and thus difficult to remember

3 The administrator makes the users change their password too often

4 The administrator allocates computer generated passwords impossible to remember

We can do much to prevent a password being discovered, not least by choosing better words, but there is little we can do if users feel they have to write them down in order to re-member them With this respect you are left at the mercy of the users

pass-6.2 Good Passwords

A good password is meaningful to the user but nonsensical to anyone else No word found in adictionary is good enough thanks to programs like “Crack” (See appendix A) Solaris 2.3 hassome new features which help users create good passwords Users run the command “passwd”

to change their passwords Under Solaris 2.3 new passwords are vetted by “passwd” before ing accepted It checks that:

be-1 The password is greater than six characters (Configurable in the /etc/default/passwd file)

2 The password has at least two alphabetical and one non-alphabetical characters

3 The new password is not the same as the old password

4 The password is not the same as the user name

Unlike Solaris1, insisting on a rejected password will not result on the password being

accept-ed Note: “passwd” will not object to any password set by root as it is assumed that the root userknows best

6.3 Missing Passwords

Its a bad idea to allow accounts to have no password By default, Solaris2 forces all accounts

to have a password To confirm this check that the PASSREQ (PASSword REQuired) parameter

!

expire: date when account will expire

All the above fields can be changed with the /usr/bin/passwd command Its always best to usecommands like passwd or use admintool to set these properties as hand editing the shadowpassword file can result in catastrophe if typing mistakes are made Solaris1.1 did have a pass-word aging facility but it was not compatible with NIS and was little used Note: Default poli-cies for password aging are defined in “/etc/default/passwd” (See man page for passwd (1))

Locking Accounts and Passwords

Solaris 2 gives us the facility to lock an account.There is even a way to prevent users fromchanging their passwords By setting ‘min’ greater than ‘max’ the user can still login but notchange his password Useful for allocating password rather than allowing users choose theirown Here are some examples:

# passwd -l <user> Lock an account

# passwd -n 10 -x 7 Lock a password

# passwd -f <user> Change password on next login

# passwd -n 30 <user> Change password every 30 days

Remember: don’t enforce too strict a regime, as it will force users to write down their words Passwords are your first and most important line of defence and any one user can be theweak link in the chain Education of users rather than enforcement of rules is the key to goodpassword security

pass-6.5 Direct root login

Any user with the UID of 0 (often called the Superuser or root) is granted full access to all files

on the system despite any access permissions set-up by the file’s owner The superuser’s namemay not necessarily be called “root” and in fact several user names could have a UID of 0 This

is an important thing to remember when looking for evidence of hacking

Given it’s awesome power it’s a good idea to restrict the activities done as root Most systemadministrators login directly as root as a matter of course, because they believe that root privi-leges are needed to perform their tasks Not so, in Solaris 2 group 14, often named “Sysadmin”,

!

gives it’s members the privilege to perform system administration tasks using Admintool (Seesection 6.7 Groups).

Its best not to let anyone login directly as root System administrators should discipline selves to login with their own user credentials then switch user (su) to root This also has theadvantage of leaving better audit trails if a system is managed by more than one person Thisregime is also good for eliminating those catastrophic mistakes that commonly resulting fromwildcard activity as root

them-Solaris 2, by default, doesn’t let root login anywhere except the system console This is trolled by the following line in the /etc/default/login file:

con-CONSOLE=/dev/console

If the console is locked in the computer room with the machine then the default setting is propriate However for a workstation it would be better to disable root login completely by set-ting console to the null device:

If five failed attempts are made, syslogd (See section 13.3) will send an alarm message to theconsole However, it records little information about the suspected break-in attempt More in-formation can be recorded by enabling the login log:

!

!

Encrypted Passwords

Because of password cracking programs (See Appendix A), its a bad idea to let the world seeeven your encrypted passwords If hackers can take a copy of the encrypted passwords thenthey can attempt to crack them on their own machine at leisure and in secret

To prevent this Solaris 2 has a shadow password file UNIX requires the account information

to be globally accessible This means that the /etc/passwd file must be readable by everyone InSolaris 1 encrypted passwords were stored in this file too In Solaris 2 the /etc/passwd file stillcontains the account information but passwords and associated information is kept in /etc/shad-

Group Passwords

Some older UNIX system made use of the group password facility, where users can swap to anygroup provided they knows the group password When a user swaps to one of his secondarygroups, no password is required Solaris 1 and Solaris 2 have this functionality, but no use ismade of it and there is no command to set a group password However one could be written ifthis functionality was desired Copying an encrypted password string from the /etc/shadow fileand inserting it into the password field of the group file will work

Sys (group 3)

There are several powerful commands that can be executed by anyone with group ID of 3, (GID3) The most important being ufsdump The idea being that operators can perform a backupwithout knowing the root password This has its advantages, but remember anyone who can rundump can steal data A dump tape can be restored on another machine where the thief does haveroot privileges Note: Under Solaris1 dump and shutdown could be run by anyone in the oper-ator group (GID=5)

Wheel (group 0)

Under Solaris1 the GID of 0 (know as the root or ‘wheel’ group) gives a list of users that canrun “su”, the swap user command However if the group was not defined then any user was en-titled to run “su” The “Wheel” group feature has been removed in Solaris 2 However if thisfunctionality is required it could easily be setup by creating your own wheel group then:

# chgrp wheel /usr/bin/su; chmod 510 /usr/bin/suNOTE: a version of su exists in /sbin as well as /usr/bin So access to both needs to be consider

SysAdmin (group 14)

Anyone in the sysadmin group can run Admintool and perform system administration taskssuch as add/delete users or reseting printers It is even possible to delete and recreate the rootaccount with a new password! So tight control is necessary over group 14 membership

Admintool is network extensible and can be used to modify remote machines as well It can beset up to use different levels of network authentication This level can be changed by editingthe /etc/inetd.conf file and running “admind” with the -S option:

100087/10 tli rpc/udp wait root /usr/sbin/admind admind -S 2

You do not need to maintain the same level of security on all systems It might be a good idea

to run level 2 security on servers and the default, level 1, on workstations Level 1 means thehosts “admind” will accept the user and group identities directly from the client system If theuser is in group 14 then he has admintool powers Watch out for level 0 where no identity check-ing is done Note, ’-S 2’ option requires DES authentication to be set up - (see section 9.2)

6.8 Shell Security

There are many command interpreters (Shells) to choose from The login program puts usersinto their default shell which is specified in the /etc/passwd file In Solaris 2 users can no longerchange their default shell It was possible to do this with the passwd or chsh commands inSolaris1 Types of new shells could be restricted by creating a list of allowable shells in the ‘/etc/shells’ file

Preventing users from changing their default shell means that the system administrator can termine which global startup file they run and use it to enforce policy For the bourne (sh) andkorn (ksh) shell this is /etc/profile Solaris1 had no such file for the C-shell (csh) however theSolaris 2 ‘csh’ now uses the /etc/.login file for this purpose

de-These files are a good place to set users up with some healthy defaults for shell variables such

as PATH,UMASK or LD_LIBRARY_PATH The administrator can now mandate which shellthe users enter by and hence which startup file they will execute

The Command Path

Which version of a command a user executes is determined by the setting of his environmentalvariable “PATH” It’s a security risk to have a “.” in a users command path This tells the shell

to look in the current directory for commands The user may think he is executing /usr/bin/lswhen really he is executing “./ls” left by a hacker (see section 15.1 - trojan horse) If “.” must

be in a PATH then put it at the end It is most important not to have “.” in the root’s PATH Itmight even be a good idea not to have a root path defined This way the root user has to typethe full pathname (/usr/bin/ls) A little realised fact is that a ‘:’ at the beginning or end of thepath has the same meaning as “.” So does an empty field ‘::’, so check for these as well

!

1 Changing directory

2 Setting the command path

3 Using shell redirection (i.e >, >>)

Command use can be limited by putting only the allowed commands in the special “./bin” rectory and setting the path appropriately It is very important to vet every command you place

di-in the restricted bdi-in directory A classic mistake is to let users run “vi” Once di-in “vi” its a simplematter to spawn a normal shell using “!sh” for example

If the purpose of the account is to share files with absolutely anyone then an anonymous ftp count would be better Rather than allowing users to login, let them interact with your ftp dae-mon (See section 11.3 ftp & telnet)

ac-6.9 The Swap User Command

The “su” command allows any user to change his UID to another user provided he has knowsthe users password This is potentially a very dangerous command In fact if you are root youcan “su” to another user without knowing his password The reason being that if your root ac-count is compromised then the system is lost anyway so what does it matter? It matters whenNFS is involved, (see Section 10.1 - NFS security)

It seems prudent to monitor the use of such a powerful command Solaris 2 has a much moreextensive and flexible “su” logging facilities The file /etc/default/su contains the following pa-rameters:

SULOG: Defines log fileCONSOLE: Which screen to send messages to; If any

PATH: Default path for new shellSUPATH: Default path if su is to rootSYSLOG: whether or not to send signals to syslogd

As with Solaris1, reports of “su” activity are sent to the system logger (see section 13.3 syslogd)and as a result messages end up on the system console Additionally, in Solaris 2 all “su” activ-ity is logged to /var/adm/sulog (The default setting for SULOG) If syslogd is not running thenmessages can be sent directly to the console device by defining CONSOLE in /etc/default/su tThere seems little point in defining PATH and SUPATH as users can simply set their own after

“su-ing”

!

Auto Logout / Lock Screen

Users are prone to walk away from their screens without logging out An opportunist couldquickly give himself permanent access to that user’s account.(Note: he would not be able to find

or change the absent users password, as the old password is needed to change to a new word) It therefore might be a good idea to automatically logout users after a period of inactiv-ity This also helps with machine performance An autologout program is not included inSolaris however public domain versions exist On such program is called “untamo” and can beobtained from several internet sites by anonymous ftp

pass-Untamo is only effective with terminal based users It is not so easy to write such a program for

an X-windows based user as inactive sessions can often be windows that need to be left open.The answer in this case it to force users to run a screen locking program (See Section 7.8 - X-Window Security)

There is however an inherent danger with automatic logout programs in the time it takes them

to notice inactivity and take action This leaves a window of opportunity for a hacker not only

to resume the session before inactivity time is reach but to leave a “trojan mule” (See section15.2) It is much better to educate users to logout every time they leave their desks

6.10 Modem Security

Connecting a modem to your system makes it prone to attack from any schoolboy hacker with

a PC at home Serious consideration is required before attaching a modem If you do need theuse of a modem maybe it can be setup for dailout only If dial-in functionality is necessary adial-back regime is recommended This involves terminating all calls after the user has identi-fied himself The system will then dial him back on a number stored by the system administra-tor In this way only registered phone numbers can establish connections The disadvantagebeing that the call is now outgoing for telephone charging purposes Solaris 2 has no dial-backfacility as standard However a third part product called “TermServ” can be purchased and isused by Sun (See Appendix C-Third Party Products) If full bidirectional functionality is re-quired then Solaris 2 has an additional “port passwords” feature that can help

!

7 Application Security

7.1 Basic file permissions revisited

Everyone thinks they knows what the UNIX file permissions mean But it might be worth goingover this one more time for reference sake These are well understood for regular files but there

is often confusion over their meaning when set on a directory

For a directory:

d-w - Files can be created/deleted, only if the directory is the current directory.dr - The contents can be listed but file attributes can’t be read (‘ls -l’ doesn’t work).d x - The directory can be entered, and used in full execution paths

dr-x - File attributes can now be read (‘ls -l’ now works)

d-wx - File can be created/deleted, even if the directory isn’t the current one

d -x-t Prevents files from deletion by others with write access Used on /tmp

d -s s - No effect (Note: the setgid bit had some meaning in Solaris 1.x)

for regular files:

-r - Allow read access to the file

w - Allows the user to modify, or delete the file

-x - Only the owner can execute files (Not shell scripts)*

-s - Will execute with effective user ID = owner (See section 7.4)

-s Will execute with effective user ID = group (See section 7.4)

-rw -T No update of “last modified time” Usually set on swap files

-t - No effect (Note: Called the sticky bit had some meaning in SunOS 3.5)

rwl The file must be locked before reading or writing

* Note: Shell scripts need read as well as execute permissions to be run

7.2 UMASK Setting

UNIX file permissions are a user’s first line of defence, but are often over looked Files are ated without regard to their permissions setting If files are created without explicitly specifyingany permissions then they will get the default permissions defined by the user’s “umask” Thestandard umask,022, leaves files readable by the world a more secure umask would be 077:

cre-Using umask 022 gives new file -rw-r r permissionsUsing umask 077 gives new file -rw - permissions

Table 1:

Its a good idea to set system wide umask in /etc/profile and /etc/.login (See “Setting Defaultfile permissions Solaris2.3 Advanced User Guide page 151)

Device File Permissions

Close attention must be given to the permissions on the files in the /dev directory Anyone whohas access to /dev/dsk/c0t0d0s0 has access to any part of the file system mounted on it

If this is the root file system the /etc/shadow file could be examined/altered e.g.:

dd if=/dev/dsk/c0t0d0s0 | grep shadow

When a user logs in, the login program will change the owner and group of the device file tothe UID of the successfully logged in user It will also change the GID to “tty” It then changesits permissions to “crw w -” This prevents other users interfering This default behaviour can

be changed by editing the “/etc/logindevperm” file This file has great potential for letting otherusers eavesdrop on private sessions

7.3 Automatic Start-up Wrappers

It is an inconvenience for users to have to login to UNIX and then login to the tabase In some implementations all users login with the same UNIX username and rely on thedatabase’s user registration for security This is never a good idea but often done

application/da-Smarter implementations will match the UNIX username to the database user name and havetools for the database administrator (DBA) to create/remove accounts Adding a user with such

a tool will create a UNIX account and DBMS account simultaneously with an identical word (known as ‘password pass-through’)

pass-“Turnkey” systems try and shield the users from UNIX by logging them straight into the cation Where a system is used in this way it is important that users are not able to break outinto a UNIX shell There are several ways of preventing this The best way of doing this is not

appli-to run a shell at all The application program can be invoked directly by placing the name of theexecutable in the password file instead of a shell

Because, some applications need environmental variables setting up correctly before they can

be run implementors setup the application to run from the user’s “.profile” It would better tocreate a wrapper (shell script) and place it in the user’s default-shell field directly

Interrupting Shell Scripts

It is possible for users to interrupt the processing of shell script and indeed the.profile A usercan quickly type an interrupt signal (such as control C) which will leaving him in his defaultshell To stop this the “.profile” must intercept such interrupts with the “trap” command Alsowhen called from a shell a binary will run in its own shell This shell could also be interrupted

It is possible to prevent this by running the binary without a shell using the “exec” command.e.g.:

%cat.profile trap exit 0 2 3 4 5 6

Even if trap is used as the first line of a shell script, it is possible for a lucky hacker to hit aninterrupt just as the login program starts to read the profile and get in before trap has setup thesignal masks The csh equivalent to “trap” is “onintr” but by default the csh ignores interruptsignals when it is reading the “.login” file In this respect the csh is more secure than the bourneand korn shell.

Many database management systems allow users to spawn a UNIX shell from their menus Thismust also be considered Many UNIX utilities allow the user to execute a shell command fromwithin them An example being the ‘:!sh’ command in vi (See section 15.5 - Back Doors)

7.4 Setuid programs

If an executable file has its setuid bit set then it will run with the “Effective User ID” (EUID)

of the file owner This might seem too powerful a facility and you may question why it is essary?

nec-The user’s real ID (UID) can still be determined Security conscious programs will check theUID to see if it is different to the EUID (See Section 7.5 Setuid Shell Scripts) However theUNIX file system accept EUID credentials in the same way as UID

This facility is often used by multiuser applications to access files owned by others The Oracleserver program is an example of this A simpler example is the “passwd” command We wantusers to be able to change their passwords, which requires “write” access to /etc/shadow How-ever, we do not want them to write anything they like So only root has write access to /etc/shadow If users want to change their password they must run “passwd” with effective user id

of 0:

% ls -l /etc/shadow /usr/bin/passwd -r - 1 root sys 508 Jan 28 15:53 /etc/shadow -s s x 1 root sys 11492 Sep 27 15:35 /usr/bin/passwd

The same facility is available for group access known as set effective group id (EGID)

The setuid/setgid facility is often abused If a hacker cannot become a user (root being the gest prise) then he maybe able to run programs as that user If he can gain an euid of 0 then itspossible, among other things for him to edit the password file and setup his own account withuid of 0

big-7.5 Setuid Shell Scripts

Shell scripts can be made to run EUID and EGID as well as binary files Setuid shell scripts areVERY insecure as it may be possible to interrupt them potentially leaving the user in a shellwith root privileges! Different shell programs handle set EUID in different ways:

Bourne Shell (sh)

The bourne (sh) protect against this hazard By default a bourne shell script will ignore EUIDand EGID by setting them back to UID and GID respectively However this feature can be dis-abled by invoking the shell with the “-p” option

!

!

de-Interactive Setuid Shells

It is even possible to get an interactive shell to effectively run as root One way to do this is tomake a copy of the shell program itself (/usr/bin/sh) Change the ownership to root and changethe permission to setuid Any user who runs this shell will have EUID = 0 This could only bedone as root but there are ways to get a root user to inadvertently run these commands for you(See section 15.1 on Trojan horses and Section 9.4.-NFS Client Security)

It is therefore a good idea to keep a list of all legitimate setuid files and frequently check for theappearance of new ones this can be done with a “find”.The following will list all setuid andsetgid files:

find / -user root \( -perm -4000 -o -perm -2000 \) -ls

The Solaris 2 ASET program does this automatically see section 14.2

7.6 Shared Library Security

Shared libraries are in common use both in Solaris1 and Solaris 2 Their great advantage is thatthey cut down the memory usage Where programs use the same library function they don’teach have to keep their own copy in memory Most of the commands in /usr/bin use shared li-braries These executables are described as being dynamically linked A service called “TheRuntime linker” will connect them to the appropriate shared libraries when they are executed.The ‘ldd’ command can be used to find out which shared libraries a program will use when ex-ecuted:

% ldd /usr/bin/ls libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1

A user could create his own subversive version of these shared libraries and alter his librarypath to point at his version:

% touch /tmp/libc.so.1

!

se-Solaris1 setuid to root programs also ignored LD_LIBRARY_PATH, but it was not so easy tocreate our own programs to do so.

7.7 Hidden directories and files

Public read/write directories suffer from this activity Anonymous-ftp accounts are often used

in this way where hidden directories are used to share software in breach of copyright natively hidden directories might be created in /var/tmp and contain a “hacker toolkit” (See sec-tion 15)

Alter-Where has all the disk space gone?

There is a directory there but you cannot see it The ’ls’ command ignores files beginning with

“.” But this can be over come with ‘ls -a’ option Its a good idea to alias ‘ls’ to “ls -a” to makethis the default for root A classic directory name is <space> A telltale signs is unusual format-ted output such as an extra linefeed when running “ls” A really clever directory name wouldinclude escape sequences to clear the last line of the screen Here are some common examples:

is to run ls -aR while in a script session (/usr/bin/script) The script file can be edited with “vi”which highlight non-printing characters with the quote symbol “^V” Alternatively, use the ‘-b’ option to ‘ls’ to display non-graphic character in octal notation This does not include whitespace characters such as tab, space or linefeed

Missing space could of course be being used by an unlinked inode which is being held open bysome process So don’t get too paranoid! Running fsck can confirm this for you

!

7.8 X11 Security

One of the features of X-based window systems, is to allow users to run their programs on onesystem and display the output on another system This leads to many security implications.OpenWindows3.3 supports two different access control mechanisms: user-based and host-based The older host based mechanisms are used for backward compatibility with earlier X11releases

The host based mechanism is weak because if you grant access to another host then all the users

on that host can access your X-Server The new user-based or authorisation-based mechanismallows you to explicitly grant or deny access to any given NetID (see appendix B)

There are two types of user-based protocols: MIT-MAGIC-COOKIE-1 and SUN-DES-1 TheMIT version is used as default by OpenWindows However SUN-DES-1 is much more secure,

as it uses secure RPCs.(See section 9.1) Here is how you select the authentication mechanismyour require:

“openwin” MAGIC-COOKIE authentication

“openwin -noauth” host based authentication

“openwin -auth sun-des” SUN-DES authentication

With MAGIC-COOKIE access information is kept in a users’ ‘.Xauthority’ file found in theirhome directory This file should be kept read/write by the owner only If someone gains access

to this they gain access to your screen and effectively access to anything you type or view The

“.Xauthority” file can be manipulated by the “xauth” or xhost command Users should be couraged from using the wildcard “+” with these, such as:

dis-%xhost +

Which allows anyone to access the X11 server The xhost command can be used to maintain ahost-based access control list, which is probably sufficient for a workstation (single user) envi-ronment However if a multiuser host/X-terminal environment one of the user-based authenti-cation mechanisms should be used

Autolock Screen

Insisting users logout every time they leave their workstation will meet more opposition fromwindows users than tty users It takes too long to start/stop windows and besides they mightwant to leave something running Rather than rely on users discipline to run “lockscreen” someadministrators mandate that an automatic lock screen program (such as xlocktool) be run in thebackground This will help deter opportunists, but may actually assist serious hackers to obtainpasswords!

The problem being that a user can be given a false sense of security by xlocktool The first thingthe user will do on return to his workstation is type his password to what he assumes is thexlocktool program As he did not personally invoke the lockscreen program he has no proof

!

7.9 Loading files from Media

“Every floppy and tape drive on you network is a potential security hole! “

With distributed systems a tape drive can be connected to any workstation and files loaded ontothe servers from there Most SPARCstations have a floppy drive as standard It might be justi-fiable to stipulate that no client systems with floppy/tape drives should be connect to your net-work

Although not supported, a “lunch-box” tape could be plugged into a Solaris1 workstation andused immediately as all SPARCstations have an external SCSI connector With Solaris2 onlythe root user can do this Solaris2 requires a reboot with the “-r” option before the tape will berecognised and a /dev/rmt device file created Provided the EEPROM is setup correctly onlyroot can do a “boot -r” It is possible to use the “tapes” to create /dev/rmt files attach new tapesbut this also has to be done as root

Tape Archive command “tar”

When new software packages are bought, how often does the installation instruction tell you to

“su” to root then extract the files onto your machine using the “tar” command? This is very gerous as tar will overwrite existing files with new ones You could inadvertently load tamperedversions of key system commands such as /usr/bin/login It is always a good idea to list the con-tents of a tape before loading it The files and directories on the tape should never contain ex-plicit path names like “/usr/bin/prog” Look out for hidden directories If the suggested tarcommand includes the “p” option be even more suspicious, as files will be loaded with pre-de-fined permissions ignoring your umask setting The “w” option is useful as it will stop and askyou if you really want to over write an existing file

dan-good# tar -xvwf /dev/rmt/0 bad# tar -xvfp /dev/rmt/0

x apps/bin/su x /usr/bin/newprog

x /apps/bin/startup x /usr/bin/newprog

It is unlikely that an official release of popular application will contain any hacking tools, if itcomes shrink wrapped from the supplier Its the less well known application or data file thatarrives on a reused tape that presents the question; or indeed an unofficial patch sent to you on

an unlabelled floppy

Volume Manager “Vold”

Only root can mount a floppy disk under Solaris1 Solaris 2 has improved functionality with theVolume Management Software When a floppy disk is inserted into the SPARCstations drive,the volume management daemon will automatically mounts it, providing it contains a UNIX orDOS file system

It is still true that only root can mount/unmount disks Which devices users can mount and withwhat options is defined in the /etc/vold.conf file This should only have write access by root.The volume manager daemon ‘vold’ mounts everything “nosuid” in case the floppy containsany setuid programs

!