Outline Integer overflow debrief CSci 4271W Development of Secure - PDF document

Outline Integer overflow debrief CSci 4271W Development of Secure Software Systems Code auditing Day 4: Auditing and Threat Modeling 1 Stephen McCamant Threat modeling University of Minnesota, Computer Science & Engineering Integer input parsing Loop bound Input is first parsed with strt♦❧ As 64-bit signed integer; overflow clamped and ignored Read loop is Then copied to signed int ❢♦r ✭✐♥t ✐ ❂ ✵❀ ✐ ❁ ♥✉♠❴♦❜❥s❀ ✐✰✰✮ Throw away top bits, reinterpret sign bit ♥✉♠❴♦❜❥s negative or zero will read nothing at all But any 32-bit int value can be produced by a program input Overflow in multiplication Vulnerability condition Overflow happens if we write more than we allocated Allocation won’t fail on this 64-bit machine (4GB Struct size is 24 bytes, or 11000 (16+8) in binary available) ✷✹✯① ❂❂ ✭① ❁❁ ✹✮ ✰ ✭① ❁❁ ✸✮ ✷✹ ✁ max ✭ ①❀ ✵ ✮ ❃ ✭ ✷✹ ✁ ① ✮ mod ✷ ✸✷ Top three bits fall off Safe if: Interpreted as unsigned after multiplication, and by Count interpreted as negative ♠❛❧❧♦❝ Overflow does not occur Unsafe if ♥✉♠❴♦❜❥s ✕ ❙ ✵①✶✵✵✵✵✵✵✵ Outline Auditing is. . . Integer overflow debrief Reading code to find security bugs Threat modeling comes first, tells you what kinds of Code auditing bugs you’re looking for Bug fixing comes next (might be someone else’s job) Threat modeling

Tiers and triage Threat model and taint Vulnerability depends on what an attacker might You might not have time to do a complete job, so control use auditing time strategically Another word for attacker-controlled is “tainted” Which bugs are most likely, and easiest to find? Threat model is the best source of tainting Triage into definitely safe, definitively unsafe, hard to information tell Of course, can always be conservative Hard to tell might be improved even if safe Where to look for problems Ideal: proof Given enough time, for each dangerous spot, be able If you can’t read all the code carefully, search for to convince someone: indicators of common danger spots Proof of safety: reasons why a bug could never happen, For format strings, look for ♣r✐♥t❢ could turn into assertions For buffer overflows, look at buffers and copying functions Proof of vulnerability: example of tainted input that causes a crash Auditing exercise Outline BCLPR is a buggy program from a previous year’s 5271 Integer overflow debrief This code has at least three buffer overflow bugs: where are they? Code auditing Are all the bugs exploitable ? As an attacker, could Threat modeling you use them? ❤tt♣✿✴✴✇✇✇✲✉s❡rs✳❝s❡❧❛❜s✳✉♠♥✳❡❞✉✴❝❧❛ss❡s✴ ❋❛❧❧✲✷✵✷✵✴❝s❝✐✹✷✼✶✴s❧✐❞❡s✴✵✷✴❜❝❧♣r✳❝ Why threat modeling? Why a structured approach? Think about and describe the security design of your Goal is to avoid missing a threat system Enumerate vectors for threats Enumerate possible threats Enumerate kinds of threats per vector Guide effort spent on combating threats Convince readers of the model’s completeness Communicate to customers and other developers

Data-flow modeling Data flow example Break down software into smaller modules Modules drawn with rounded rectangles More detail is better, within reason Show data flows among modules and external parties Rectangles for external parties Most data flows will be bi-drectional Trust boundaries Trust boundaries example A trust boundary groups components with the same privilege, which therefore trust each other Drawn as labeled dotted box Attacks usually don’t originate within a trust group The boundary also corresponds to an attack surface Attacks come with data flows STRIDE threat taxonomy Spoofing (vs authentication) Principle: attacks propagate along data flows Tampering (vs integrity) Therefore, enumerate flows to enumerate attacks Repudiation (vs. non-repdiation) A more specific prompt, but does not eliminate the need Information disclosure (vs. confidentiality) for imagination Other half is types of attacks, see next slide Denial of service (vs. availability) Elevation of privilege (vs. authortization) What to do about threats Spoofing threat examples Mitigate: add a defense, which may not be complete Eliminate: such as by removing functionality Using someone else’s account Transfer functionality: let someone else handle it Making a program use the wrong file Transfer risk: convince another to bear the cost False address on network traffic Accept risk: decide that the risk (probability ✁ loss) is sufficiently low

Tampering threat examples Repudiation threat examples Performing an important action without logging Modifying an important file Destroying existing logs Rearranging directory structure Add fake events to make real events hard to find or Changing contents of network packets not credible Info. disclosure threat examples DoS threat examples Flood network link with bogus traffic Eavesdropping on network traffic Make a server use up available memory Reading sensitive files Make many well-formed but non-productive Learning sensitive information from meta-data interactions Elevation of privilege threat examples Cause data to be interpreted as code Change process to run as root/administrator Convince privileged process to run attacker’s code