1 / 15

UNIX Security 2: A Quick Recap

UNIX Security 2: A Quick Recap. SOEN321 - Information Systems Security Revision 1.3 Date: September 30, 2003. Trojan Horse. In UNIX, as in many other OS, there are ways to allow users execution of programs written by other users.

peigi
Download Presentation

UNIX Security 2: A Quick Recap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. UNIX Security 2: A Quick Recap SOEN321 - Information Systems Security Revision 1.3 Date: September 30, 2003 Serguei A. Mokhov, mokhov@cs.concordia.ca

  2. Trojan Horse • In UNIX, as in many other OS, there are ways to allow users execution of programs written by other users. • By having those programs executed in such a way that it provides the access rights of the executing user, the other users may misuse these rights. Serguei A. Mokhov, mokhov@cs.concordia.ca

  3. Trojan Horse (2) • Examples: • A text editor searching for keywords in the open file; upon successful match, copies the document elsewhere. The code that missuses its runtime environment, is called a Trojan Horse. • UNIX path search. We’ll explore this one in greater detail. • A program emulating login. Serguei A. Mokhov, mokhov@cs.concordia.ca

  4. UNIX path • Long search paths, which are very common in UNIX, make Trojan Horse matters worse. • Recall COMP346, Operating Systems... • PA1... “... to set proper Java version change your path to ....” • The users can configure their environment variables in their .cshrc, .tcshrc, .bashrc, whatever, including the path variable. set path=( /usr/ucb /pkg/java-1.2.1/bin /site/bin /usr/bin /usr/sbin \ /bin /usr/hosts /usr/X11R6/bin /sbin /usr/lib \ ~ ~/bin ~/bin/dev ) Serguei A. Mokhov, mokhov@cs.concordia.ca

  5. UNIX path (2) • The search path lists the set of the directories to search when an ambiguous command name given (i.e. not not absolute, which comprises 99% of the commands). • When user types a command in the shell’s prompt, the shell starts looking at every item in the path list, to look up the actual command. • The first command found is executed... Serguei A. Mokhov, mokhov@cs.concordia.ca

  6. UNIX path (3) • Obviously (to whom? :-)), all the directories the path list must be secure; otherwise, a Trojan Horse replacement of a common command can be executed accidentally if it happened to sneak into one of those directories in the path. • A bad habit is to have “.” in your path list. Serguei A. Mokhov, mokhov@cs.concordia.ca

  7. UNIX path (4) • “.” means current directory, so if you type a command, say ls, and a corresponding fake ls happened to be in your current directory, you can get in trouble. • Example: a “friend” shares with you a directory; by being in it and executing a command, you can actually execute the one in your “friend”’s directory which will run as you (with your effective UID) with all your privileges, thereby an ability to copy, delete, modify your files. • The bottom line: never trust your current directory, remove “.” from your path :-) Serguei A. Mokhov, mokhov@cs.concordia.ca

  8. Login Emulation or Why Windows’ Login is More Secure • A Trojan Horse variation is a fake login, i.e. a program emulating login prompt left by an advisory. • An unsuspecting user attempts to login and finds that it failed. Re-attempt - and success... • What had happened? Serguei A. Mokhov, mokhov@cs.concordia.ca

  9. Login Emulation or Why Windows’ Login is More Secure (2) • First time around the login emulator • simply saved the credentials somewhere, • faked incorrect login message, and • exited leaving normal login in place. • To defeat such an attack an OS can print an usage message at the end of interactive session or use some nontrappable key sequence, such as Ctrl+Alt+Del as in Windows NT/2000/XP Serguei A. Mokhov, mokhov@cs.concordia.ca

  10. System Threats: Morris Worm • A worm is a program on its own, a process of which spawning things all over the place causing performance degradation. • Famous The Morris Internet Worm hit UNIX systems (SunOS and VAX) in 1988… Serguei A. Mokhov, mokhov@cs.concordia.ca

  11. Morris Worm • Consisted of two programs – bootstrap and and the main parts. • Bootstrap was uses a grappling hook – a tiny C program compiled and run on every machine it accessed, and used to bring the main one in onto the hooked system. • The main was searching for new ways to propagate from the newly infested system. • The main also used to systematically crack user passwords on the host machine (lame cases, 432-word dictionary, UNIX on-line dictionary) Serguei A. Mokhov, mokhov@cs.concordia.ca

  12. Morris Worm • The worm used the holes in rsh, finger, and sendmail programs (recall the lecture transcript 4) • rsh, an utility for remote command execution didn’t require to use passwords if you had special files with host-login pairs • finger had a typical buffer overflow problem. • sendmail was used to transport the grappling hook thing when sendmail was run in the (default!) debug mode. Serguei A. Mokhov, mokhov@cs.concordia.ca

  13. Morris Worm Serguei A. Mokhov, mokhov@cs.concordia.ca

  14. The Morris Worm • Same tools that contributed to worm’s success, helped to defeat it. • Patched binaries were copied over the infected systems. • Presence of the source code also greatly helped. Serguei A. Mokhov, mokhov@cs.concordia.ca

  15. Viruses • Viruses, unlike worms, are not standalone programs, but embed themselves into already pre-existing program. • Not going to talk about them here, just worth mentioning that there not as many for UNIX as for Windows. • The reason being is UNIX security model, with all those permissions, ACL, etc, if the infected program were to run, not much it can do WRT to the virus prorogation, because it’s capabilities usually limited and there are no write permissions set. • Hint: use crypto as a virus detection mechanism Serguei A. Mokhov, mokhov@cs.concordia.ca

More Related