Preview question Which of the following is not always true, when the - PDF document

Preview question Which of the following is not always true, when the variables are interpreted as 32-bit unsigned ✐♥t s in C? CSci 5271 A. ①✯② is odd, if both ① and ② are odd Introduction to Computer Security Low-level vulnerabilities and attacks B. ①✯② ❂❂ ②✯① Stephen McCamant C. ① ✰ ① ✰ ① ✰ ① ❂❂ ✹✯① University of Minnesota, Computer Science & Engineering D. ✶✻✯① ❃❂ ① E. ① ✰ ✭✲①✮ ❂❂ ✵ Outline More library attempts Where overflows come from (cont’d) OpenBSD str❧❝♣② , str❧❝❛t Easier to use safely than “n” versions More low-level problems Non-standard, but widely copied Classic code injection attacks Microsoft-pushed str❝♣② s , etc. Now standardized in C11, but not in glibc Announcements intermission Runtime checks that ❛❜♦rt Shellcode techniques Compute size and use ♠❡♠❝♣② Exploiting other vulnerabilities C++ st❞✿✿str✐♥❣ , glib, etc. Still a problem: truncation Off-by-one bugs Unexpectedly dropping characters from the end of str❧❡♥ does not include the terminator strings may still be a vulnerability Comparison with ❁ vs. ❁❂ E.g., if attacker pads paths with ✴✴✴✴✴✴✴ or Length vs. last index ✴✳✴✳✴✳✴✳ ①✰✰ vs. ✰✰① Avoiding length limits is best, if implemented correctly Even more buffer/size mistakes Other array problems Inconsistent code changes (use s✐③❡♦❢ ) Missing/wrong bounds check Misuse of s✐③❡♦❢ (e.g., on pointer) One unsigned comparison suffices Two signed comparisons needed Bytes vs. wide chars (UCS-2) vs. multibyte chars Beware of clever loops (UTF-8) Premature optimization OS length limits (or lack thereof)

Outline Integer overflow Where overflows come from (cont’d) Fixed size result ✻ ❂ math result More low-level problems Sum of two positive ✐♥t s negative or less than Classic code injection attacks addend Announcements intermission Also multiplication, left shift, etc. Negation of most-negative value Shellcode techniques ✭❧♦✇ ✰ ❤✐❣❤✮✴✷ Exploiting other vulnerabilities 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 operations are the ♦❜❥ ✯♣ ❂ ♠❛❧❧♦❝✭♥ ✯ s✐③❡♦❢✭♦❜❥✮✮❀ same ❢♦r ✭✐ ❂ ✵❀ ✐ ❁ ♥❀ ✐✰✰✮ Most important difference: ordering ♣❬✐❪ ❂ r❡❛❞❴♦❜❥✭✮❀ In C, signed overflow is undefined behavior Mixing integer sizes Null pointers Complicated rules for implicit conversions Vanilla null dereference is usually non-exploitable Also includes signed vs. unsigned (just a DoS) Generally, convert before operation: But not if there could be an offset (e.g., field of struct) E.g., ✶❯▲▲ ❁❁ ✻✸ And not in the kernel if an untrusted user has Sign-extend vs. zero-extend allocated the zero page ❝❤❛r ❝ ❂ ✵①❢❢❀ ✭✐♥t✮❝ Undefined behavior Linux kernel example C standard “undefined behavior”: anything could str✉❝t s♦❝❦ ✯s❦ ❂ t✉♥✲❃s❦❀ happen ✴✴ ✳✳✳ Can be unexpectedly bad for security ✐❢ ✭✦t✉♥✮ Most common problem: compiler optimizes r❡t✉r♥ P❖▲▲❊❘❘❀ assuming undefined behavior cannot happen ✴✴ ♠♦r❡ ✉s❡s ♦❢ t✉♥ ❛♥❞ s❦

Format strings Outline Where overflows come from (cont’d) ♣r✐♥t❢ format strings are a little interpreter More low-level problems ♣r✐♥t❢✭❢♠t✮ with untrusted ❢♠t lets the attacker Classic code injection attacks program it Allows: Announcements intermission Dumping stack contents Shellcode techniques Denial of service Arbitrary memory modifications! Exploiting other vulnerabilities Overwriting the return address Collateral damage Collateral damage Other code injection targets Function pointers Stop the program from crashing early Local, global, on heap ‘Overwrite’ with same value, or another legal one ❧♦♥❣❥♠♣ buffers GOT (PLT) / import tables Minimize time between overwrite and use Exception handlers Indirect overwrites Non-sequential writes Change a data pointer used to access a code E.g. missing bounds check, corrupted pointer pointer Can be more flexible and targeted Easiest if there are few other uses E.g., a write-what-where primitve Common examples More likely needs an absolute location Frame pointer May have less control of value written C++ object vtable pointer

