1 / 13

Managing Privileged Programs: Attacks, Escalation, and Defenses

This chapter explores the importance of managing privileged programs, including possible attacks on privilege and ways to defend against them. Topics covered include privilege escalation attacks, race conditions, access control, set.uid calls, chroot jails, weak file permissions, and more.

teaston
Download Presentation

Managing Privileged Programs: Attacks, Escalation, and Defenses

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. Privileged Programs Chapter 12

  2. Synopsis • Why Privileged Programs • Possible attacks on privilege • Managing Privilege

  3. Why Privileged Programs? (This chapter is very Unix specific)‏ • Principle of Least Privilege: “Every program and every user should operate using the least set of privileges necesary to complete the job.” • Means no user should have administrator privileges by default. • They only acquire them when they need them, and only when they are running the program that needs the privileges. These programs are privileged programs, aka setuid programs.

  4. Why do we need privileges? • Talking directly to hardware • Modifying the OS behavior • Sending signals to certain processes • Working with shared resources • Opening restricted network ports • Altering global configurations • Overriding filesystem protections • Installing files in system directories • Updating protected files • Accessing files that belong to other users.

  5. Possible attacks on Privilege

  6. Privilege Escalation Attacks and defenses • Often second stage of a two stage attack. • Could also be carried out by a legitimate user. • Will cover: • Race conditions • Access Control • Managing Privilege: set uid calls • Some general advice • Chroot jails • Weak file permissions • Safe directories • Insecure temporary files • Command injection • Misuse of standard file descriptors.

  7. Managing Privilege: set uid calls • Each process has three uid's associated with it: • Real uid – uid of program caller • Effective uid – uid used for access decisions • Saved uid – recoverable uid • Vary from Unix version to unix version. Choose from: • setuid(uid) (sets euid, unless euid = 0)‏ • seteuid(euid)‏ • setreuid(ruid,euid)‏ • setresuid(ruid,euid,suid)‏ • Last two can use -1 to leave value unchanged. • Get with int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);

  8. Privileges for files on linux • Linux provides two additional system calls: • setfsuid(uid_t fsuid); • setfsgid(uid_t fsgid); • They both return the old value of the fsuid/fsgid. • Setting the euid changes the fsuid to that value.

  9. Use of access(2)‏ • Int access(pathname, mode)‏ • Is tempting: check is made against the real uid • Advice: don't use: subject to race conditions: if you want to open a file with privileges of the invoking user, drop privileges temporarily.

  10. Some General Advice • MISTRUST EVERYTHING!!! • Command line arguments • Environment • File System • Race conditions • Weak file permissions • Unsafe directories • Bad temporary files • Bad standard file descriptors • Disable all signals • Trap all signals which would otherwise be ignored • Beware of unexpected events: • Check for EVERY error condition, every return code. • Die on errors

  11. chroot • Changes the meaning of / • Is drastic: anything outside of the new / is unreachable • Use ldd and strace to trace dependencies • Use mknod or MAKEDEV to create necesary devices. • Chroot doesn't close files, or change dir. It can also fail. • NEVER LET THE CHROOTED PROCESS RUN AS ROOT!!!!!

  12. Insecure Directories • The only safe way to do file work is work on safe directories. • A safe directory is a directory of which it and and its ancestors are only writable by root and the process. • Pages 445-446 contain the code to create such a directory

  13. Insecure Temporary Files • Generating file names with mktemp, tmpnam, tempnam is insecure. • The function tmpfile is also insecure, since, if the file exists already, it is only truncated; nothing else is changed. • Mkstemp generates a unique file name, opens it, if it can, with mode 0600 and O_EXCL flag. If it cannot open the file, it returns -1. • Umask of 077 is a good idea, though.

More Related