Outline Vulnerabilities in OS interaction Low-level view of memory - PDF document

Outline Vulnerabilities in OS interaction Low-level view of memory CSci 5271 Introduction to Computer Security Logistics announcements Day 3: Low-level vulnerabilities Basic memory-safety problems Stephen McCamant Where overflows come from University of Minnesota, Computer Science & Engineering 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 HA1 virtual machines Vulnerabilities in OS interaction Ubuntu 16.04 server, hosted on CSE Labs Low-level view of memory 64-bit kernel but 32-bit BCMTA, ❣❝❝ ✲♠✸✷ Logistics announcements One VM per group (up to 2 students) Basic memory-safety problems For allocation, send group list to Aditya Where overflows come from ♣❛❦❦✐✵✵✶❅✉♠♥✳❡❞✉ Don’t put off until the last minute More problems Other parts of HA1 Exercise set 1 Instructions will be on the Assignments Available on website area of course web page Due Wednesday, February 13th, on But BCMTA is not ready yet, so first Canvas due date will be delayed Groups of 1-2, turn in one copy Nothing due before next Wednesday, no hidden vulnerability before next Friday Canvas, discussions Finding project topics Canvas page started, will use for Pre-proposal due 2/6 (one week from assignment turn-in Wednesday) Online discussions, including for group Don’t skimp on topic selection: formation important to success For spoiler questions, email both me Conference papers linked from class and the TA, keep CC’d site

More on choosing topics Outline Vulnerabilities in OS interaction Can’t: wait to see what part of class you like best Low-level view of memory But feel free to look ahead Logistics announcements Think about your group’s skills Also: available hardware/software Basic memory-safety problems Think about where to find novelty Where overflows come from Topic changes allowed, but will set you More problems back Stack frame overflow Overwriting adjacent objects Forward or backward on stack Other local variables, arguments Fields within a structure Global variables Other heap objects Overwriting metadata Double free On stack: Passing the same pointer value to Return address ❢r❡❡ more than once Saved registers, incl. frame pointer More dangerous the more other heap On heap: operations occur in between Size and location of adjacent blocks

Use after free Outline Vulnerabilities in OS interaction Low-level view of memory AKA use of a dangling pointer Logistics announcements Could overwrite heap metadata Basic memory-safety problems Or, access data with confused type Where overflows come from More problems Library funcs: unusable Library funcs: dangerous Big three unchecked string functions str❝♣②✭❞❡st✱ sr❝✮ ❣❡ts writes unlimited data into supplied str❝❛t✭❞❡st✱ sr❝✮ buffer s♣r✐♥t❢✭❜✉❢✱ ❢♠t✱ ✳✳✳✮ No way to use safely (unless stdin Must know lengths in advance to use trusted) safely (complicated for s♣r✐♥t❢ ) Finally removed in C11 standard Similar pattern in other funcs returning a string Library funcs: bounded More library attempts OpenBSD str❧❝♣② , str❧❝❛t Just add “n”: Easier to use safely than “n” versions str♥❝♣②✭❞❡st✱ sr❝✱ ♥✮ Non-standard, but widely copied str♥❝❛t✭❞❡st✱ sr❝✱ ♥✮ Microsoft-pushed str❝♣② s , etc. s♥♣r✐♥t❢✭❜✉❢✱ s✐③❡✱ ❢♠t✱ ✳✳✳✮ Now standardized in C11, but not in glibc Tricky points: Runtime checks that ❛❜♦rt Buffer size vs. max characters to write Compute size and use ♠❡♠❝♣② Failing to terminate str♥❝♣② zero-fill C++ st❞✿✿str✐♥❣ , glib, etc.

Still a problem: truncation Off-by-one bugs Unexpectedly dropping characters from the end of strings may still be a str❧❡♥ does not include the terminator vulnerability Comparison with ❁ vs. ❁❂ E.g., if attacker pads paths with Length vs. last index ✴✴✴✴✴✴✴ or ✴✳✴✳✴✳✴✳ ①✰✰ vs. ✰✰① Avoiding length limits is best, if implemented correctly Even more buffer/size mistakes Other array problems Inconsistent code changes (use Missing/wrong bounds check s✐③❡♦❢ ) One unsigned comparison suffices Misuse of s✐③❡♦❢ (e.g., on pointer) Two signed comparisons needed Bytes vs. wide chars (UCS-2) vs. Beware of clever loops multibyte chars (UTF-8) Premature optimization OS length limits (or lack thereof) Outline Integer overflow Vulnerabilities in OS interaction Fixed size result ✻ ❂ math result Low-level view of memory Sum of two positive ✐♥t s negative or Logistics announcements less than addend Also multiplication, left shift, etc. Basic memory-safety problems Negation of most-negative value Where overflows come from ✭❧♦✇ ✰ ❤✐❣❤✮✴✷ More problems

Integer overflow example Signed and unsigned Unsigned gives more range for, e.g., s✐③❡ t ✐♥t ♥ ❂ r❡❛❞❴✐♥t✭✮❀ At machine level, many but not all ♦❜❥ ✯♣ ❂ ♠❛❧❧♦❝✭♥ ✯ s✐③❡♦❢✭♦❜❥✮✮❀ operations are the same ❢♦r ✭✐ ❂ ✵❀ ✐ ❁ ♥❀ ✐✰✰✮ Most important difference: ordering ♣❬✐❪ ❂ r❡❛❞❴♦❜❥✭✮❀ In C, signed overflow is undefined behavior Mixing integer sizes Null pointers Complicated rules for implicit Vanilla null dereference is usually conversions non-exploitable (just a DoS) Also includes signed vs. unsigned But not if there could be an offset (e.g., Generally, convert before operation: field of struct) E.g., ✶❯▲▲ ❁❁ ✻✸ And not in the kernel if an untrusted Sign-extend vs. zero-extend user has allocated the zero page ❝❤❛r ❝ ❂ ✵①❢❢❀ ✭✐♥t✮❝ Undefined behavior Linux kernel example C standard “undefined behavior”: str✉❝t s♦❝❦ ✯s❦ ❂ t✉♥✲❃s❦❀ anything could happen ✴✴ ✳✳✳ Can be unexpectedly bad for security ✐❢ ✭✦t✉♥✮ Most common problem: compiler r❡t✉r♥ P❖▲▲❊❘❘❀ optimizes assuming undefined behavior ✴✴ ♠♦r❡ ✉s❡s ♦❢ t✉♥ ❛♥❞ s❦ cannot happen