1. slide 1 of 103 Internet Security: An Optimist Gropes For Hope Bill Cheswick, Chief Scientist Lumeta Corp ches@lumeta.com

2. CLNS 2003 slide 2 of 93slide 2 of 103

3. slide 3 of 103 Most common question from the press: “Is Internet security getting better or worse?”

4. slide 4 of 103 Universal Answer It is getting worse.

5. slide 5 of 103 Why?

6. CLNS 2003 slide 6 of 93slide 6 of 103 Aug. 1993 Writing FWAIS first edition “Most people use the Internet for email” The web was in the future Most attacks were still theoretical

7. CLNS 2003 slide 7 of 93slide 7 of 103 In August 1993 Morris sequence number hijack documented in the 80s, but not seen in the wild Wholesale password sniffing hadn’t been seen No DOS attacks Windows had no standard TCP stack, so it wasn’t a player After Morris worm, but worms were scarce – Sendmail had been patched and all was well in the world (not)

8. CLNS 2003 slide 8 of 93slide 8 of 103 CERT advisories: 1994 first advisory, released February 3, was a response to a dramatic increase in network monitoring by intruders, who were capturing passwords and installing "back doors" for future access to systems attacks increased in a single week from a few isolated reports to indications that tens of thousands of systems may have been compromised Unlike most security incidents, this one received extensive attention from the media the CERT team notified an archive site that their software being readied for distribution had been modified

9. CLNS 2003 slide 9 of 93slide 9 of 103 CERT advisories, 1994 CA-94:01 Ongoing Network Monitoring Attacks CA-94:02 Revised Patch for SunOS /usr/etc/rpm.mountd Vulnerability CA-94:03 AIX Performance Tools Vulnerabilities CA-94:04 SunOS /usr/ucb/rdist Vulnerability CA-94:05 MD5 Checksums: SunOS files CA-94:06 Writable /etc/utmp Vulnerability - SunOS 4.1.X CA-94:07 wuarchive ftpd Trojan Horse CA-94:08 ftpd Vulnerabilities- wuarchive and BSDI ftpd

10. CLNS 2003 slide 10 of 93slide 10 of 103 CERT advisories, 1994 (cont.) CA-94:09 /bin/login Vulnerability CA-94:10 IBM AIX bsh Vulnerability CA-94:11 Majordomo Vulnerabilities CA-94:12 Sendmail Vulnerabilities CA-94:13 SGI IRIX Help Vulnerability CA-94:14 Trojan Horse in IRC Client for UNIX CA-94:15 NFS Vulnerabilities

11. CLNS 2003 slide 11 of 93slide 11 of 103 Many attacks were theoretical… SYN packet flooding Mail flooding and similar application overflows TCP hijacking Hadn’t seen a worm in years Unix viruses were research topics Attacks on the TCP/IP stacks Packet amplification

12. CLNS 2003 slide 12 of 93slide 12 of 103 …and then they happened… Massive sniffing (1994) SYN packet DOS attacks (1996) TCP hijacking (1996) Ping-of-death (1996?) – Son of “crashme” SMURF (1997?) Massive worm and viral outbreaks – Mellissa, Code Red, etc. etc.

13. slide 13 of 103 There are a lot more players, and on average they are a lot less secure

14. CLNS 2003 slide 14 of 93slide 14 of 103 When I started at the Labs (Dec 1987) Most of the hosts on the Internet were listed in a single file named hosts.txt Most of the systems were various flavors of Unix or VMS Most systems had some sort of professional system administration, at least sometimes – Win98 was ten years away There wasn’t much at stake, perhaps even on MILNET MILNET was easy to disconnect, and sometimes was – Well, maybe. Numerous attacks were theoretical

15. CLNS 2003 slide 15 of 93slide 15 of 103 Now, everyone is on the Internet Grandma has ruined it for all of us The Internet subway goes to all the bad neighborhoods Vast, dangerous software packages with dangerous capabilities run nearly everywhere Most of the theoretical attacks are now implemented and used regularly.

