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 considered as unsigned)? CSci 5271 A. An environment variable Introduction to Computer Security B. The program name in ❛r❣✈❬✵❪ Day 3: Low-level vulnerabilities C. A command-line argument in ❛r❣✈❬✶❪ Stephen McCamant 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 Low-level view of memory system call fail? Careful about rolling back after an error Logistics announcements in the middle of a complex operation Basic memory-safety problems Fail to drop privileges ✮ run untrusted Where overflows come from code anyway Update file when disk full ✮ truncate More problems Race conditions Classic races: files in ✴t♠♣ Two actions in parallel; result depends Temp filenames must already be unique on which happens first But “unguessable” is a stronger Usually attacker racing with you requirement 1. Write secret data to file Unsafe design ( ♠❦t❡♠♣✭✸✮ ): function to 2. Restrict read permissions on file return unused name Many other examples Must use ❖ ❊❳❈▲ for real atomicity

TOCTTOU gaps TOCTTOU example Time-of-check (to) time-of-use races ✐♥t s❛❢❡❴♦♣❡♥❴❢✐❧❡✭❝❤❛r ✯♣❛t❤✮ ❢ ✐♥t ❢❞ ❂ ✲✶❀ 1. Check it’s OK to write to file str✉❝t st❛t s❀ 2. Write to file st❛t✭♣❛t❤✱ ✫s✮ Attacker changes the file between ✐❢ ✭✦❙ ■❙❘❊●✭s✳st ♠♦❞❡✮✮ steps 1 and 2 ❡rr♦r✭✧♦♥❧② r❡❣✉❧❛r ❢✐❧❡s ❛❧❧♦✇❡❞✧✮❀ ❡❧s❡ ❢❞ ❂ ♦♣❡♥✭♣❛t❤✱ ❖ ❘❉❖◆▲❨✮❀ Just get lucky, or use tricks to slow r❡t✉r♥ ❢❞❀ you down ❣ 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 Program argument specifies file with With hard links directory ❢✐❧❡s With changing parent directories What about Avoid by instead using: ❢✐❧❡s✴✳✳✴✳✳✴✳✳✴✳✳✴❡t❝✴♣❛ss✇❞ ? ❢✯ 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 Can influence behavior in unexpected In Unix, splitting a command line into ways words is the 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 Exploit s②st❡♠✭✧✴❜✐♥✴✉♥❛♠❡✧✮ directory 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 Canvas page started, will use for Low-level view of memory assignment turn-in Logistics announcements Online discussions, including for group formation Basic memory-safety problems For spoiler questions, email both me Where overflows come from and the TA, keep CC’d More problems Finding project topics More on choosing topics Can’t: wait to see what part of class Pre-proposal due 9/18 (one week from you like best today) But feel free to look ahead Don’t skimp on topic selection: Think about your group’s skills important to success Also: available hardware/software Conference papers linked from class Think about where to find novelty site Topic changes allowed, but will set you Scheduling grid now available 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 AKA use of a dangling pointer ❢r❡❡ more than once Could overwrite heap metadata More dangerous the more other heap Or, access data with confused type operations occur in between

Outline Library funcs: unusable Vulnerabilities in OS interaction ❣❡ts writes unlimited data into supplied Low-level view of memory buffer Logistics announcements No way to use safely (unless stdin Basic memory-safety problems trusted) Where overflows come from Finally removed in C11 standard More problems Library funcs: dangerous Library funcs: bounded Big three unchecked string functions Just add “n”: str❝♣②✭❞❡st✱ sr❝✮ str♥❝♣②✭❞❡st✱ sr❝✱ ♥✮ str❝❛t✭❞❡st✱ sr❝✮ str♥❝❛t✭❞❡st✱ sr❝✱ ♥✮ s♣r✐♥t❢✭❜✉❢✱ ❢♠t✱ ✳✳✳✮ s♥♣r✐♥t❢✭❜✉❢✱ s✐③❡✱ ❢♠t✱ ✳✳✳✮ Must know lengths in advance to use Tricky points: safely (complicated for s♣r✐♥t❢ ) Buffer size vs. max characters to write Failing to terminate Similar pattern in other funcs returning str♥❝♣② zero-fill a string More library attempts Still a problem: truncation OpenBSD str❧❝♣② , str❧❝❛t Unexpectedly dropping characters from Easier to use safely than “n” versions the end of strings may still be a Non-standard, but widely copied vulnerability Microsoft-pushed str❝♣② s , etc. E.g., if attacker pads paths with Now standardized in C11, but not in glibc ✴✴✴✴✴✴✴ or ✴✳✴✳✴✳✴✳ Runtime checks that ❛❜♦rt Compute size and use ♠❡♠❝♣② Avoiding length limits is best, if implemented correctly C++ st❞✿✿str✐♥❣ , glib, etc.

Off-by-one bugs Even more buffer/size mistakes Inconsistent code changes (use str❧❡♥ does not include the terminator s✐③❡♦❢ ) Comparison with ❁ vs. ❁❂ Misuse of s✐③❡♦❢ (e.g., on pointer) Length vs. last index Bytes vs. wide chars (UCS-2) vs. multibyte chars (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 ✐♥t ♥ ❂ r❡❛❞❴✐♥t✭✮❀ less than addend ♦❜❥ ✯♣ ❂ ♠❛❧❧♦❝✭♥ ✯ s✐③❡♦❢✭♦❜❥✮✮❀ ❢♦r ✭✐ ❂ ✵❀ ✐ ❁ ♥❀ ✐✰✰✮ Also multiplication, left shift, etc. ♣❬✐❪ ❂ r❡❛❞❴♦❜❥✭✮❀ Negation of most-negative value ✭❧♦✇ ✰ ❤✐❣❤✮✴✷

Signed and unsigned Mixing integer sizes Unsigned gives more range for, e.g., Complicated rules for implicit s✐③❡ t conversions Also includes signed vs. unsigned At machine level, many but not all Generally, convert before operation: operations are the same E.g., ✶❯▲▲ ❁❁ ✻✸ Most important difference: ordering Sign-extend vs. zero-extend In C, signed overflow is undefined ❝❤❛r ❝ ❂ ✵①❢❢❀ ✭✐♥t✮❝ behavior Null pointers Undefined behavior C standard “undefined behavior”: Vanilla null dereference is usually anything could happen non-exploitable (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 assuming undefined behavior And not in the kernel if an untrusted cannot happen user has 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!