1 / 22

Language-Based Security An Introduction

Language-Based Security An Introduction. Greg Morrisett Cornell University. Paper for this lecture. G.McGraw and G.Morrisett. “Attacking Malicious Code: A Report to the INFOSEC Research Council.” In IEEE Communications , Volume 17(5), Sept./Oct. 2000. Background:

Download Presentation

Language-Based Security An Introduction

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. Language-Based SecurityAn Introduction Greg Morrisett Cornell University

  2. Paper for this lecture G.McGraw and G.Morrisett. “Attacking Malicious Code: A Report to the INFOSEC Research Council.”In IEEE Communications, Volume 17(5), Sept./Oct. 2000. Background: • series of meetings of people from various US government agencies (DoD, FBI, CIA, NSA), industry, academia, and hacker communities. • goal was to identify promising research directions. • also informed by a DARPA ISAT study. • scary set of meetings... Lang. Based Security

  3. Computer Security Goal: prevent “bad” things from happening: • delete or trash files • crash a system • deny access to a service • steal information • fail to pay Similar goals to software engineering. Difference is in assumptions about “failures”: • must assume the worst possible case: attacks! Lang. Based Security

  4. What is “Bad”? Depends upon: • the task -- what is the code’s purpose? • the context -- what host, what OS, whose behalf? • the policy -- e.g., mandatory access Tighter constraints are better. who wrote the code memorysafety idealizedimplementation MAC type safety full specification “true” Lang. Based Security

  5. Mainframe Security Traditional security policies and mechanisms grew out of the shared mainframe world. • protect service (computing) from failures • protect users’ data from each other OS Kernel served as a Reference Monitor: • multiplex hardware among users’ programs • preemptive multi-tasking, indirect device access • isolate programs from each other • virtual memory address spaces, distinct supervisor mode • maintain integrity (privacy?) of users’ files • user & group id’s, access control lists Lang. Based Security

  6. 1st Principle of Security Design Least Privilege: each principle is given the minimum access needed to accomplish its task. [Saltzer & Schroeder ‘75] Examples: + Administrators don’t run day-to-day tasks as root. So “rm –rf /” won’t wipe the disk. - fingerd runs as root so it can access different users’ .plan files. But then it can also “rm –rf /”. Lang. Based Security

  7. Least Privilege Elsewhere Least Privilege shows up in almost all engineering design patterns. • SE & Languages: abstract data types, strong interfaces, encapsulation, black-box principle, etc. But the emphasis there is subtly different. • Easier to make changes to an implementation when the interface is enforced. Lang. Based Security

  8. 2nd Principle of Security Design Keep the Trusted Computing Base small. Trusted Computing Base (TCB): • the parts of a system that must work correctly to ensure the proper functioning of the system. • e.g., the OS Kernel & Hardware. Smaller, simpler systems tend to have fewer bugs and bad interactions. • so keep the kernel small and simple. “Small TCB” is a basic principle in all software. Lang. Based Security

  9. Things have changed... The principles of least privilege and small TCB are still valid. But the context that motivated the design of today’s security policies and OS-based enforcement mechanisms have changed radically. We need new policies and mechanisms. Lang. Based Security

  10. Changes: Back in the 1970’s, the hardware and kernel were simple, small and relatively trustworthy. Today, they’re HUGE. • Win2K: ~50 Mloc Why the growth? • personal vs. shared computers – protecting users from each other wasn’t that important. • old code never goes away. • richer set of devices (mice, cd, bluetooth, etc.) • services (e.g., gui, net, web, suspend, etc.) • performance – crossing boundaries is expensive. It’s hard to say these are small TCB’s. Lang. Based Security

  11. Further Changes In the ’70s, computing systems were isolated. • software updates done infrequently by an experienced administrator. • you trusted the programs you ran. • physical access was required. • few things were executable. • crashes and outages didn’t cost billions. The Internet has changed all of this. • software is constantly updated – sometimes without your knowledge or consent. • you have no idea what a program does. • a hacker in the Philippines is as close as your neighbor. • everything is executable (i.e., web pages, email). • we depend upon the infrastructure. Lang. Based Security

  12. Vendors few many Media hard soft Deliverymechanism physical electronic Frequency ofinstallation seldom always Size of package wholething smallpieces Permanence persistent ephemeral Trends: Lang. Based Security

  13. Nov 1988: CERT is created. 1994: Privatization of the Internet 1997: Pres. Commission on Critical Infrastructure Protection 1999: Morris joins MIT faculty. Timeline: 1975-2000 Trojan Horse 197? pushl $68732f push '/sh<NUL>' pushl $6e69622f push '/bin' movl sp,r10 save address of start of string pushl $0 push O (arg 3 to execve) pushl $0 push O (arg 2 to execve) pushl r10 push string addr (arg 1 to execve) pushl $3 push argument count movl sp,ap set argument pointer chink $3b do "execvet" kernel Call. Virus 1983 pushl $68732f push '/sh<NUL>' pushl $6e69622f push '/bin' movl sp,r10 save address of start of string pushl $0 push O (arg 3 to execve) pushl $0 push O (arg 2 to execve) pushl r10 push string addr (arg 1 to execve) pushl $3 push argument count movl sp,ap set argument pointer chink $3b do "execvet" kernel Call. The Morris Worm Oct 1988 pushl $68732f push '/sh<NUL>' pushl $6e69622f push '/bin' movl sp,r10 save address of start of string pushl $0 push O (arg 3 to execve) pushl $0 push O (arg 2 to execve) pushl r10 push string addr (arg 1 to execve) pushl $3 push argument count movl sp,ap set argument pointer chink $3b do "execvet" kernel Call. Melissa March 1999 Private Sub Document_Open() On Error Resume Next If System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <> "" Then CommandBars("Macro").Controls("Security...").Enabled = False System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") = 1&Else CommandBars("Tools").Controls("Macro").Enabled = False End If Dim UngaDasOutlook, DasMapiName, BreakUmOffASlice Set UngaDasOutlook = CreateObject("Outlook.Application") If System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\Office\", "Melissa?") <> "... by Kwyjibo" Then If UngaDasOutlook = "Inlook" Then explore.zipJune 1999 rem barok -loveletter(vbe) <i hate go to school> rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / Manila,Philippines On Error Resume Next dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow eq="" ctr=0 Set fso = CreateObject("Scripting.FileSystemObject") set file = fso.OpenTextFile(WScript.ScriptFullname,1) vbscopy=file.ReadAll main() sub main() On Error Resume Next Stacheldraht Feb 2000 Private Sub Document_Open() On Error Resume Next If System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") <> "" Then CommandBars("Macro").Controls("Security...").Enabled = False System.PrivateProfileString("", "HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Security", "Level") = 1&Else CommandBars("Tools").Controls("Macro").Enabled = False End If Dim UngaDasOutlook, DasMapiName, BreakUmOffASlice Set UngaDasOutlook = CreateObject("Outlook.Application") 911 virusApril 2000 From: The SANS Institute Research Office Subj: Malicious 911 Virus Wipes Out Hard Drives of Internet Users At 8:00 am on Saturday, April 1 (This is not an April Fool's joke!) the FBI announced it had discovered malicious code wiping out the data on hard drives and dialing 911. This is a vicious virus and needs to be stopped quickly. That can only be done through wide-scale individual action. Please forward this note to everyone who you know who might be affected. ILoveYouMay 2000 rem barok -loveletter(vbe) <i hate go to school> rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / Manila,Philippines On Error Resume Next dim fso,dirsystem,dirwin,dirtemp,eq,ctr,file,vbscopy,dow eq="" ctr=0 Set fso = CreateObject("Scripting.FileSystemObject") Badman TrojanJune 2000 Published on 06/09/2000, PITTSBURGH POST-GAZETTE HACKERS INVADE HOME COMPUTERS TO SET UP ATTACK The FBI will meet with experts from a security company today to discuss the firm's discovery that hackers have embedded a malicious program disguised as a movie clip on 2,000 commercial and home computers, positioning themselves to launch an attack designed to shut down Web sites. Lang. Based Security

  14. 1988: Morris Worm Penetrated an estimated 5 to 10 percent of the 6,000 machines on the internet. Used a number of clever methods to gain access to a host. • brute force password guessing • bug in default sendmail configuration • X windows vulnerabilities, rlogin, etc. • buffer overrun in fingerd Some remarks: • “bio-diversity” helped to limit the spread. • “root kits” for cracking modern systems are easily available and largely use the same techniques. Lang. Based Security

  15. 1999: Love Bug & Melissa Both email-based viruses that exploited: • a common mail client (MS Outlook) • trusting (i.e., uneducated) users • VB scripting extensions within messages to: • lookup addresses in the contacts database • send a copy of the message to those contacts Melissa: hit an estimated 1.2 million machines. Love Bug: caused estimated $10B in damage. Remarks: • no passwords or crypto involved Lang. Based Security

  16. Why Did they Succeed? • VBscripts invoked transparently upon opening. • Run with full privileges of the user. • Kernel doesn’t know about things like mail messages, contacts database, etc. • Recipients trusted the sender – after all, they know them. • Interactions of a complex system were unanticipated. Lang. Based Security

  17. A Solution for Melissa? Turn off all executable content? • no problem when email was just text. • but executable content is genuinely useful. • ex: automated meeting planner agent, postscript, Mpeg4 codecs, client-side forms, etc. • US DoD tried to do this and was hit with a revolt. You can’t function in the modern net-based world without scripting extensions. So there’s a fundamental tension: • modern software wants to be open and extensible. • programmable components are ultimately flexible. • Postscript, Emacs, Java[script], VB, Jini, ActiveX, plug-n-play... • security wants things to be closed: least privilege. • turning off extensibility is a denial-of-service attack. Lang. Based Security

  18. Solutions? Scan for viruses or suspicious code. • e.g., McAffee, Norton, etc. • based largely on a lexical signature. • perhaps the most commercially effective tool. • but only works for things you’ve seen. • Melissa spread in a matter of hours. • virus kits make it easy to disguise a virus. • not clear that it scales over time. Not a complete solution. Lang. Based Security

  19. Solutions? Code Signing: use crypto techniques to establish that someone you trust has signed the code. • e.g., Verisign, Authenticode, MS device drivers • bad assumption: signature implies “good” • keys may be stolen • “good” for what context? • even well-intentioned people make “bad” code • bad assumption: you can sue the signer • signatures have no legal standing (at least in US) • signer may not have written or even looked at the code • identifying who is responsible is difficult Lang. Based Security

  20. Turning off, Scanning & Signing Examine surface-level properties of code. • easy to build. • but sensitive to the form of the code. Oblivious to the semantics of the code. • hard to detect and stop new forms of attacks. • we want to stop bad things regardless as to who wrote the code. We’re going to focus on potential solutions that are based more strongly on the semantics or behavior of the code. • hence, language-based security. Lang. Based Security

  21. Security Enforcement Possible times to rule out “bad” things: • Before execution: • analyze code, reject if it’s potentially bad • rewrite the code so that it’s good • backup data so you can recover later • During execution: • monitor execution & stop bad things • detect that bad things happened and roll back • detect that bad things happened and log • After execution • call the police, present audit logs • sue somebody Lang. Based Security

  22. Outline for the Course • Reference Monitors (during execution) • operating systems, interpreters • software-based fault isolation • in-lined reference monitors • Type-Safe Languages (before execution) • SPIN: Modula-3 based kernel • Java VM, MS Common Language Runtime • Minimizing the TCB • Typed Assembly and Proof-Carrying Code • Certifying Compilers Lang. Based Security

More Related