16. CLNS 2003 slide 16 of 93slide 16 of 103 We’ve been losing ground for decades Bad guys are figuring out attacks that we have been waiting for over the years – Very few surprises Arms races are proceeding on many fronts Defense has improved slowly, even on systems where it ought to be easy to improve System administration is a nightmare – Open research problem

17. CLNS 2003 slide 17 of 93slide 17 of 103 Life cycle of a security bug, roughly It is first discovered It is first exploited, usually manually It is announced A patch is made available Some people patch the hole A worm or virus exploits the hole More people patch it Eventually the software goes away

18. slide 18 of 103 Yeahbuttal

19. slide 19 of 103 Cost vs. Benefits If you look at just one of these, you are doing half the job

20. CLNS 2003 slide 20 of 93slide 20 of 103 OTOH, tools we didn’t have in 1994 Available, working, distributable crypto No ssh Firewalls: build it yourself Stateful inspection had been pondered, but not available – Want to hack a kernel? IDS, honey pots, and lots of other tools available

21. CLNS 2003 slide 21 of 93slide 21 of 103 Bright spots, now The crypto export war appears to be over There are better tools available for some situations – Ssh – IPsec – Better Linux and Unix systems – Microsoft security initiative – Honeyd and other tools Un*x/Linux/GNU is freely available, and a reasonable solution

22. CLNS 2003 slide 22 of 93slide 22 of 103 I am optimistic. Good security is possible One can engineer reliable systems out of unreliable parts We have the home-field advantage: we can choose to set the rules on our hosts World-class encryption is now available and cheap The Bad Guys are giving us lots of practice

23. CLNS 2003 slide 23 of 93slide 23 of 103 There are a lot of benefits Some successful web business models – Fedex…package progress – Amazon: access to the 100,000 th book on the best seller list – Access to vast educational resources College courses Research papers in most disciplines Access to raw data – Better access to government (still spotty at the local level.)

24. CLNS 2003 slide 24 of 93slide 24 of 103 Financial business models are working On-line banking and brokerage access Paypal (bismuth) Internet access is so widely available and used that the states are starting to tax it Insurance companies are still reluctant to write hacking insurance – What does hurricane Andrew look like?

25. slide 25 of 103 And Microsoft…

26. slide 26 of 103 What does good security feel like? Confidence without hubris

27. CLNS 2003 slide 27 of 93slide 27 of 103 The Morris worm: Nov. 1988 I was running the Bell Labs firewall Heard about the worm on the radio upon awakening What was my first reaction? – This is what good security is about

28. CLNS 2003 slide 28 of 93slide 28 of 103 Some facts to keep in mind: economics Security is never perfect: economic concerns are always present What is the value of what we are trying to protect, and what is our adversary willing to spend – Miscomputation of this balance is the underlying cause of security breaches We are always aiming for “good enough”, though “good enough” has to be good enough

29. slide 29 of 103 Some things we can’t fix We have to engineer around them

30. CLNS 2003 slide 30 of 93slide 30 of 103 Social Engineering ``Hello, this is Dennis Ritchie calling. I’m in Israel now and I have forgotten my password.’’ ``Hello,, I’ve just started work here. said I should have an account on ‘‘

31. CLNS 2003 slide 31 of 93slide 31 of 103 I need to manage expectations here The Internet will never be 100% secure. Such security is not possible Some problems are over-constrained Security is always about economics – Good enough is good enough For many, the Internet is already good enough – Amazon, ebay, fedex, etc. etc. – Viruses, worms, spam aren’t that bad

32. CLNS 2003 slide 32 of 93slide 32 of 103 Software will always have bugs Perhaps DEK would be interested in working on inetd, and a web server. A kernel. Heck, the works… Marcus Ranum couldn’t get inetd right in 60 lines Perhaps formal methods will work some day – Must produce widely-useful morsels of software – Start with the likes of ASN.1 and openssl…

