{"id":970,"date":"2012-11-01T00:00:56","date_gmt":"2012-11-01T04:00:56","guid":{"rendered":"http:\/\/jlg.name\/blog\/?p=970"},"modified":"2013-09-01T23:26:38","modified_gmt":"2013-09-02T03:26:38","slug":"2012-conference-on-computer-and-communications-security","status":"publish","type":"post","link":"http:\/\/jlg.name\/blog\/2012\/11\/2012-conference-on-computer-and-communications-security\/","title":{"rendered":"2012 Conference on Computer and Communications Security"},"content":{"rendered":"<p>In October I attended the\u00a0<a href=\"http:\/\/www.sigsac.org\/ccs\/CCS2012\/\">19th ACM Conference on Computer and Communications Security (CCS)<\/a>\u00a0in Raleigh, North Carolina.\u00a0 It was my fourth time attending (and third city visited for) the conference.<\/p>\n<p>Here are some of my interesting takeaways from the conference:<\/p>\n<ul>\n<li><strong>The next thing after ASLR?<\/strong>\u00a0\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Address_space_layout_randomization\">Address space layout randomization (ASLR)<\/a>\u00a0is an anti-malware technique.\u00a0 Under ASLR you mix up where your program keeps its important data structures.\u00a0 Doing so makes it harder for malicious software to find and abuse those structures.\u00a0 Taking \u201cmix things up\u201d one step further, I enjoyed the talk on\u00a0<a href=\"http:\/\/www.utdallas.edu\/~hamlen\/wartell12ccs.pdf\">Binary Stirring: Self-randomizing Instruction Addresses of Legacy X86 Binary Code<\/a>.\u00a0 The authors\u2019 technique \u201ctransforms legacy application binary code into self-randomizing code that statically re-randomizes itself each time it is loaded.\u201d<\/li>\n<\/ul>\n<p>The point of Binary Stirring is to end up with a completely different (but functionally equivalent) executable code segment, each time you load a program. \u00a0The authors double \u201ceach code segment into two separate segments\u2014one in which all bytes are treated as data, and another in which all bytes are treated as code.\u00a0 \u2026In the data-only copy (.told), all bytes are preserved at their original addresses, but the section is set non-executable (NX).\u00a0 \u2026In the code-only copy (.tnew), all bytes are disassembled into code blocks that can be randomly stirred into a new layout each time the program starts.\u201d\u00a0 (The authors measured about a 2% performance penalty from mixing up the code segment.)<\/p>\n<p>But why mix the executable bytes at all?\u00a0 Binary Stirring is intended to protect against clever \u201c<a href=\"http:\/\/en.wikipedia.org\/wiki\/Return-oriented_programming\">return-oriented programming<\/a>\u201d (ROP) attacks by eliminating all predictable executable code from the program.\u00a0 If you haven\u2019t studied ROP (I hadn\u2019t before I attended the talk) then it\u2019s worth taking a look, just to appreciate the cleverness of the attack &amp; the challenge of mitigating it.\u00a0 Start with last year\u2019s paper\u00a0<a href=\"http:\/\/www.ece.cmu.edu\/~ejschwar\/papers\/usenix11.pdf\">Q: Exploit Hardening Made Easy<\/a>, especially the related work survey in section 9.<\/p>\n<ul>\n<li><strong>Oblivious RAM:<\/strong>\u00a0 ORAM is a neat concept, dating back to at least 1990, wherein an adversary who\u00a0<em>can<\/em>\u00a0see your memory accesses\u00a0<em>cannot<\/em>\u00a0learn anything about what your program is doing.\u00a0 (See below.)\u00a0 I don\u2019t know of any practical real-world problems that are solvable by ORAM \u2014 a current general challenge is that\u00a0<a href=\"http:\/\/www.emilstefanov.net\/Research\/Files\/Publications\/PracticalORam.pdf\">you only get obliviousness by utterly giving up on performance<\/a>\u00a0\u2014 but I still enjoy hearing about work on the topic, including\u00a0<a href=\"http:\/\/www.cs.umd.edu\/~jkatz\/papers\/oram.pdf\">this paper that combines ORAM with the neat concept of secure two-party computation<\/a>(wherein two parties must cooperate to calculate a function\u2019s output, but where neither party reveals anything about its half of the computation).<\/li>\n<\/ul>\n<p>Regarding ORAM, imagine a stock analyst who stores gigabytes of encrypted market information \u201cin the cloud.\u201d\u00a0 In order to make a buy\/sell decision about a particular stock (say, NASDAQ:TSYS), she would first download a few kilobytes of historical information about TSYS from her cloud storage.\u00a0 The problem is that an adversary at the cloud provider could detect that she was interested in TSYS stock, even though the data is encrypted in the cloud.\u00a0 (How?\u00a0 Well, imagine that the adversary watched her memory access patterns the last time she bought or sold TSYS stock.\u00a0 Those access patterns will be repeated this time when she examines TSYS stock.)\u00a0 The point of oblivious RAM is to make it impossible for the adversary to glean which records the analyst downloads.<\/p>\n<ul>\n<li><strong>Fully homomorphic encryption:<\/strong>\u00a0 The similar concept of\u00a0<a href=\"http:\/\/www.americanscientist.org\/issues\/pub\/2012\/5\/alice-and-bob-in-cipherspace\">fully homomorphic encryption (FHE)<\/a>\u00a0was discussed at some of the post-conference workshops.\u00a0 FHE is the concept that you can encrypt data (such as database entries), store them \u201cin the cloud,\u201d and then have the cloud do computation for you (such as database searches)\u00a0<em>on the encrypted data, without decrypting<\/em>.<\/li>\n<\/ul>\n<p>When I first heard about the concept of homomorphic encryption (circa 2005, from some of my excellent then-colleagues at IBM Research) I felt it was one of the coolest things I\u2019d encountered in a company filled with cool things.\u00a0 Unfortunately FHE is still somewhat of a pipe dream \u2014 like ORAM, it\u2019ll be a long while before it\u2019s efficient enough to solve any practical real-world problems \u2014 but it remains an active area of interesting research.<\/p>\n<ul>\n<li><strong>Electrical network frequency (ENF):<\/strong>\u00a0 In the\u00a0<em>holy cow, how cool is that?<\/em>\u00a0category, the paper \u201c<a href=\"http:\/\/www.ece.umd.edu\/~minwu\/research\/public_paper\/Conf12\/CCS12_antiENF_final_ChuangGargWu.pdf\">How Secure are Power Network Signature Based Time Stamps?<\/a>\u201d introduced me to a new forensics concept: \u201cOne emerging direction of digital recording authentication is to exploit an potential time stamp originated from the power networks. This time stamp, referred to as the Electrical Network Frequency (ENF), is based on the fluctuation of the supply frequency of a power grid.\u00a0 \u2026 It has been found that digital devices such as audio recorders, CCTV recorders, and camcorders that are plugged into the power systems or are near power sources may pick up the ENF signal due to the interference from electromagnetic fields created by power sources.\u201d\u00a0 Wow!<\/li>\n<\/ul>\n<p>The paper is about anti-forensics (how to remove the ENF signature from your digital recording) and counter-anti-forensics (how to detect when someone has removed the ENF signature).\u00a0 The paper\u2019s discussion of ENF analysis reminded me loosely of one of my all-time favorite papers, also from CCS, on\u00a0<a href=\"http:\/\/www.cl.cam.ac.uk\/~sjm217\/papers\/ccs06hotornot.pdf\">remote measurement of CPU load by measuring clock skew as seen through TCP (transmission control protocol) timestamps<\/a>.<\/p>\n<ul>\n<li><strong>Resource-freeing attacks (RFA)<\/strong>:\u00a0 I also enjoy papers about virtualization, especially regarding the fair or unfair allocation of resources across multiple competing VMs.\u00a0 In the paper \u201c<a href=\"http:\/\/pages.cs.wisc.edu\/~venkatv\/ccs12-rfa.pdf\">Resource-Freeing Attacks: Improve Your Cloud Performance (at Your Neighbor\u2019s Expense)<\/a>\u201d, the authors show how to use antisocial virtual behavior for fun and profit: \u201cA resource-freeing attack (RFA) [improves] a VM\u2019s performance by forcing a competing VM to saturate some bottleneck. If done carefully, this can slow down or shift the competing application\u2019s use of a desired resource. For example, we investigate in detail an RFA that improves cache performance when co-resident with a heavily used Apache web server. Greedy users will benefit from running the RFA, and the victim ends up paying for increased load and the costs of reduced legitimate traffic.\u201d<\/li>\n<\/ul>\n<p>A disappointing aspect of the paper is that they don\u2019t spend much time discussing how one can prevent RFAs.\u00a0 Their suggestions are (1) use a dedicated instance, or (2) build better hypervisors, or (3) do better scheduling.\u00a0 That last suggestion reminded me of another of my all-time favorite research results, from last year\u2019s \u201c<a href=\"http:\/\/arxiv.org\/pdf\/1103.0759\">Scheduler Vulnerabilities and Attacks in Cloud Computing<\/a>\u201d, wherein the authors describe a \u201ctheft-of-service\u201d attack:\u00a0 A virtual machine calls\u00a0<em>Halt()<\/em>\u00a0just before the hypervisor timer fires to measure resource use by VMs, meaning that the VM consumes CPU resources but (a) isn\u2019t charged for them and (b) is allocated even more resources at the expense of other VMs.<\/p>\n<ul>\n<li><strong>My favorite work of the conference:<\/strong>\u00a0 The paper is a little hard to follow, but I loved the talk on \u201c<a href=\"https:\/\/www.hgi.rub.de\/media\/emma\/veroeffentlichungen\/2012\/08\/16\/scriptlessAttacks-ccs2012.pdf\">Scriptless Attacks \u2013 Stealing the Pie Without Touching the Sill<\/a>\u201d.\u00a0 The authors were interested in whether an attacker could still perform \u201cinformation theft\u201d attacks once all the XSS (cross-site scripting) vulnerabilities are gone.\u00a0 Their answer: \u201cThe surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files.\u201d<\/li>\n<\/ul>\n<p>One of their examples is that the attacker can very rapidly shrink then grow the size of a text entry field.\u00a0 When the text entry field shrinks to\u00a0<em>one pixel smaller than the width of the character the user typed<\/em>, the browser automatically creates a scrollbar.\u00a0 The attacker can note the appearance of the scrollbar and infer the character based on the amount the field shrank.\u00a0 (The shrinking and expansion takes place too fast for the user to notice.)\u00a0 The data exfiltration happens even with JavaScript completely disabled.\u00a0 Pretty cool result.<\/p>\n<p>Finally, here are some honorable-mention papers in four categories \u2014 work I enjoyed reading, that you might too:<\/p>\n<p>Those who cannot remember the past, are condemned to repeat it:<\/p>\n<ul>\n<li><a href=\"http:\/\/users.ece.cmu.edu\/~tdumitra\/public_documents\/bilge12_zero_day.pdf\">Before We Knew It: An Empirical Study of Zero-Day Attacks in the Real World<\/a><\/li>\n<\/ul>\n<ul>\n<li><a href=\"http:\/\/www.hpl.hp.com\/techreports\/2012\/HPL-2012-63R1.pdf\">An Historical Examination of Open Source Releases and Their Vulnerabilities<\/a><\/li>\n<\/ul>\n<p>Sidestepping institutional security:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.cs.ucla.edu\/~chunyip\/publications\/ccs12-peng.pdf\">Mobile Data Charging: New Attacks and Countermeasures<\/a><\/li>\n<\/ul>\n<ul>\n<li><a href=\"https:\/\/netfiles.uiuc.edu\/qwang26\/www\/publications\/censorspoofer.pdf\">CensorSpoofer: Asymmetric Communication Using IP Spoofing for Censorship-Resistant Web Browsing<\/a><\/li>\n<\/ul>\n<p>Why be a white hat?\u00a0 The dark side is where all the money is made:<\/p>\n<ul>\n<li><a href=\"http:\/\/cseweb.ucsd.edu\/~voelker\/pubs\/eaas-ccs12.pdf\">Manufacturing Compromise: The Emergence of Exploit-as-a-Service<\/a><\/li>\n<\/ul>\n<ul>\n<li><a href=\"http:\/\/www.cs.gmu.edu\/~mccoy\/papers\/CCS12Priceless.pdf\">Priceless: The Role of Payments in Abuse-Advertised Goods<\/a><\/li>\n<\/ul>\n<p>Badware and goodware:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.cs.utexas.edu\/~shmat\/shmat_ccs12.pdf\">The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software<\/a><\/li>\n<\/ul>\n<ul>\n<li><a href=\"http:\/\/seclab.cs.ucsb.edu\/media\/uploads\/papers\/blacksheep.pdf\">Blacksheep: Detecting Compromised Hosts in Homogeneous Crowds<\/a><\/li>\n<\/ul>\n<p>Overall I enjoyed the conference, especially the \u201clocal flavor\u201d that the organizers tried to inject by serving stereotypical southern food (shrimp on grits, fried catfish) and hiring a bluegrass band (the thrilling\u00a0<a href=\"http:\/\/www.steepcanyon.com\/\">Steep Canyon Rangers<\/a>) for a private concert at Raleigh\u2019s performing arts center.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In October I attended the\u00a019th ACM Conference on Computer and Communications Security (CCS)\u00a0in Raleigh, North Carolina.\u00a0 It was my fourth time attending (and third city visited for) the conference. Here are some of my interesting takeaways from the conference: The next thing after ASLR?\u00a0\u00a0Address space layout randomization (ASLR)\u00a0is an anti-malware technique.\u00a0 Under ASLR you mix [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[4,7],"tags":[],"_links":{"self":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/970"}],"collection":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/comments?post=970"}],"version-history":[{"count":1,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/970\/revisions"}],"predecessor-version":[{"id":971,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/970\/revisions\/971"}],"wp:attachment":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/media?parent=970"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/categories?post=970"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/tags?post=970"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}