Some recent security news

Transcription

1 Some recent security news Swedish ISP didn t update their routers US Postal service hacked; data about 500k employees leaked security cameras use default passwords Tor network hacked (by law enforcement) Domestic Russian Internet traffic routed through Frankfurt, China, and Stockholm

2 Wednesday/Thursday: Oral examination #1 Until Sunday: Intro lab evaluation! New lab (and some groups) after the examination

3 Structured oral assessment explaining discussing! Group A explaining presenting follow-up questions? discussing! Teachers discussing asking discussing! challenging Documenting Peer review form Group B ( or 2 copies) Different groups meet each seminar Groups review each other s solutions Activity and reflection required

4 Software Security Write programs which do not UNnecessarily break! Björn Victor spring 2014

5 Goal: Avoid pitfalls Avoid opening gaping security holes Understand pitfalls understand how programs run on real systems programming, compilers, data structures, architecture, operating systems useful knowledge

6 Top 25 Most Dangerous Software Errors Rank Name [1] Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') [2] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') [3] Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [4] Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [5] Missing Authentication for Critical Function [6] Missing Authorization [7] Use of Hard-coded Credentials [8] Missing Encryption of Sensitive Data [9] Unrestricted Upload of File with Dangerous Type Avoid these!! [10] Reliance on Untrusted Inputs in a Security Decision [11] Execution with Unnecessary Privileges [12] Cross-Site Request Forgery (CSRF) [13] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [14] Download of Code Without Integrity Check [15] Incorrect Authorization [16] Inclusion of Functionality from Untrusted Control Sphere [17] Incorrect Permission Assignment for Critical Resource [18] Use of Potentially Dangerous Function [19] Use of a Broken or Risky Cryptographic Algorithm [20] Incorrect Calculation of Buffer Size [21] Improper Restriction of Excessive Authentication Attempts [22] URL Redirection to Untrusted Site ('Open Redirect') [23] Uncontrolled Format String [24] Integer Overflow or Wraparound [25] Use of a One-Way Hash without a Salt

7 Security vs. reliability Reliability issues, examples: check return value of system calls and library calls (e.g. did the memory allocation work? could the file be opened?) write modular code, more easily checked and tested Some overlap with security!

8 Standard pitfalls Inputs encodings, validation, quoting Overflows integers, stack, heap Races temporary files

9 Standard defenses Typing, canonical forms, bounds checking, validation/quoting Hardware support, source analysis/ inspection, testing Design principles (e.g. Least privilege)

10 Pitfalls

11 Pitfalls: inputs to programs Unexpected inputs to programs can break security Examples: URL encodings Name-based protection Script/SQL insertion Pathnames

12 URL shapes <a href=" Where does this lead? What is shown to the user? where quite...se is username, incom... is password, villain.si.te is the real host homograph encodings using Internationalized Domain Name (IDN) encoding (e.g. miсrоsоft.com as xn mirsft-yqfbx.com )

13 Name-based protection File name case sensitivity e.g. earlier Apache web server access control: MyFile different from myfile even if not different in file system if Apache protected MyFile but not myfile, access control could be avoided This particular case fixed, but principle is still valid

14 Name-based protection Varying encodings of name, e.g. ASCII vs HTML entities vs URL encoding vs ISO-8859 vs UTF-8 vs Unicode ASCII = ASCII foo/bar = foo%2fbar HTML entities URL encoding (hex) UTF-8 can use two or three bytes to represent å ; ISO-8859 uses one byte e5 c3 a5 61 cc 8a

15 Example: Pathnames Example: web server where URLs are attached to web root directory e.g. /var/www/html what happens given URL../../../../etc/passwd? /var/www/html/../../../../etc/passwd = /etc/passwd Actual attack on Netgear SPH200D router!

16 Pathnames: solutions Disallow/remove../ components - and check for encodings of that string Translate to absolute pathname, check it Use the chroot system call to make it impossible to escape web root Each is more or less practical

17 Name-based protection IP address vs DNS names = = arachne.it.uu.se Good solution (general): rewrite to canonical form before lookup/ access control

18 Script/SQL: solutions always escape ( quote ) special characters for the interpreter, e.g ; \; \ validate input before using it, e.g. correct syntax, length, range. Do not rely on client side validation! (e.g. using Javascript in input forms) Why?

19 Overflows

20 Overflows Integer representation typically finite/fixed size (8, 16, 32, 64 bits) what happens: 8-bit unsigned value =?; 16 x 17 =? 8-bit signed value =? Converting between representations may lose value (e.g. 32-bit 16-bit loses half the bits) 0; 16 (= 272%255); -128 (= )

21 Array bounds checking Low-level languages e.g. C: no array bounds checking arr[index] is the same as &arr+index*sizeof(array element) negative indexes - what happens? cf. integer overflow gets(buf) reads until EOF or newline without checking if it fits in buf solution: use fgets(buf, nbytes, stdin) Example?