33. CLNS 2003 slide 33 of 93slide 33 of 103 People pick lousy passwords Best solution: don’t let them – Computer-generated keys are held in smart keys, USB dongles, etc. Don’t allow dictionary attacks on passwords, password-derived keys, PINS – This means that on-line authentication servers are needed…if you can crack something offline, it becomes a game of sniff-and-crack

34. CLNS 2003 slide 34 of 93slide 34 of 103 Some facts to keep in mind: users are not security experts Computer systems are fantastically complex: even the experts do not understand all the interactions People pick lousy passwords

35. CLNS 2003 slide 35 of 93slide 35 of 103 Social Engineering (cont.) Click here to infect your computer.

36. CLNS 2003 slide 36 of 93slide 36 of 103 Another problem with strange programs

37. CLNS 2003 slide 37 of 93slide 37 of 103 Managing expectations: Denial- of-Service It is here to stay Any public service can be abused by the public There are mitigations, but I don’t see full solutions Best solution: throw hardware at the problem

38. CLNS 2003 slide 38 of 93slide 38 of 103 Wireless passwords These are mostly POP3 (email) passwords G1zmoniq! kkB5cKkn0 pf-itAot?78 Mhr370Chiz YuzTmKm dugod123 tr.fbgi!

39. CLNS 2003 slide 39 of 93slide 39 of 103 Experts cut corners, too Fred Grampp’s password was easily found with a dictionary attack Ssh hijacking at conferences Temporary holes are forgotten

40. CLNS 2003 slide 40 of 93slide 40 of 103 I cheated on my authentication test # acct challenge response ches '00319 Thu Dec 20 15:32:22 2001 ' '23456bcd;f.k' OK root '00294 Fri Dec 21 16:47:39 2001 ' 'nj3kdi2jh3yd6fh:/' OK ches '00311 Fri Dec 21 16:48:50 2001 ' '/ldh3g7fgl' OK ches '00360 Thu Jan 3 12:52:29 2002 ' 'jdi38kfj934hdy;dkf7' OK ches '00416 Fri Jan 4 09:02:02 2002 ' 'jf/l3kf.l2cxn.' OK ches '00301 Fri Jan 4 13:29:12 2002 ' 'j2mdjudurut2jdnch2hdtg3kdjf;s'/s' OK ches '00301 Fri Jan 4 13:29:30 2002 ' 'j2mdgfj./m3hd'k4hfz' OK ches '00308 Tue Jan 8 09:35:26 2002 ' '/l6k3jdq,' OK ches '84588 Thu Jan 10 09:24:18 2002 ' 'jf010fk;.j' OK ches '84588 Thu Jan 10 09:24:35 2002 ' 'heu212jdg431j/' OK ches '00306 Thu Jan 17 10:46:00 2002 ' 'jfg.bv,vj/,1' OK ches '00309 Fri Jan 18 09:37:09 2002 ' 'no way 1 way is best!/1' OK ches '00309 Fri Jan 18 09:37:36 2002 ' 'jzw' NO ches '00368 Tue Jan 22 09:51:41 2002 ' '84137405jgf/' OK ches '00368 Tue Jan 22 09:51:56 2002 ' 'k762307924a/q' OK ches '80276 Fri Feb 1 15:00:18 2002 ' '/,f9gjh,md' OK ches '00165 Wed Feb 6 10:37:00 2002 ' 'jduse7fh.,cf' OK ches '67795 Mon Feb 11 08:50:11 2002 ' 'dbfho1jdh1m;dhfg' OK ches '00164 Thu Feb 14 09:37:16 2002 ' 'jpiw8eury3yru8fkdh' OK ches '00164 Thu Feb 14 09:37:34 2002 ' 'm1j4i0kk5;'' OK ches '00167 Mon Feb 18 09:34:06 2002 ' 'dm,c.lv/fl7' NO ches '77074 Tue Feb 19 09:02:52 2002 ' 'd' NO ches '77074 Tue Feb 19 09:02:57 2002 ' 'hbcg3]'d/' OK ches '00158 Wed Feb 20 11:33:24 2002 ' 'ebdj8fjtkd;' OK

