Lecture Securing Unix

1. Lecture Securing Unix CSCE 517 Forensic Computing • Topics • Trusted Unix Releases • Unix Security Risks • Set-uid • Buffer Overflow Problems July 1, 2003

2. Unix Wrapup • Password file structure • Group file • Superuser • su • sudo • setuid • guid • Buffer Overflow • http://secinf.net/uparticle/l/p49-14.txt

3. Unix History • 1965 Multics Operating Systems project, a multiuser, multiple concurrent users, data sharing • 1969 Ken Thompson at Bell Labs developed an operating system he called Unix (a pun on Multics) • 1970 Dennis Ritchie developed the language C and a compiler for it. Thompson wrote the second version of Unix largely in C (90% C 10% assembly language) • Late 1970’s - Bell Labs effectively gave away Unix to universities • BSD (Berkeley Software Division) branch • 1991 Linux - a graduate student, Linus Torvalds, implemented an open source version of Unix • http://www.levenez.com/unix/

4. Open Source Systems • Unix was almost the first open-source, but Bell Labs really retained some of the rights • GNU Free Software Foundation • Gnu emacs – Richard Stallman • gcc - gnu c compiler • Linux • Red Hat • Mandrake … • Open BSD a “hardened” system

5. OpenBSD • Derived from BSD branch • Pays special attention to security issues • Security Benefits • “Out-of-the-box” hardened system configuration; no effort • Strong Cryptography up and ready • OpenSSH – remote secure shell (secure “telnet”) • IPSec - • Strong PRNG (Pseudo Random Number Generator) • http://www.openbsd.org • Standard Linux releases can be configured “hardened” but OpenBSD comes that way.

6. OpenSSH • The problem with telnet – • SSH – Secure Shell, … • “What is Secure Shell” FAQ • http://www.employees.org/~satch/ssh/faq • Is it a Protocol or Program?

7. OpenSSH Servers and Clients • SSH servers • OpenSSH Project • SSH Clients • Putty • https://www.cse.sc.edu/FTP • Lists: http://www.ece.nwu.edu/~mack23/ssh-clients.html http://www.freessh.org • SCP – secure copy, http://www.I-tree.org • SSH Resources • Implementation – Univ Florida paper • http://www.boran.com/security/sp/ssh-part1.html

8. SSH Implementation

9. IPSec

10. Strong PRNG • Strong PRNG (Pseudo Random Number Generator)

11. Multilevel Trusted Systems • http://www.sei.cmu.edu/str/descriptions/trusted_body.html • Principles of trusted operating systems (TOS) • The principle of least privilege • Mandatory Access Controls – a means of restricting access to objects based on the sensitivity of the information • Privilege bracketing – enabling and disabling privilege around the smallest section of code that really needs it • Trusted Solaris • Trusted BSD • NSA (National Security Agency) • http://www.nsa.gov/selinux/index.html

12. Unix Security Risks • Poorly chosen passwords • Ref • Old/misconfigured/buggy network daemons • Use of telnet, ftp, rsh, … • Buggy privileged programs (setuid/setgid) • Filesystem nightmares • Insecure applications

13. Unix Password Structure • Original Scheme • /etc/passwd • Format login:encryptedPassword: • Commands that access name info: Who, ls, finger • crypt

14. Shadow Passwords • A number of useful Unix commands make use of much of the information in the password file. • But, why does the encrypted password need to be there? • It doesn’t move this to /etc/shadow that only root can read!

15. Password Common Sense • Use good strong ones! • http:// • Modified Phrase Acronyms (keep punctuation, insert special) “I left my heart in San Francisco”  !lmyi$F • Educate Users on common mistakes • Ref • Shear idiocy: Blank, Login, loginReversed • Other Simple ones • Check up on users • Dictionary checks • Use proactive password checkers • Check the password as entered for quality

16. Password Procedures • Enforce lock down after 3 to 5 failures • Help Desk “password reset” procedures • Help desk call - “this is Dean White reset my password!” • Procedures: phone back at preset number or voicemail • Don’t reset password always to the same value or to a value that is a function of the user (Soc-Sec) • Use phonetic password generator – so they can be pronounced over the phone • Password Station - electronic reset of passwords http://www.passwordstation.net • Avoid hardcoding passwords in scripts!

17. Set UID / Set GID • The Need • Consider the problem of a user changing their password. • How can they be allowed to write the entry in the file /etc/shadow? • This would mean they could change other user’s passwords. • Setuid – • Normally when a program runs it runs as the user that started it • A setuid program “changes the user id” to the owner of the file that contains the program • ls –l /bin/passwd • Thus /bin/passwd runs with the priviledges of “root” • chmod 01755 file ???

18. Set UID / Set GID • Set UID programs are necessary • No passwd command  System Admin called each time a password is changed !? • Set UID files • Extreme care must be used in their implementation • One failure of a setuid application  game over, the attacker has root priviledge • http://www.safermag.com/html/safer25/alerts/33.html • Set-gid wrinkles • Works the same way but • Can be set on a directory, which inherited by each file in the subtree.

19. Exploiting Set UID Programs • Skeleton of a setuid program • Non-priviledged section code • Setuid system call • priviledged section code • Restore uid with another setuid syscall • Non-priviledged section code • Note the problem is not just writing secure priviledged sections, because a problem in the non-priviledged section can lead to another setuid call ! • A buffer overflow anywhere in a setuid program can result in someone becoming root. • Setuid, exec shell

20. Set UID Programs • Unix systems ship with typically 70-100 setuid programs • Passwrd, ping … • SecurityFocus.com • BugTraq reports of new setuid problems • So what is a Systems Administrator to do? • Setuid lock-down tips • Solaris http://ist.uwaterloo.ca/security/howto/2000-08-17 • Linux

