1 / 27

CMSC 414 Computer and Network Security Lecture 23

CMSC 414 Computer and Network Security Lecture 23. Jonathan Katz. Database security. Data perturbation: k -anonymity. Ensure that any “identifying information” is shared by at least k members of the database Example…. Example: 2-anonymity. Problems with k -anonymity.

ambrose
Download Presentation

CMSC 414 Computer and Network Security Lecture 23

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMSC 414Computer and Network SecurityLecture 23 Jonathan Katz

  2. Database security

  3. Data perturbation: k-anonymity • Ensure that any “identifying information” is shared by at least k members of the database • Example…

  4. Example: 2-anonymity

  5. Problems with k-anonymity • Hard to find the right balance between what is “scrubbed” and utility of the data • Not clear what security guarantees it provides • For example, what if I know that the Asian person in ZIP code 0214x smokes? • Again, does not deal with out-of-band information

  6. Output perturbation • One approach: replace the query with a perturbed query, then return an exact answer to that • E.g., a query over some set of entries C is answered using some (randomly-determined) subset C’  C • User only learns the answer, not C’ • Second approach: add noise to the exact answer (to the original query)

  7. A negative result [Dinur-Nissim] • Heavily paraphrased: Given a database with n rows, if roughly n queries are made to the database (in total) then essentially the entire database can be reconstructed even if O(n1/2) noise is added to each answer • On the positive side, it is known that very small error can be used when the total number of queries is kept small

  8. Formally defining privacy • A problem inherent in all these approaches (and the source of many of the problems we have seen) is that no definition of “privacy” is offered • Recently, there has been work addressing exactly this point • Developing definitions • Provably-secure schemes!

  9. A definition of privacy • Differential privacy [Dwork et al.] • Roughly speaking: • For each row r of the database (representing, say, an individual), the distribution of answers given when r is included in the database are “close” to the answers given when r is not included in the database • Note: can’t really hope for closeness better than 1/|DB| • Further refining/extending this definition is currently an active area of research

  10. Achieving privacy • A “converse” to the Dinur-Nissim result is that adding some (carefully-generated) noise, and limiting the number of queries appropriately, can be proven to achieve privacy • Currently an active area of research

  11. Programming language/application level security

  12. PL security • Previous focus in this class has been on secure protocols and algorithms • For real-world security, it is not enough for the protocol/algorithm to be secure, but also the implementation must be secure

  13. Importance of the problem • The amount of time we are devoting to the problem is not indicative of its relative importance • In practice, attacks that exploit implementation flaws are much more common than attacks that exploit protocol flaws • Damage from such flaws also typically much greater • Viruses/worms almost always exploit such flaws • If you ever program security-sensitive applications, learn about secure programming

  14. Importance of the problem • Most common cause of Internet attacks • Over 50% of CERT advisories related to buffer overflow vulnerabilities • Morris worm (1988) • 6,000 machines infected • CodeRed (2001) • 300,000 machines infected in 14 hours • SQL slammer worm (2003) • 75,000 machines infected in 10 minutes(!)

  15. PL attacks • Many of the most common PL attacks come down to not properly validating input from (untrusted) users before use • Buffer overflow attacks • Format string vulnerabilities • Cross-site scripting (XSS) attacks • SQL injection attacks • etc. • There are other PL security issues as well, but we will not cover these in this class

  16. Buffer overflows • Fixed-sized buffer that is to be filled with unknown data, usually provided directly by user • If more data “stuffed” into the buffer than it can hold, that data spills over into adjacent memory • If this data is executable code, the victim’s machine may be tricked into running it • Can overflow buffer on the stack or the heap…

  17. Stack overview • Each function that is executed is allocated its own frame on the stack • When one function calls another, a new frame is initialized and placed (pushed) on the stack • When a function is finished executing, its frame is taken off (popped) the stack

  18. Function frame Stack grows this way locals vars ebp ret addr args Frame of the calling function Execute code at this address after func() finishes Pointer to previous frame

  19. color price ebp ret addr args Frame of the calling function locals vars “Simple” buffer overflow • Overflow one variable into another • gets(color) • What if I type “blue 1” ? • (Actually, need to be more clever than this)

  20. Execute code at this address after func() finishes This will be interpreted as a return address! More devious examples… • strcpy(buf, str) • What if str has more than buf can hold? • Problem: strcpy does not check that str is shorter than buf overflow buf sfp ret addr str Frame of the calling function Pointer to previous frame

  21. Even more devious… overflow buf sfp ret addr str Frame of the calling function In the overflow, a pointer back into the buffer appears in the location where the system expects to find return address Attacker puts actual assembly instructions into his input string, e.g., binary code of execve(“/bin/sh”)

  22. Severity of attack? • Theoretically, attacker can cause machine to execute arbitrary code with the permissions of the program itself • Actually carrying out such an attack involves many more details • See “Smashing the Stack…”

  23. Examples; using gdb

  24. Preventing this attack • We have seen that strcpy is unsafe • strcpy(buf, str) simply copies memory contents into buf starting from *str until “\0” is encountered, ignoring the size of buf • Avoid strcpy(), strcat(), gets(), etc. • Use strncpy(), strncat(), instead • Even these are not perfect… (e.g., no null termination) • Always a good idea to do your own validation when obtaining input from untrusted source • Still need to be careful when copying multiple inputs into a buffer

  25. Does range checking help? • strncpy(char *dest, const char *src, size_t n) • No more than n characters will be copied from *src to *dest • Programmer has to supply the right value of n! • Bad: … strcpy(record,user); strcat(record,”:”); strcat(record,cpw); … • Published “fix” (do you see the problem?): … strncpy(record,user,MAX_STRING_LEN-1); strcat(record,”:”); strncat(record,cpw,MAX_STRING_LEN-1); …

  26. Off-by-one overflow • Consider the following code:char buf[512]; int i; for (i=0; i <= 512; i++) buf[i] = input[i]; • 1-byte overflow: can’t change return address, but can change pointer to previous stack frame • On little-endian architecture, make it point into buffer

  27. Exam review

More Related