41. CLNS 2003 slide 41 of 93slide 41 of 103 I cheated on my authentication test (cont.) ches '00156 Thu Feb 21 09:58:32 2002 ' 'jdufi46945jhfy37/' OK ches '00210 Thu Feb 21 09:59:12 2002 ' '123456abcdefihjd32/' OK ches '00163 Mon Feb 25 09:24:30 2002 ' 'd' NO ches '00163 Mon Feb 25 09:24:35 2002 ' 'ozhdkf0ey2k/.,vk0l' OK ches '00154 Tue Feb 26 10:54:48 2002 ' 'j4if9dl/0hgg/' OK ches '59810 Tue Mar 12 09:03:40 2002 ' '60673h4,dk/' OK ches '59810 Tue Mar 12 09:03:58 2002 ' 'ju607493,l;/' OK ches '00156 Tue Mar 12 12:41:12 2002 ' '3+4=7 but not 10 or 4/2' OK ches '00161 Fri Mar 15 09:41:20 2002 ' '/.,kl9djfir' OK ches '00161 Fri Mar 15 09:41:36 2002 ' '3' NO ches '00160 Mon Mar 25 08:52:59 2002 ' '222' OK ches '00160 Mon Mar 25 08:53:09 2002 ' '2272645' OK ches '29709 Mon Apr 1 11:36:34 2002 ' '4' OK ches '87197 Mon Apr 1 11:41:41 2002 ' 'x' NO ches '87197 Mon Apr 1 11:41:49 2002 ' '234jkfd' OK ches '00162 Wed Apr 3 10:43:58 2002 ' 'zb' NO ches '45303 Thu Apr 4 10:52:06 2002 ' 'bn' NO cges '45303 Thu Apr 4 10:52:10 2002 ' '' NO ches '45303 Thu Apr 4 10:52:15 2002 ' ''zx' NO ches '45303 Thu Apr 4 10:52:19 2002 ' 'zx' NO ches '41424 Mon Apr 8 09:49:09 2002 ' 'ab3kdhf' OK ches '85039 Tue Apr 9 09:46:06 2002 ' '04' OK ches '00154 Tue Apr 9 11:41:16 2002 ' '07' OK ches '00160 Tue Apr 16 08:58:29 2002 ' 'jdnfc8djd9dls';/' OK ches '00161 Thu Apr 18 10:49:10 2002 ' 'x' NO ches '00161 Thu Apr 18 10:49:14 2002 ' '898for/dklf7d' OK

42. slide 42 of 103 Some principles and tools Security 101, the slow part of the talk

43. CLNS 2003 slide 43 of 93slide 43 of 103 Security strategies Stay out of the game, if you can Defense in depth if you have to be in the game Always, always make it as simple as possible Design security in from the start: it is an attribute of the infrastructure, not a feature to be added later

44. CLNS 2003 slide 44 of 93slide 44 of 103 Staying out of the game “Best block is not be there” – Karate Kid 1 User’s password and PIN choices are less important if dictionary attacks are not possible Mellissa at Lucent – The Unix V7 mailer Avoiding the monoculture

45. CLNS 2003 slide 45 of 93slide 45 of 103 Defense in depth If you are dealing with imperfect systems, engineer redundancies to improve the reliability

46. CLNS 2003 slide 46 of 93slide 46 of 103

47. CLNS 2003 slide 47 of 93slide 47 of 103 Secure defaults are important If you use 10% of the features 90% of the time, the other features can be disabled This has long been a problem with Unix systems – Default network services include many dangerous ones – Most systems still need field-stripping New Microsoft security initiatives include a close examination of defaults

48. CLNS 2003 slide 48 of 93slide 48 of 103 Security doesn’t need to be inconvenient Modern hotel room keys Modern car keys

49. CLNS 2003 slide 49 of 93slide 49 of 103 Some solutions: Hardware tokens Digital Pathways SNK-004 SecureID – time-based S/Key – software or printout solution Many others – usually proprietary server software – New USB dongles are just the ticket!