Unexpected-size writes Outline Where overflows come from (cont’d) More low-level problems Attacks don’t need to obey normal conventions Classic code injection attacks Overwrite one byte within a pointer Announcements intermission Use mis-aligned word writes to isolate a byte Shellcode techniques Exploiting other vulnerabilities Memory layout question Project meeting scheduling In a 32-bit Linux/x86 program, which of these objects would have the lowest address (numerically least when For pre-proposal due Wednesday night: considered as unsigned)? Will pick a half-hour meeting slot, use for three A. An environment variable different meetings B. The program name in ❛r❣✈❬✵❪ List of about 70 slots on the web page C. A command-line argument in ❛r❣✈❬✶❪ Choose ordered list in pre-proposal, length inverse to popularity D. A local ❢❧♦❛t variable in a function called by ♠❛✐♥ E. A local ❝❤❛r array in ♠❛✐♥ HA1 materials posted Getting your virtual machines Ubuntu 16.04 server, hosted on CSE Labs Instructions PDF 64-bit kernel but 32-bit BCMTA, ❣❝❝ ✲♠✸✷ BCMTA source code One VM per group (up to 3 students) VM instructions web page For allocation, send group list to Travis Discussion and submissions on Canvas Don’t put off until the last minute Sequence of exploits Types of vulnerabilities Week 1 (9/20): bad feature, 10 points OS interaction/logic errors Week 2 (9/27): easier, 20 points Memory safety errors Week 3 (10/4): harder, 30 points E.g., exploit with control-flow hijacking Week 4 (10/11): harder, 30 points Command-line and server modes available Plus, design suggestions (10 points) Week 5 (10/18): hardest, ✶✵ ✁ ♥ extra credit

Part of challenge: automation Outline Where overflows come from (cont’d) Must represent your attack as an exploit script More low-level problems Must be fully automatic Classic code injection attacks No user interaction Works reliably, within 60 seconds Announcements intermission Must work on a clean VM Shellcode techniques Use t❡st✲❡①♣❧♦✐t script Exploiting other vulnerabilities Basic definition Classic execve ✴❜✐♥✴s❤ Shellcode: attacker supplied instructions ❡①❡❝✈❡✭❢♥❛♠❡✱ ❛r❣✈✱ ❡♥✈♣✮ system call implementing malicious functionality Specialized syscall calling conventions Name comes from example of starting a shell Omit unneeded arguments Often requires attention to machine-language Doable in under 25 bytes for Linux/x86 encoding Avoiding zero bytes More restrictions No newlines Common requirement for shellcode in C string Only printable characters Analogy: broken 0 key on keyboard Only alphanumeric characters May occur in other parts of encoding as well “English Shellcode” (CCS’09) Transformations Multi-stage approach Initially executable portion unpacks rest from Fold case, escapes, Latin1 to Unicode, etc. another format Invariant: unchanged by transformation Improves efficiency in restricted environments Pre-image: becomes shellcode only after transformation But self-modifying code has pitfalls

NOP sleds Where to put shellcode? In overflowed buffer, if big enough Goal: make the shellcode an easier target to hit Long sequence of no-op instructions, real shellcode Anywhere else you can get it at the end Nice to have: predictable location x86: 0x90 0x90 0x90 0x90 0x90 . . . shellcode Convenient choice of Unix local exploits: Where to put shellcode? Code reuse Environment variables If can’t get your own shellcode, use existing code Classic example: s②st❡♠ implementation in C library “Return to libc” attack More variations on this later Outline Non-control data overwrite Where overflows come from (cont’d) More low-level problems Overwrite other security-sensitive data Classic code injection attacks No change to program control flow Announcements intermission Set user ID to 0, set permissions to all, etc. Shellcode techniques Exploiting other vulnerabilities Heap meta-data Heap meta-data Boundary tags similar to doubly-linked list Overwritten on heap overflow Arbitrary write triggered on ❢r❡❡ Simple version stopped by sanity checks