Winter 2017 Vol

;login WINTER 2017 VOL. 42, NO. 4 : & Neural Nets Improve Password Choices William Melicher, Blase Ur, Sean M. Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Faith Cranor & DNSSEC: Useless as Used Taejoong Chung, Roland van Rijswijk-Deij, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, and Christo Wilson & Fixing the Bitcoin Blockchain Shehar Bano, Mustafa Al-Bassam, and George Danezis & Psychological Safety in SRE Teams John P. Looney & Interview with Peter G. Neumann Columns Exiting Gracefully in Python David Beazley Perl without Perl David N. Blank-Edelman tcpdump as a Monitoring Tool Dave Josephsen Using Vault in Go Chris “Mac” McEniry Collecting Big Data Dan Geer UPCOMING EVENTS Enigma 2018 USENIX Security ’18: 27th USENIX Security January 16–18, 2018, Santa Clara, CA, USA Symposium www.usenix.org/enigma2018 August 15–17, 2018, Baltimore, MD, USA Submissions due February 8, 2018 FAST ’18: 16th USENIX Conference on File and Storage www.usenix.org/sec18 Technologies Co-located with USENIX Security ’18 February 12–15, 2018, Oakland, CA, USA SOUPS 2018: Fourteenth Symposium on Usable Privacy www.usenix.org/fast18 and Security August 12–14, 2018 SREcon18 Americas Abstract submissions due February 12, 2018 March 27–29, 2018, Santa Clara, CA, USA www.usenix.org/soups2018 www.usenix.org/srecon18americas WOOT ’18: 12th USENIX Workshop on Offensive NSDI ’18: 15th USENIX Symposium on Networked Technologies Systems Design and Implementation August 13–14, 2018 www.usenix.org/woot18 April 9–11, 2018, Renton, WA, USA www.usenix.org/nsdi18 CSET ’18: 11th USENIX Workshop on Cyber Security Experimentation and Test SREcon18 Asia/Australia August 13, 2018 June 6–8, 2018, Singapore www.usenix.org/cset18 www.usenix.org/srecon18asia ASE ’18: 2018 USENIX Workshop on Advances in Security Education USENIX ATC ’18: 2018 USENIX Annual Technical August 13, 2018 Conference www.usenix.org/ase18 July 11–13, 2018, Boston, MA, USA Submissions due February 6, 2018 FOCI ’18: 8th USENIX Workshop on Free and Open www.usenix.org/atc18 Communications on the Internet Co-located with USENIX ATC ’18 August 14, 2018 www.usenix.org/foci18 HotStorage ’18: 10th USENIX Workshop on Hot Topics in Storage and File Systems HotSec ’18: 2018 USENIX Summit on Hot Topics July 9–10, 2018 in Security Submissions due March 15, 2018 August 14, 2018 www.usenix.org/hotstorage18 www.usenix.org/hotsec18 HotCloud ’18: 10th USENIX Workshop on Hot Topics in Cloud Computing SREcon18 Europe/Middle East/Africa July 9, 2018 August 29–31, 2018, Dusseldorf, Germany www.usenix.org/hotcloud18 www.usenix.org/srecon18europe HotEdge ’18: USENIX Workshop on Hot Topics OSDI ’18: 13th USENIX Symposium on Operating in Edge Computing Systems Design and Implementation July 10, 2018 October 8–10, 2018, Carlsbad, CA, USA www.usenix.org/hotedge18 Abstract registration due April 26, 2018 www.usenix.org/osdi18 www.usenix.org/facebook www.usenix.org/gplus www.usenix.org/linkedin twitter.com/usenix www.usenix.org/youtube WINTER 2017 VOL. 42, NO. 4 EDITOR Rik Farrow [email protected] EDITORIAL MANAGING EDITOR Michele Nelson 2 Musings Rik Farrow [email protected] SECURITY COPY EDITORS Steve Gilmartin 6 Global-Scale Measurement of DNS Manipulation Amber Ankerholz Paul Pearce, Ben Jones, Frank Li, Roya Ensafi, Nick Feamster, Nicholas Weaver, and Vern Paxson PRODUCTION Arnold Gatilao 14 An End-to-End View of DNSSEC Ecosystem Management Jasmine Murcia Taejoong Chung, Roland van Rijswijk-Deij, Balakrishnan Chandrasekaran, TYPESETTER David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, and Star Type Christo Wilson [email protected] 22 Securing the Internet, One HTTP 200 OK at a Time USENIX ASSOCIATION Wilfried Mayer, Katharina Krombholz, Martin Schmiedecker, 2560 Ninth Street, Suite 215 and Edgar Weippl Berkeley, California 94710 Phone: (510) 528-8649 26 Better Passwords through Science (and Neural Networks) FAX: (510) 548-5738 William Melicher, Blase Ur, Sean M. Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Faith Cranor www.usenix.org 31 The Road to Scalable Blockchain Designs ;login: is the official magazine of the USENIX Shehar Bano, Mustafa Al-Bassam, and George Danezis Association. ;login: (ISSN 1044-6397) is published quarterly by the USENIX 37 An Interview with Peter G. Neumann Rik Farrow Association, 2560 Ninth Street, Suite 215, Berkeley, CA 94710. SYSTEMS $90 of each member’s annual dues is for 42 Decentralized Memory Disaggregation Over Low-Latency Networks a subscription to ;login:. Subscriptions for Juncheng Gu, Youngmoon Lee, Yiwen Zhang, Mosharaf Chowdhury, non members are $90 per year. Periodicals and Kang G. Shin postage paid at Berkeley, CA, and additional mailing offices. SRE AND SYSADMIN POSTMASTER: Send address changes to Psychological Safety in Operation Teams John P. Looney ;login:, USENIX Association, 2560 Ninth Street, 50 Suite 215, Berkeley, CA 94710. 55 From Sysadmin to SRE in 2587 Words Vladimir Legeza ©2017 USENIX Association 59 Understanding Docker Kurt Lidl USENIX is a registered trademark of the USENIX Association. Many of the designa- COLUMNS tions used by manufacturers and sellers to distinguish their products are claimed 66 raise SystemExit(0) David Beazley as trademarks. USENIX acknowledges all 70 Practical Perl Tools: Perl without Perl David N. Blank-Edelman trademarks herein. Where those designations appear in this publication and 74 Go: HashiCorp’s Vault Chris “Mac” McEniry USENIX is aware of a trademark claim, 79 iVoyeur: Tcpdump at Scale Dave Josephsen the designations have been printed in caps or initial caps. 82 For Good Measure: Letting Go of the Steering Wheel Dan Geer 87 /dev/random: Cloudbursting, or Risk Mismanagement Robert G. Ferrell BOOKS 89 Book Reviews Mark Lamourine and Michele Nelson USENIX NOTES 92 2018 Election for the USENIX Board of Directors Casey Henderson 93 Thanks to Our Volunteers Casey Henderson 94 USENIX Association Financial Statements for 2016 Musings RIK FARROWEDITORIAL Rik is the editor of ;login:. lthough ;login: no longer has theme issues, this issue is loaded with [email protected] articles about security. Sitting in lofty isolation, I thought I would A muse this time about the three problems we have with computer security: hardware, software, and people. I don’t think I’ve left anything out. Hardware Most of the computers that people use (as opposed to simpler IoT devices) have hardware designs roughly like early timesharing mainframes. For the purposes of security, our computers have two relevant features: memory management and privileged modes. Memory management was designed to keep processes from interfering with each other and the operating system. You really don’t want someone else who is logged into another terminal (a device capable of displaying 24 lines of 80 characters each, a keyboard, and a serial interface maxing out at 19,200 baud [1]) writing into your process’s memory, and especially not the operating system’s memory. Note that terminals on early systems were often Teletype Model 33 ASRs, capable of uppercase only but also allowed input or output via a paper tape reader/puncher [2]. Teletypes used Baudot, just five bits per character, with a maximum rate of 10 characters per second. I actually used Teletypes on a Multics system in 1969. Memory management on mainframes in the 1970s didn’t always work well. In 1979, I crashed a mainframe, using a DECwriter 300, a much nicer and quieter terminal, while taking an operating systems course. I made a mistake entering a substitute command and only noticed when the command was taking forever to complete. I had created an infinite loop, essentially replacing each character with two copies of itself. What clued me in to what I had done was when other people in the terminal room started getting up and leaving, knowing it would take at least 20 minutes to reboot the mainframe. In our “modern” systems, memory management works very well at protecting processes from one another, and events like the one I just described won’t happen. This is where privilege mode [3] comes in. Because the operating system needs to be capable of doing things that normal processes cannot, the CPU switches into privilege mode when executing operating system code. While in privilege mode, the executing software can read or write anywhere in memory. Needless to say, this has made writing kernel exploits extremely popular. And as kernels are the largest single images with the most complex code (think multiple threads, locking, and device drivers) you generally run, there are lots of vulnerabilities to be found. You might be wondering why we rely on such ancient mechanisms as the hardware basis for our security. Think of these mechanisms as being like internal combustion engines: they’ve been around a long time and have gotten fantastically more efficient. There are other reasons for using these mechanisms: they are familiar to both CPU designers and programmers (see People, below). There was an alternative design, a mainframe built in the mid-to-late ’60s: the GE 645 (later Honeywell). The GE 645 had segment registers, essentially hardware used to add an offset to each memory address. Unlike memory management, segment registers as used in this design weren’t limited to large page sizes, so it was possible to have programs that could treat 2 WINTER 2017 VOL. 42, NO. 4 www.usenix.org EDITORIAL Musings different areas of memory as if they were different physical If I had been working as the CSO of a large financial company compartments, and limit access to those compartments. Please whose main business had to do with identity records, I would read my interview with Peter G. Neumann in this issue for more have insisted on having simple parsers, but also a gateway, a type on segmentation. of application firewall, that would limit access to the database to the expected queries, and rate limit the number of responses Intel’s flagship CPUs in the later ’80s also used segment regis- permitted.

Load more