50. CLNS 2003 slide 50 of 93slide 50 of 103 One-time Passwords RISC/os (inet) Authentication Server. Id? ches Enter response code for 70202: 04432234 Destination? cetus $

51. CLNS 2003 slide 51 of 93slide 51 of 103 Authentication …or use a USB or PCCard key You need them for your hotel room and rental car, and you don’t complain about that…

52. CLNS 2003 slide 52 of 93slide 52 of 103 Principles and tools: encryption Moore’s law fixed this We won the crypto wars

53. CLNS 2003 slide 53 of 93slide 53 of 103 Encryption is necessary, but not sufficient Many (most?) attacks aren’t associated with wiretaps IPsec is well-defined, and could be ubiquitous Microsoft ought to make it the default for their clients End-to-end encryption makes the wireless and Ethernet sniffing problem go away

54. CLNS 2003 slide 54 of 93slide 54 of 103 Tools: Trusted Computing Base This is hard, but there are usable solutions out there It’s debatable whether Microsoft has produced software yet that deserves to be trusted – Their new security thrust is real, but it is a huge job

55. CLNS 2003 slide 55 of 93slide 55 of 103 ftp stream tcp nowait root /v/gate/ftpd telnet stream tcp nowait root /usr/etc/telnetd shell stream tcp nowait root /usr/etc/rshd login stream tcp nowait root /usr/etc/rlogind exec stream tcp nowait root /usr/etc/rexecd finger stream tcp nowait guest /usr/etc/fingerd bootp dgram udp wait root /usr/etc/bootp tftp dgram udp wait guest /usr/etc/tftpd ntalk dgram udp wait root /usr/etc/talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal sgi-dgl stream tcp nowait root/rcv dgld uucp stream tcp nowait root /usr/lib/uucp/uucpd Default services SGI workstation

56. CLNS 2003 slide 56 of 93slide 56 of 103 More default services mountd/1 stream rpc/tcp wait/lc root rpc.mountd mountd/1 dgram rpc/udp wait/lc root rpc.mountd sgi_mountd/1 stream rpc/tcp wait/lc root rpc.mountd sgi_mountd/1 dgram rpc/udp wait/lc root rpc.mountd rstatd/1-3 dgram rpc/udp wait root rpc.rstatd walld/1 dgram rpc/udp wait root rpc.rwalld rusersd/1 dgram rpc/udp wait root rpc.rusersd rquotad/1 dgram rpc/udp wait root rpc.rquotad sprayd/1 dgram rpc/udp wait root rpc.sprayd bootparam/1 dgram rpc/udp wait root rpc.bootparamd sgi_videod/1 stream rpc/tcp wait root ?videod sgi_fam/1 stream rpc/tcp wait root ?fam sgi_snoopd/1 stream rpc/tcp wait root ?rpc.snoopd sgi_pcsd/1 dgram rpc/udp wait root ?cvpcsd sgi_pod/1 stream rpc/tcp wait root ?podd tcpmux/sgi_scanner stream tcp nowait root ?scan/net/scannerd tcpmux/sgi_printer stream tcp nowait root ?print/printerd 9fs stream tcp nowait root /v/bin/u9fs u9fs webproxy stream tcp nowait root /usr/local/etc/webserv

57. slide 57 of 103 If You Don’t have a Trusted Computing Base…

58. Firewalls Perimeter defenses

59. CLNS 2003 slide 59 of 93slide 59 of 103 Firewalls have their uses Medium-grade security Personal firewalls are useful Firewalls in cheap network equipment does a good job for simple, useful security policies

60. CLNS 2003 slide 60 of 93slide 60 of 103 Firewalls: Not a panacea Backdoors usually diminish the effectiveness Commercial firewalls are probably OK May give community a false sense of security The firewall is often the only secure part of a configuration – People go around them – People go through the bad ones – No protection from insiders

61. slide 61 of 103 Anything large enough to be called an “intranet” is probably out of control

