Last time Other malicious code Back doors Salami attacks Rootkits Interface illusions Keystroke logging

Man-in-the-middle attacks Nonmalicious flaws Covert channels Side channels 5-1 This time Finish side channels Controls against security flaws in programs Look at the stages of the software development lifecycle How to get the best chance of controlling all of the

flaws? 5-2 Side channels Eve can learn information about what Alice's computer is doing (and what data it is processing) by looking at: RF emissions Power consumption Audio emissions Reflected light from a CRT

Time it takes for Alice's computer to perform a computation These are especially powerful attacks when Alice's computer is a smart card (like a SIM chip or satellite TV card) that stores some kind of secret but is physically in Eve's possession 5-3 The picture so far We've looked at a large number of ways an attacker can compromise program security Exploit unintentional flaws Exploit intentional, but nonmalicious, behaviour of the system Introduce malicious code, including malware

The picture looks pretty bleak Our job is to control these threats It's a tough job 5-4 Software lifecycle Software goes through several stages in its lifecycle: Specification Design

Implementation Change management Code review Testing Documentation Maintenance At which stage should security controls be considered? 5-5 Security controlsDesign

How can we design programs so that they're less likely to have security flaws? Modularity Encapsulation Information hiding Mutual suspicion Confinement 5-6 Modularity

Break the problem into a number of small pieces (modules), each responsible for a single subtask The complexity of each piece will be smaller, so each piece will be far easier to check for flaws, test, maintain, reuse, etc. Modules should have low coupling A coupling is any time one module interacts with another module High coupling is a common cause of unexpected behaviours in a program 5-7 Encapsulation

Have the modules be mostly self-contained, sharing information only as necessary This helps reduce coupling The developer of one module should not need to know how a different module is implemented She should only need to know about the published interfaces to the other module (the API) 5-8 Information hiding The internals of one module should not be visible to other modules This is a stronger statement than encapsulation: the implementation and internal state of one module should be hidden from developers of other modules This prevents accidental reliance on behaviours not

promised in the API It also hinders some kinds of malicious actions by the developers themselves! 5-9 Mutual Suspicion It's a good idea for modules to check that their inputs are sensible before acting on them Especially if those inputs are received from untrusted sources Where have we seen this idea before? But also as a defence against flaws in, or malicious behaviour on the part of, other modules Corrupt data in one module should be prevented from corrupting other modules 5-10

Confinement Similarly, if Module A needs to call a potentially untrustworthy Module B, it can confine it (also known as sandboxing) Module B is run in a limited environment that only has access to the resources it absolutely needs This is especially useful if Module B is code downloaded from the Internet Suppose all untrusted code were run in this way What would be the effect? 5-11 Security controlsImplementation

When you're actually coding, what can you do to control security flaws? High on the list: Don't use C Unfortunately, that's not realistic in many situations One useful tool: static code analysis Also: Formal methods Genetic diversity 5-12 Static code analysis

There are a number of software products available that will help you find security flaws in your code These work for various languages, including C, C++, Java, Perl, PHP, Python They often look for things like buffer overflows, but some can also point out TOCTTOU and other flaws These tools are not perfect! They're mostly meant to find suspicious things for you to look at more carefully They also miss things, so they can't be your only line of defence 5-13 Formal methods

Instead of looking for suspicious code patterns, formal methods try to prove that the code does exactly what it's supposed to do And you thought the proofs in your math classes were hard? Unfortunately, we can show that this is impossible to do in general But that doesn't mean we can't find large classes of useful programs where we can do these proofs in particular Usually, the programmer will have to mark up her code with assertions or other hints to the theorem proving program This is time-consuming, but if you get a proof out, you can really believe it! 5-14

Genetic diversity The reason worms and viruses are able to propagate so quickly is that there are many, many machines running the same vulnerable code The malware exploits this code If there are lots of different HTTP servers, for example, there's unlikely to be a common flaw This is the same problem as in agriculture If everyone grows the same crop, they can all be wiped out by a single virus 5-15 Security controls Change management

Large software projects can have dozens or hundreds of people working on the code Even if the code's secure today, it may not be tomorrow! If a security flaw does leak into the code, where did it come from? Not so much to assign blame as to figure out how the problem happened, and how to prevent it from happening again 5-16 Source code and configuration control Track all changes to either the source code or the configuration information (what features to enable, what version to build, etc.) in some kind of management system

There are dozens of these; you've probably used at least a simple one before CVS, Subversion, git, darcs, Perforce, Mercurial, Bitkeeper, ... Remember that attempted backdoor in the Linux source we talked about last time? Bitkeeper noticed a change to the source repository that didn't match any valid checkin 5-17 Security controlsCode review Empirically, code review is the single most effective way to find faults once the code has been written The general idea is to have people other than the code author look at the code to try to find any flaws