22 Stack/buffer overflows Exploit bounds checking problem void foo(void) { /* no argument, no value */ char buf[70]; } gets(buf); /* read input */ if (strncmp(buf, "foo", 3)) /* are the first three characters "foo"? */ printf("bar!\n"); /* then give some response */ How can this simple program be exploited?

23 Stack/buffer overflow void foo(void) { /* no argument, no value */ char buf[70]; } gets(buf); /* read input */ if (strncmp(buf, "foo", 3)) /* are the first three characters "foo"? */ printf("bar!\n"); /* then give some response */ addr buf (70 bytes) addr code (70 bytes) addr+70 addr+71 saved frame pointer return address excess input addr+70 addr+71 code addr (pushed earlier) even more code Stack grows to lower addr; writes successively higher addr Arbitrary code can get executed!

24 Example code int main(int argc, char *argv[]) { char *sh; char *args[2]; } sh = "/bin/sh"; args[0] = sh; args[1] = NULL; execve(sh, args, NULL); (a) Desired shellcode code in C nop nop // end of nop sled jmp find // jump to end of code cont: pop %esi // pop address of sh off stack into %esi xor %eax,%eax // zero contents of EAX mov %al,0x7(%esi) // copy zero byte to end of string sh (%esi) lea (%esi),%ebx // load address of sh (%esi) into %ebx mov %ebx,0x8(%esi) // save address of sh in args[0] (%esi+8) mov %eax,0xc(%esi) // copy zero to args[1] (%esi+c) mov $0xb,%al // copy execve syscall number (11) to AL mov %esi,%ebx // copy address of sh (%esi) t0 %ebx lea 0x8(%esi),%ecx // copy address of args (%esi+8) to %ecx lea 0xc(%esi),%edx // copy address of args[1] (%esi+c) to %edx int $0x80 // software interrupt to execute syscall find: call cont // call cont which saves next address on stack sh:.string "/bin/sh " // string constant args:.long 0 // space used for args array.long 0 // args[1] and also NULL for env array (b) Equivalent position-independent x86 assembly code eb 1a 5e 31 c d 1e 89 5e c b0 0b 89 f3 8d 4e 08 8d 56 0c cd 80 e8 e1 [Stallings & Brown Fig 10.8]

25 Heap overflows Heap: memory area for e.g. dynamically allocated memory blocks structured, header/trailer with info about other memory blocks etc overwrite header/trailer: cause crashes, overwrite (securityrelevant) data, store program...

26 Race conditions Race condition: when timing of execution (severely) affects the outcome of computation Design principle: separation of mechanisms If not used: race conditions usable for attacks On the Top 41 list

27 Race condition example A program uses a file in /tmp directory for intermediary data, which is later used Even if files are by default protected: without sticky bit (cf. Unix), anyone can replace file - at right moment with sticky bit: predictable file name gives attack opportunity

28 Group work: Top 25 Most Dangerous Software Errors Read the description of a Top 25 item: What is the problem? ( Technical details ) Read about a suggested mitigation (fix, making it less severe) How does the mitigation work on an example? Can you find an example from Reality? (Also see the Monster Mitigations list.) (suggestion: not one you already know)

29 Defenses

30 Defenses/mitigations Validate inputs! use type checking, canonical forms, bounds checking type checking possible also for information flow analysis and other security aspects Avoid unsafe functions (gets, sprintf, strcpy etc)

31 Defenses/mitigations Hardware support: stack overflow: make stack non-executable ( NX ) enforce either write or execute permission ( W^X = write XOR execute) Kernel support: randomize address of stack etc Sometimes breaks old software, sometimes not

32 Defenses/mitigations Software support: example change function call mechanism: place a (random) check value ( canary ) below return address on stack, check that it is intact before returning (cf. coal mines) addr addr+70 addr+71 addr+72 buf (70 bytes) saved frame pointer 0xff00ff00 return address (pushed earlier)

33 Defenses/mitigations Software support (2): use high-level programming languages (e.g. with bounds checking, strong type system) e.g. avoid C

34 Defenses/mitigations Source analysis compilers check for dangerous functions type checking Example: OpenBSD Unix uses tools and code auditing to catch all simple pitfalls

35 Defenses/mitigations Testing for known vulnerabilities e.g. using tools such as Metasploit Testing shows the presence, not the absence of bugs -- E.W. Dijkstra Formal verification (e.g. sel4 microkernel, L4.verified project)

36 Defense: design principles Least privilege ( need-to-know ): each subject should be given only those rights needed to complete its task Economy of mechanism: small/simple design gives easier verification/implementation Complete mediation: check every access Open design: no security by obscurity Fail-safe defaults: deny access by default Separation of privilege: depend on >1 condition Least common mechanism: minimize shared mechanisms

37 Defenses Keep your system up-to-date security patches and updates virus protection Make backups! And check that they work!

38 Summary: problems Inputs encodings, validation, quoting Overflows integers, stack, heap Races temporary files

39 Summary: defenses Validate inputs Hardware support Software support Source code analysis Design principles! Keep up-to-date!