62. CLNS 2003 slide 62 of 93slide 62 of 103

63. CLNS 2003 slide 63 of 93slide 63 of 103 This was Supposed To be a VPN

64. CLNS 2003 slide 64 of 93slide 64 of 103 Some intranet statistics from Lumeta clients

65. CLNS 2003 slide 65 of 93slide 65 of 103 Perimeter defenses don’t work if the perimeter is too big Small “enclaves” are much safer Implemented with – routing restrictions – Intranet firewalls – Encryptions Most of my family is in an enclave, and that is about as large as I’d like it to be

66. slide 66 of 103 Example: Life Without a Firewall Trusting Your Computing Base, or Skinny-dipping on the Internet

67. slide 67 of 103 It can be done

68. CLNS 2003 slide 68 of 93slide 68 of 103 Life without a firewall It’s like skinny-dipping For a security person, it keeps one focused Extra layers of security built into network services – Belt-and-suspenders “net-rot” (“route-rot”?) can be fatal Confidence in the face of wide-spread network mayhem

69. CLNS 2003 slide 69 of 93slide 69 of 103 We need to be able to trust our hosts Secure software with good system management Microsoft doesn’t hack it, yet. – Long history of putting features over security – A huge software base to fix – Customers used to dangerous services “Honey, I’ll be home at six” can have a virus!

70. CLNS 2003 slide 70 of 93slide 70 of 103 Secure host technology Goes way back: Multics, Burroughs Current efforts in *BSD systems (especially NetBSD) and Linux Jailing servers, clients(!) – Chroot technologies have a lot of promise – Need solutions over several Unixoid operating systems Microsoft’s security initiative appears to be real

71. CLNS 2003 slide 71 of 93slide 71 of 103 Secure host technology Digital Rights Management & Palladium can help us Load and run only approved software: that’s not all bad

72. CLNS 2003 slide 72 of 93slide 72 of 103 Routes to root root network services Interactive user Setuid programs Admin mistakes network services start

73. CLNS 2003 slide 73 of 93slide 73 of 103 root network services In general, there are way too many of them root network services Interactive user Setuid programs Admin mistakes network services start

74. CLNS 2003 slide 74 of 93slide 74 of 103 Setuid-root programs Waaaaaay too many of these root network services Interactive user Setuid programs Admin mistakes network services start

75. CLNS 2003 slide 75 of 93slide 75 of 103 find / -perm -4000 -user root -print | wc -l Root: the gateway to privilege

76. CLNS 2003 slide 76 of 93slide 76 of 103 AIX 4.2 & 242 & a staggering number \\ BSD/OS 3.0 & 78\\ FreeBSD 4.3 & 42 & someone's guard machine\\ FreeBSD 4.3 & 47 & 2 appear to be third-party\\ FreeBSD 4.5 & 43 & see text for closer analysis \\ HPUX A.09.07 & 227 & about half may be special for this host \\ Linux (Mandrake 8.1) & 39 & 3 appear to be third-party \\ Linux (Red Hat 2.4.2-2) & 39 & 2 third-party programs \\ Linux (Red Hat 2.4.7-10) & 31 & 2 third-party programs\\ Linux (Red Hat 5.0) & 59\\ Linux (Red Hat 6.0) & 38 & 2--4 third-party \\ Linux 2.0.36 & 26 & approved distribution for one university \\ Linux 2.2.16-3 & 47 \\ Linux 7.2 & 42\\ NCR Intel 4.0v3.0 & 113 & 34 may be special to this host \\ NetBSD 1.6 & 35 \\ SGI Irix 5.3 & 83 \\ SGI Irix 5.3 & 102 \\ Sinux 5.42c1002 & 60 & 2 third-party programs\\ Sun Solaris 5.4 & 52 & 6 third-party programs\\ Sun Solaris 5.6 & 74 & 11 third-party programs\\ Sun Solaris 5.8 & 70 & 6 third-party programs\\ Sun Solaris 5.8 & 82 & 6 third-party programs\\ Tru64 4.0r878 & 72 & \\ Setuid-root

