Notes from Prof. Brun€¦ · 25.10.2012 · Software Security — Ben Ransford — CS621 Fall...
40
Software Security — Ben Ransford — CS621 Fall 2012 Notes from Prof. Brun • Project plan due next Tuesday (email him if you have questions) • Be ready to present project plans on Tuesday (10 minutes per group) 1
Transcript of Notes from Prof. Brun€¦ · 25.10.2012 · Software Security — Ben Ransford — CS621 Fall...
Software Security — Ben Ransford — CS621 Fall 2012
Notes from Prof. Brun
• Project plan due next Tuesday (email him if you have questions)
• Be ready to present project plans on Tuesday (10 minutes per group)
1
CS621 Fall 2012
Software Security
Software Security — Ben Ransford — CS621 Fall 2012 3
Software Security — Ben Ransford — CS621 Fall 2012 3
Software Security — Ben Ransford — CS621 Fall 2012 4
≈
Ross Anderson,Security Engineering
Saltzer & Kaashoek,P. of C. S. D.
Software Security — Ben Ransford — CS621 Fall 2012 5
“Security engineering is about building systems to remain dependable in the face
of malice, error, or mischance.”
Software Security — Ben Ransford — CS621 Fall 2012 6
Security =Policy + Mechanism + Assurance + Incentive
Software Security — Ben Ransford — CS621 Fall 2012 6
Security =Policy + Mechanism + Assurance + Incentive
Insecurity ≈How can I break this system?
Software Security — Ben Ransford — CS621 Fall 2012
Threat Modeling
7
• ... is your job in system design
• Think like an attacker
• Understand and prioritize incentives
• Imagine a realistic attacker
Software Security — Ben Ransford — CS621 Fall 2012
Attack Surface
• Which parts of your system interface with other stuff?
• Network ports, I/O
• Command-line inputs
• Dependencies on other systems
8
Software Security — Ben Ransford — CS621 Fall 2012
Attacker Incentives
• For each element of attack surface:
• What can a successful attacker gain?
• What’s it worth?
9
Software Security — Ben Ransford — CS621 Fall 2012 10
Software Security — Ben Ransford — CS621 Fall 2012 10
Software Security — Ben Ransford — CS621 Fall 2012 10
Software Security — Ben Ransford — CS621 Fall 2012 11
(Some) Kinds of Attackers
Value Example Attacker
Low Generic PC Script kiddie
Medium Personal bank account Phisher
High State nuclear program Another state
Software Security — Ben Ransford — CS621 Fall 2012
Script Kiddies
12
• Largely unskilled; main resource = time
• Use pre-packaged exploits
• May wish to sell compromised resources (e.g., sell zombie PCs to botnet)
Software Security — Ben Ransford — CS621 Fall 2012
Midrange “Hackers”
• Somewhat skilled; may have specific targets
• May be willing to use social engineering
• Motivations include fame, revenge, vandalism, $$$
13
Software Security — Ben Ransford — CS621 Fall 2012
High-End Hackers
• Deep understanding of target
• Write exploits
• These days, sell exploits for $$$$$
14
Software Security — Ben Ransford — CS621 Fall 2012
High-End Hackers
• Deep understanding of target
• Write exploits
• These days, sell exploits for $$$$$
14
Software Security — Ben Ransford — CS621 Fall 2012
Even Higher-End Hackers
15
• E.g., state agencies (NSA, Mossad)
• Specific targets for espionage or sabotage
• Advanced persistent threats — get into target and stay there
Software Security — Ben Ransford — CS621 Fall 2012 16
Software Security — Ben Ransford — CS621 Fall 2012 17
CryptographyDo’s & don’ts
Note: cryptography != security
Software Security — Ben Ransford — CS621 Fall 2012
Rule #1
18
Don’t design your own cipher!Use an existing one.
== Use AES.
Software Security — Ben Ransford — CS621 Fall 2012
Don’t pull a Mifare
19
Software Security — Ben Ransford — CS621 Fall 2012
Rule #2
20
Don’t rely on security through obscurity.Your system’s design will become known.
== Assume only the keys are secret.
X
Software Security — Ben Ransford — CS621 Fall 2012
Rule #3
21
Don’t use randomness incorrectly or use predictable “randomess.”
Bad randomness makes attacks easy.
== Use TRNG or a good seeded PRNG
Software Security — Ben Ransford — CS621 Fall 2012 22
Good PRNG
• Doesn’t repeat itself (long period)
• Does use sources of “random” bits
Software Security — Ben Ransford — CS621 Fall 2012 22
Good PRNG
• Doesn’t repeat itself (long period)
• Does use sources of “random” bits
Software Security — Ben Ransford — CS621 Fall 2012 23
Bad PRNG
Easy to guess secrets!
Software Security — Ben Ransford — CS621 Fall 2012 23
Bad PRNG
Easy to guess secrets!
Software Security — Ben Ransford — CS621 Fall 2012
Note: Multiple PRNGs
24
(demo of Linux /dev/urandom vs. /dev/random)
Don’t use urandom when you want random.
Software Security — Ben Ransford — CS621 Fall 2012
Harping on Randomness
25
Software Security — Ben Ransford — CS621 Fall 2012
Harping on Randomness
25
“We found that 5.57% of TLS hosts and 9.60% of SSH hosts share public keys in an apparently vulnerable
manner, due to either insufficient randomness during key generation or device default keys” (source: factorable.net)
Software Security — Ben Ransford — CS621 Fall 2012
Debian OpenSSL disaster
26
(Don’t trust your tools blindly!)
Software Security — Ben Ransford — CS621 Fall 2012
Greatest Hits(and how not to get hit)
27
please put on your C/C++ hats
Software Security — Ben Ransford — CS621 Fall 2012
Buffer overflows(super common)
28
strcpy(dest, user_supplied_input);
Software Security — Ben Ransford — CS621 Fall 2012
Use-after-free(somewhat common)
29
void f (p_t *p) { ...; free(p); }
f(my_pointer);*my_pointer = 0x1234;
Software Security — Ben Ransford — CS621 Fall 2012
Double free(not all that common)
30
void f (p_t *p) { ...; free(p); }
f(my_pointer);free(my_pointer);
Software Security — Ben Ransford — CS621 Fall 2012
Input validation
31
Software Security — Ben Ransford — CS621 Fall 2012
Cross-site scripting(super super super common)
32
Hello my name is <script>stealStuff();</script>