This is one of the benefits often touted for open-source software: anyone who wants to can look at the code But this doesn't mean people actually do! Even open-source security vulnerabilities can sit undiscovered for years, in some cases 5-18 Kinds of code review There are a number of different ways code review can be done The most common way is for the reviewers to just be given the code They look it over, and try to spot problems that the author missed

This is the open-source model 5-19 Guided code reviews More useful is a guided walk-through The author explains the code to the reviewers Justifies why it was done this way instead of that way This is especially useful for changes to code Why each change was made What effects it might have on other parts of the system What testing needs to be done

Important for safety-critical systems! 5-20 Easter egg code reviews One problem with code reviews (especially unguided ones) is that the reviewers may start to believe there's nothing there to be found After pages and pages of reading without finding flaws (or after some number have been found and corrected), you really just want to say it's fine A clever variant currently being researched at Berkeley: the author inserts intentional flaws into the code The reviewers now know there are flaws The theory is that they'll look harder, and are more likely to find the unintentional flaws

It also makes it a bit of a game 5-21 Security controlsTesting The goal of testing is to make sure the implementation meets the specification But remember that in security, the specification includes and nothing else How do you test for that?! Two main strategies: Try to make the program do unspecified things just by doing unusual (or attacker-like) things to it

Try to make the program do unspecified things by taking into account the design and the implementation 5-22 Black-box testing A test where you just have access to a completed object is a black-box test This object might be a single function, a module, a program, or a complete system, depending on at what stage the testing is being done What kinds of things can you do to such an object to try to get it to misbehave? int sum(int inputs[], int length) 5-23 Fuzz testing

One easy thing you can do in a black-box test is called fuzz testing Supply completely random data to the object As input in an API As a data file As data received from the network As UI events This causes programs to crash surprisingly often! These crashes are violations of Availability, but are often indications of an even more serious vulnerability

5-24 White-box testing If you're testing conformance to a specification by taking into account knowledge of the design and implementation, that's white-box testing Also called clear-box testing Often tied in with code review, of course White-box testing is useful for regression testing Make a comprehensive set of tests, and ensure the program passes them When the next version of the program is being tested,

run all these tests again 5-25 Recap Controls against security flaws in programs Various controls applicable to each of the stages in the software development lifecycle To get the best chance of controlling all of the flaws: Standards describing the controls to be used Processes implementing the standards Audits ensuring adherence to the processes 5-26

Next time Protection in General-Purpose Operating Systems History Separation vs. Sharing Segmentation and Paging Access Control Matrix Access Control Lists vs. Capabilities Role-based Access Control


Recently Viewed Presentations

  • The iron content of runoff from a banana

    The iron content of runoff from a banana

    The iron content of runoff from a banana ranch is a necessary analytical parameter to analyze. A 25.0mL sample of the runoff was acidified with HNO3 and treated with excess KSCN to form a red complex.
  • Weathering, Erosion, and Deposition in Texas lesson 2

    Weathering, Erosion, and Deposition in Texas lesson 2

    Weathering, Erosion, and Deposition in Texas lesson 2. unit 4. TEKS 8B: The student will analyze the effects of weathering, erosion, and deposition on the environment in ecoregions of Texas.
  • 2013 Master Gardener State of the Onion

    2013 Master Gardener State of the Onion

    Speakers' Bureau. Jimmy Lee. Sally Lee. Debbie McLaury. Nanette O'Hara. Pat O'Shea. Virginia Overstreet. Chris Peterson. Nicole Pinson. Polly Ryan. Pam Shives
  • Bacterial Transformation LAB - Mr. G's AP Bio

    Bacterial Transformation LAB - Mr. G's AP Bio

    Bacterial Transformation LAB. Read the lab safety information and write the complete procedure (pp. S103-S105) in your notebook. THIS MUST BE DONE BEFORE YOU CAN PROCEED WITH THE LAB. 3. Write a simple hypothesis by comparing your sample with that...
  • BoM 22—Alma 5-7

    BoM 22—Alma 5-7

    "The city, I understood, was his. It was the City Eternal; and the people following him were to abide there in peace and eternal happiness.But who were they?"As if the Savior read my thoughts, he answered by pointing to a...
  • Systems Analysis and Design 9 Edition Chapter 9

    Systems Analysis and Design 9 Edition Chapter 9

    DBMS Components. Interfaces for Users, Database Administrators, and Related Systems. Related information systems. A DBMS can support several related information systems that provide input to, and require specific data from, the DBMS. No human intervention is required for two-way communication
  • Mobile Services: SobekPH - University of Florida

    Mobile Services: SobekPH - University of Florida

    This, of course, is only one possible strategy available for managing "paged" data, but inasmuch as it is a familiar UI idiom, it was the one we selected. It also allows us to restore the application state at a given...
  • What are microsatellites?

    What are microsatellites?

    How many beans make five? Genetic diversity analysis and taxonomy in the legume Ononis Jane Kloda Dr D MacDonald, Dr PGD Dean and Dr S Mayes Morphology Morphology Morphology Geography Cytology Flow Cytometry Taxonomy Aims How many groups are British...