77. CLNS 2003 slide 77 of 93slide 77 of 103 So, don’t have network services…. In general, there are way too many of them root network services Interactive user Setuid programs Admin mistakes network services start

78. CLNS 2003 slide 78 of 93slide 78 of 103 So, don’t have users… In general, there are way too many of them root network services Interactive user Setuid programs Admin mistakes network services start

79. CLNS 2003 slide 79 of 93slide 79 of 103 Get rid of setuid programs if you do have users In general, there are way too many of them root network services Interactive user Setuid programs Admin mistakes network services start

80. CLNS 2003 slide 80 of 93slide 80 of 103 Minimize root network services Use non-root services if at all possible root network services Interactive user Setuid programs Admin mistakes network services start

81. CLNS 2003 slide 81 of 93slide 81 of 103 Three layers of defense we might have Properly-programmed and configured server software, I.e. security bug-free Operating system user name and file permissions providing some protection Chroot and various jailing technologies – FreeBSD jail(1) – Various system call monitors Alas, chroot is the only standard

82. CLNS 2003 slide 82 of 93slide 82 of 103 Chroot In V7 Unix. Maybe earlier Restricts file system access only User root may^H^H^Hcan escape from chroot Non-root users cannot invoke chroot Many other attacks possible from chroot – Net access, cpu/file/swap exhaustion, system call probes

83. CLNS 2003 slide 83 of 93slide 83 of 103 Awful stuff you have to do to jail a program Make a static binary or – Include all the shared libraries in the chroot directory Build a whole file system (a la jail(1)) or – Copy each file into the jail – /etc/hosts, /dev/null, /dev/zero, /etc/passwd, etc Debug the startup Put the logs somewhere

84. slide 84 of 103 Example: a web server highly- resistant to defacement

85. CLNS 2003 slide 85 of 93slide 85 of 103 Goal A web server that cannot be defaced Read-only content – Provisioned by ssh from trusted client No active content Limited capacity (~20 queries/second)

86. CLNS 2003 slide 86 of 93slide 86 of 103 Implementation Inetd entry calls chroot for every HTTP query Chroot jails apache web server Server runs non-root, has write access only to logs and tmp directory Therefore, compromised server can only serve bad pages to the attacker Chroot doesn’t limit everything, or course – Net access – Swap, disk, CPU exhaustion

87. CLNS 2003 slide 87 of 93slide 87 of 103 Other software I have jailed POP3 (simple email) – May lose email if compromised Samba (windows SMB file system server) – May lose files if compromised HTTPS SSL for the web server – May lose the private key if compromised Simple services for web active content

