Preview question In a 32-bit Linux/x86 program, which of these - PDF document

Preview question In a 32-bit Linux/x86 program, which of these objects would have the lowest address (numerically least when CSci 5271 considered as unsigned)? Introduction to Computer Security A. An environment variable Day 3: Low-level vulnerabilities B. The program name in ❛r❣✈❬✵❪ Stephen McCamant C. A command-line argument in ❛r❣✈❬✶❪ University of Minnesota, Computer Science & Engineering D. A local ❢❧♦❛t variable in a function called by ♠❛✐♥ E. A local ❝❤❛r array in ♠❛✐♥ Outline Bad/missing error handling Vulnerabilities in OS interaction Under what circumstances could each system call Low-level view of memory fail? Logistics announcements Careful about rolling back after an error in the middle of a complex operation Basic memory-safety problems Fail to drop privileges ✮ run untrusted code anyway Where overflows come from Update file when disk full ✮ truncate More problems Race conditions Classic races: files in ✴t♠♣ Two actions in parallel; result depends on which Temp filenames must already be unique happens first But “unguessable” is a stronger requirement Usually attacker racing with you Unsafe design ( ♠❦t❡♠♣✭✸✮ ): function to return 1. Write secret data to file unused name 2. Restrict read permissions on file Must use ❖ ❊❳❈▲ for real atomicity Many other examples TOCTTOU gaps TOCTTOU example ✐♥t s❛❢❡❴♦♣❡♥❴❢✐❧❡✭❝❤❛r ✯♣❛t❤✮ ❢ Time-of-check (to) time-of-use races ✐♥t ❢❞ ❂ ✲✶❀ str✉❝t st❛t s❀ 1. Check it’s OK to write to file st❛t✭♣❛t❤✱ ✫s✮ 2. Write to file ✐❢ ✭✦❙ ■❙❘❊●✭s✳st ♠♦❞❡✮✮ Attacker changes the file between steps 1 and 2 ❡rr♦r✭✧♦♥❧② r❡❣✉❧❛r ❢✐❧❡s ❛❧❧♦✇❡❞✧✮❀ Just get lucky, or use tricks to slow you down ❡❧s❡ ❢❞ ❂ ♦♣❡♥✭♣❛t❤✱ ❖ ❘❉❖◆▲❨✮❀ r❡t✉r♥ ❢❞❀ ❣

TOCTTOU example TOCTTOU example ✐♥t s❛❢❡❴♦♣❡♥❴❢✐❧❡✭❝❤❛r ✯♣❛t❤✮ ❢ ✐♥t s❛❢❡❴♦♣❡♥❴❢✐❧❡✭❝❤❛r ✯♣❛t❤✮ ❢ ✐♥t ❢❞ ❂ ✲✶✱ r❡s❀ ✐♥t ❢❞ ❂ ✲✶✱ r❡s❀ str✉❝t st❛t s❀ str✉❝t st❛t s❀ r❡s ❂ st❛t✭♣❛t❤✱ ✫s✮ r❡s ❂ st❛t✭♣❛t❤✱ ✫s✮ ✐❢ ✭r❡s ⑤⑤ ✦❙ ■❙❘❊●✭s✳st ♠♦❞❡✮✮ ✐❢ ✭r❡s ⑤⑤ ✦❙ ■❙❘❊●✭s✳st ♠♦❞❡✮✮ ❡rr♦r✭✧♦♥❧② r❡❣✉❧❛r ❢✐❧❡s ❛❧❧♦✇❡❞✧✮❀ ❡rr♦r✭✧♦♥❧② r❡❣✉❧❛r ❢✐❧❡s ❛❧❧♦✇❡❞✧✮❀ ❡❧s❡ ❢❞ ❂ ♦♣❡♥✭♣❛t❤✱ ❖ ❘❉❖◆▲❨✮❀ ❡❧s❡ ❢❞ ❂ ♦♣❡♥✭♣❛t❤✱ ❖ ❘❉❖◆▲❨✮❀ r❡t✉r♥ ❢❞❀ r❡t✉r♥ ❢❞❀ ❣ ❣ Changing file references Directory traversal with ✳✳ With symbolic links With hard links Program argument specifies file with directory ❢✐❧❡s With changing parent directories What about ❢✐❧❡s✴✳✳✴✳✳✴✳✳✴✳✳✴❡t❝✴♣❛ss✇❞ ? Avoid by instead using: ❢✯ functions that operate on fds ✯❛t functions that use an fd in place of the CWD Environment variables IFS and why it’s a problem In Unix, splitting a command line into words is the Can influence behavior in unexpected ways shell’s job P❆❚❍ String ✦ argv array ▲❉ ▲■❇❘❆❘❨ P❆❚❍ ❣r❡♣ ❛ ❜ ❝ vs. ❣r❡♣ ✬❛ ❜✬ ❝ ■❋❙ Choice of separator characters (default space, tab, . . . newline) is configurable Also umask, resource limits, current directory Exploit s②st❡♠✭✧✴❜✐♥✴✉♥❛♠❡✧✮ Outline Overall layout (Linux 32-bit) Vulnerabilities in OS interaction Low-level view of memory Logistics announcements Basic memory-safety problems Where overflows come from More problems