21. Set UID Lockdowns • Avoid installing the full installation • List set uid/set gid programs • find / -perm –u+s –print • find / -perm –g+s –print • For those that only root needs to run remove setuid bit • Identify setuid programs that leak information • Ps, top, netstat • Identify setuid programs that only a trusted group needs; remove access to “others” • Identify those that you think no one will ever need. • AUSCERT wrapper • For essential ones modify the AUSCERT wrapper • Don’t accept long arguments or environment variables

22. Breaking Set UID Programs for Fun and Profit

23. Umask • What are the default permissions set on a file when it is created? • The umask is an mask that is used to mask out bits in the permissions. • e.g. if umask is 023 then • Group – 2 = 010  ‘w’ is masked out • Others – 3 = 011  ‘w’ and ‘x’ are masked out • Umask manipulation • Umask command – can be run at prompt but usually in setup scripts • Common default 022 • Frequently set in /etc/profile

24. Umask Dangers • In Unix the way one process creates another is using the system call fork. • Umask is inherited across forks • Init is the process that creates various “login processes” which create the shells, which create user files • If init has has too loose of a umask then too many files will be readable.

25. Chroot for servers

26. Caveats of Chroot • Not a virtual computer; it’s a filesystem abstraction • Escape from chroot jail • If process has root access the game is over. To Break out first create devices to access memory directly then modify the process’s idea of the root directory • http://www.bpfh.net/simes/computing/chroot-break.html • User Mode Linux (UML) – • http://user-mode-linux.sourceforge.net/

27. Root Privileges • Managing the password of root • Use a strong password • Never let a naïve or reckless user have the password. • Disable remote root logins • Use su to gain root access • Su – switch user

28. Sudo • Use to permit/control access to privileged programs • e.g., sudo ethereal

29. Rootkit Countermeasures • http://www.tripwire.org • http://www.kernelhacking.org • http://packetstormsecurity.nl/Unix/penetration/rootkits • LKM support

30. R-Services • TCP ports 513 and 514 • rlogind • rshd • r-Services Risks • Just don’t use them or telnet or FTP! Use SSH

31. Assessing Vulnerabilities of a Unix System • Use network based scanner tool to identify remotely exploitable security holes (e.g., Nessus discussed later) • Prioritize by risk analysis • Draw up and execute plan for fixing the problems • Use network based scanner tool to identify locally exploitable security holes • Identify biggest risks and get to work. • Scanners, Intrusion Detection Systems, etc. later

32. Unix Host Lockdown • Host lockdown is the process of making a system compliant with the established security policy • Approaches • Manually make the changes • Develop a script or scripts to automate the changes • Use a hardening tool • Host hardening tools • YASSP (Yet Another Solaris Security Package) http://www.yassp.org • TITAN http://www.fish.com/titan • Bastille Unix http://www.bastille-linux.org/

33. Buffer Overflow Problems • A lot of well known attacks on systems take advantage of buffer overflows • Activation Stack – stores local variables, return address for each separate function call

34. IA32/Linux Stack Frame • Current Stack Frame (“Top” to Bottom) • Parameters for function about to call • “Argument build” • Local variables • If can’t keep in registers • Saved register context • Old frame pointer • Caller Stack Frame • Return address • Pushed by call instruction • Arguments for this call Caller Frame Arguments Frame Pointer (%ebp) Return Addr Old %ebp Saved Registers + Local Variables Argument Build Stack Pointer (%esp)

35. Stack Frame for main Return Address Saved %ebp %ebp [3] [2] [1] [0] buf Stack Frame for echo Buffer Overflow Stack /* Echo Line */void echo(){ char buf[4]; /* Way too small! */ gets(buf); puts(buf);} echo: pushl %ebp # Save %ebp on stack movl %esp,%ebp subl $20,%esp # Allocate space on stack pushl %ebx # Save %ebx addl $-12,%esp # Allocate space on stackleal -4(%ebp),%ebx # Compute buf as %ebp-4 pushl %ebx # Push buf on stack call gets # Call gets . . .

36. Malicious Use of Buffer Overflow Stack after call to gets() • Input string contains byte representation of executable code • Overwrite return address with address of buffer • When bar() executes ret, will jump to exploit code void foo(){ bar(); ... } foo stack frame return address A B data written by gets() pad void bar() { char buf[4]; gets(buf); ... } exploit code bar stack frame B

37. Buffer Overflow Ex. foo RA • Activation Record for bar() • Arguments • Return address (4 bytes) • Local variables • buf[4] • How do you get foo to return somewhere other than 04100000? • Is this Big or Little Endian? buf[3] buf[2] buf[1] buf[0] bar RA

38. Avoiding Overflow Vulnerability • Use Library Routines that Limit String Lengths • fgets instead of gets • strncpy instead of strcpy • Don’t use scanf with %s conversion specification • Use fgets to read the string /* Echo Line */void echo(){ char buf[4]; /* Way too small! */ fgets(buf, 4, stdin); puts(buf);}

39. Avoiding Buffer Overflow Attacks • Immunix • Developed a modified compiler, StackGuard • Linux Kernel patches • System Call Wrappers

40. Buffer Overflow References-HowTo • “Compromised-Buffer-Overflows, from Intel to SPARC Version 8” by Mudge from “@Stake” • http://www.astake.com/research/advisories/1996/bufitos.pdf • “The Tao of Windows Buffer Overflow” by Dildog again from @Stake • http://www.cultdeadcow.com/cDc_files/cDc-351 • ”Smashing the Stack for Fun and Profit” by Aleph1 of SecurityFocus.com, Issue 49 of Phrack • http://www.shmoo.com/phrack/Phrack49/p49-14

41. Summary