88. CLNS 2003 slide 88 of 93slide 88 of 103 FOR THE FINAL APPROVAL IS THE FUND TO COMMENCE THIS TRANSACTION WHILE 80% WOULD BE INVESTED AND YOU HAVE ABSOLUTE CONTROL OVER THIS IS WHAT IS CALLED TOPPING(ADDITION/LOADING OF EXTRA QUANTITIES/BARRELS ON TO THE SON OF THE FUND FROM HIS ACCOUNT UNLESS SOMEONE APPLIES FOR CLAIM AS THE NEXT OF KIN. I AM OPEN TO ADVICE. PLAESE DO GET BACK TO ME AS SOON AS BE REST ASSURED THAT THERE IS ABSOLUTELY NO RISK INVOLVED IN ANY FINANCIAL TRANSACTION WHATSOEVER, THE NETHERLANDS WHO WILL ASSIST ME IN THE NETHERLANDS PROHIBIT A REFUGEE (ASSYLUM SEEKER) TO OPEN ACCOUNT OR TO BE AGREED UPON WHEN WE COME DOWN OVER THERE BECAUSE WE CANNOT RELEASE THE TOTAL SUM $15.5 MILLION USD IN A PLACE OF YOUR INTEREST BY A RETURN E-MAIL AND ENCLOSE YOUR PRIVATE CONTACT TELEPHONE NUMBER FAX NUMBER FULL NAME AND ADDRESS OR YOUR COMPANY NAME ADDRESS AND ENDEAVOUR TO FURNISH ME WITH YOUR FULL THIS TRANSACTION AND CLAIM THE BOXES FROM THE DESK OF MR IBE OKONDU ECO BANK PLC LAGOS-NIGERIA +234+01+2902565

89. CLNS 2003 slide 89 of 93slide 89 of 103 Generic Viagra is a trademark of the receipt of your country, who used to work with you based on trust as the funds you will remain honest to me till the end of the Petroleum Resources (NNPC) by a foreigncontracting firm, which we wish to enter into a safe foreigners account abroad before the rest.But I don't know any foreigner,I am only contacting you because the management is ready to give you reasonable share of the Nigerian National Petroleum Corporation. On completion of our present situation I cannot do it all by It is from the company. For onward sfer to your home within 14 working days of commencement after receipt of the funds.You know my father I happen to be used in settling taxation and all local and foreign exchange departments. At the conclusion of this letter using the above e-mail address. I will give to you I await your response. Yours sincerely Taofeek Savimbi. Please click here

90. CLNS 2003 slide 90 of 93slide 90 of 103 Some jail themselves, or should DNS/bind Maybe apache someday NTP should, and needs least-privilege time setting permissions. Write permission on /dev/time? PAM service?

91. slide 91 of 103 Example: Amazon, Fedex, …

92. CLNS 2003 slide 92 of 93slide 92 of 103 Things are getting better: we have business models We know a bit about hacking and loss rates Insurance companies are starting to write hacking insurance – Question: what does hurricane Andrew look like on the Internet?

93. slide 93 of 103 Example: Spook networks

94. CLNS 2003 slide 94 of 93slide 94 of 103 Talk to spooks: they have security experience Don’t try to get their secrets, get their security advice A number of secret networks appear to be well-run – Slammer-free – Rare virus sightings They do all the stuff we all know about, and Management uses a big hammer for compliance Bigger problem than spies: morons

95. CLNS 2003 slide 95 of 93slide 95 of 103 Spooks Use enclaves Run their own compilers Buy off-the-shelf hardware Restrict client software Spend a lot of money testing things like openssl – The public could use this research

96. CLNS 2003 slide 96 of 93slide 96 of 103 Spooks… Watch their networks closely Make IP addresses useful – No RFC 1918, they need accountability

97. slide 97 of 103 Ches’s wish list (incomplete)

98. CLNS 2003 slide 98 of 93slide 98 of 103 Ches’s wish list More work on chroot/jail Implement on *BSD and Linux, or the job’s not done Plan 9 has some nice ideas to check out Better user file system access model than NFS- based solutions – Revisit the DFS wars of the mid-80s More tiny, tested servers with limited capabilities Operating system security enhancements, and installation scripts that make them useful Sandboxes and similar technologies in Windows

99. CLNS 2003 slide 99 of 93slide 99 of 103 More wishes Rigorous formal cryptographic protocol design and verification Rigorous TCB in modern kernels, compilers, etc – If this were easy, it would have been done by now – Of course, it has been done Hardware support for non-executable stack, etc. – Dreams of Burroughs machines?

100. CLNS 2003 slide 100 of 93slide 100 of 103 Ches’s wish list Sandboxes for browsers! – I want to be able to run Java and Javascript and even plug-ins without fear – Why is this hard? Operating systems have done stuff like this for decades? Better firmware in routers

101. CLNS 2003 slide 101 of 93slide 101 of 103 Still theoretical Major BGP hijacking Successful root DNS DoS Dual-boot infections Major router/IOS worm Attacks that damage actual hardware

102. slide 102 of 103 Conclusion I think things can get better But it is going to take work and diligence

103. CLNS 2003 slide 103 of 93slide 103 of 103 Questions http://research.lumeta.com/ches/ ches@lumeta.com Yes, I’d love to sign your book