Detail: static code and data Detail: heap Detail: initial stack Example stack frame Outline Canvas, discussions Vulnerabilities in OS interaction Low-level view of memory Canvas page started, will use for assignment turn-in Logistics announcements Online discussions, including for group formation For spoiler questions, email both me and the TA, Basic memory-safety problems keep CC’d Where overflows come from More problems Finding project topics More on choosing topics Can’t: wait to see what part of class you like best Pre-proposal due 9/18 (one week from today) But feel free to look ahead Don’t skimp on topic selection: important to success Think about your group’s skills Also: available hardware/software Conference papers linked from class site Think about where to find novelty Scheduling grid now available Topic changes allowed, but will set you back

Outline Stack frame overflow Vulnerabilities in OS interaction Low-level view of memory Logistics announcements Basic memory-safety problems Where overflows come from More problems Overwriting adjacent objects Overwriting metadata Forward or backward on stack On stack: Other local variables, arguments Return address Fields within a structure Saved registers, incl. frame pointer On heap: Global variables Size and location of adjacent blocks Other heap objects Double free Use after free Passing the same pointer value to ❢r❡❡ more than AKA use of a dangling pointer once Could overwrite heap metadata More dangerous the more other heap operations Or, access data with confused type occur in between Outline Library funcs: unusable Vulnerabilities in OS interaction Low-level view of memory ❣❡ts writes unlimited data into supplied buffer Logistics announcements No way to use safely (unless stdin trusted) Basic memory-safety problems Finally removed in C11 standard Where overflows come from More problems

Library funcs: dangerous Library funcs: bounded Just add “n”: Big three unchecked string functions str♥❝♣②✭❞❡st✱ sr❝✱ ♥✮ str❝♣②✭❞❡st✱ sr❝✮ str❝❛t✭❞❡st✱ sr❝✮ str♥❝❛t✭❞❡st✱ sr❝✱ ♥✮ s♣r✐♥t❢✭❜✉❢✱ ❢♠t✱ ✳✳✳✮ s♥♣r✐♥t❢✭❜✉❢✱ s✐③❡✱ ❢♠t✱ ✳✳✳✮ Tricky points: Must know lengths in advance to use safely Buffer size vs. max characters to write (complicated for s♣r✐♥t❢ ) Failing to terminate Similar pattern in other funcs returning a string str♥❝♣② zero-fill More library attempts Still a problem: truncation OpenBSD str❧❝♣② , str❧❝❛t Unexpectedly dropping characters from the end of Easier to use safely than “n” versions Non-standard, but widely copied strings may still be a vulnerability Microsoft-pushed str❝♣② s , etc. E.g., if attacker pads paths with ✴✴✴✴✴✴✴ or Now standardized in C11, but not in glibc ✴✳✴✳✴✳✴✳ Runtime checks that ❛❜♦rt Avoiding length limits is best, if implemented Compute size and use ♠❡♠❝♣② correctly C++ st❞✿✿str✐♥❣ , glib, etc. Off-by-one bugs Even more buffer/size mistakes Inconsistent code changes (use s✐③❡♦❢ ) str❧❡♥ does not include the terminator Misuse of s✐③❡♦❢ (e.g., on pointer) Comparison with ❁ vs. ❁❂ Bytes vs. wide chars (UCS-2) vs. multibyte chars Length vs. last index (UTF-8) ①✰✰ vs. ✰✰① OS length limits (or lack thereof) Other array problems Outline Vulnerabilities in OS interaction Low-level view of memory Missing/wrong bounds check One unsigned comparison suffices Logistics announcements Two signed comparisons needed Basic memory-safety problems Beware of clever loops Premature optimization Where overflows come from More problems

Integer overflow Integer overflow example Fixed size result ✻ ❂ math result Sum of two positive ✐♥t s negative or less than ✐♥t ♥ ❂ r❡❛❞❴✐♥t✭✮❀ addend ♦❜❥ ✯♣ ❂ ♠❛❧❧♦❝✭♥ ✯ s✐③❡♦❢✭♦❜❥✮✮❀ ❢♦r ✭✐ ❂ ✵❀ ✐ ❁ ♥❀ ✐✰✰✮ Also multiplication, left shift, etc. ♣❬✐❪ ❂ r❡❛❞❴♦❜❥✭✮❀ Negation of most-negative value ✭❧♦✇ ✰ ❤✐❣❤✮✴✷ Signed and unsigned Mixing integer sizes Complicated rules for implicit conversions Unsigned gives more range for, e.g., s✐③❡ t Also includes signed vs. unsigned At machine level, many but not all operations are the Generally, convert before operation: same E.g., ✶❯▲▲ ❁❁ ✻✸ Most important difference: ordering Sign-extend vs. zero-extend In C, signed overflow is undefined behavior ❝❤❛r ❝ ❂ ✵①❢❢❀ ✭✐♥t✮❝ Null pointers Undefined behavior C standard “undefined behavior”: anything could Vanilla null dereference is usually non-exploitable happen (just a DoS) Can be unexpectedly bad for security But not if there could be an offset (e.g., field of struct) Most common problem: compiler optimizes And not in the kernel if an untrusted user has assuming undefined behavior cannot happen allocated the zero page Linux kernel example Format strings ♣r✐♥t❢ format strings are a little interpreter str✉❝t s♦❝❦ ✯s❦ ❂ t✉♥✲❃s❦❀ ♣r✐♥t❢✭❢♠t✮ with untrusted ❢♠t lets the attacker ✴✴ ✳✳✳ program it ✐❢ ✭✦t✉♥✮ Allows: r❡t✉r♥ P❖▲▲❊❘❘❀ Dumping stack contents ✴✴ ♠♦r❡ ✉s❡s ♦❢ t✉♥ ❛♥❞ s❦ Denial of service Arbitrary memory modifications!