crysp.uwaterloo.ca

crysp.uwaterloo.ca

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

5-27

Recently Viewed Presentations

  • First Fridays with the University Budget Office August

    First Fridays with the University Budget Office August

    CLASS - Kathryn Cullivan & Naomi Alvarado. College of Information - Rochelle Sykes. Advancement - Tom Augsburger. Alumni Relations -Margie Lagleder. Research & Innovation - Tori Smith. International Affairs - Jade Lu . Library - AK Khan.
  • Introductory Chemistry, 2nd Edition Nivaldo Tro

    Introductory Chemistry, 2nd Edition Nivaldo Tro

    Tro's "Introductory Chemistry", Chapter 4. Structure of the Nucleus. Rutherford proposed that the nucleus had a particle that had the . same amount of charge as an electron . but opposite sign. Based on measurements of the nuclear charge of...
  • Big-Data M e t h o ds Measurement

    Big-Data M e t h o ds Measurement

    Latent variable models assume that a collection of unobserved traits or attributes underlie observed test or survey responses. Most studies consider broadly defined, continuous latent variables. Broadly defined continuous latent variables are useful for correlational research and ranking individuals on...
  • Exploring the rules of engagement

    Exploring the rules of engagement

    Lecturers emphasised egt with subject- foregrounded concepts, meaning making, encouraging sts to 'do' the tasks disciplinary specilists do via EBL, collab learning, stdt research. * * Saw essay writing as a situated practice. Essay writing is implcilty framed by the...
  • Scripps Mercy Hospital Chula Vista - SDACNL

    Scripps Mercy Hospital Chula Vista - SDACNL

    Bedside huddle for all new admissions (SD) Centricity . EHR. Patient Navigation where a Case Manager (called Patient Care Navigator was rounding with the Hospitalist team avgas 12-15 pts) throughout the hospital from admission to discharge. This occurred from 2013-2015.
  • 11.7 Substituted Derivatives of Benzene and Their Nomenclature

    11.7 Substituted Derivatives of Benzene and Their Nomenclature

    11.7 Substituted Derivatives of Benzene and Their Nomenclature General Points 1) Benzene is considered as the parent and comes last in the name.
  • Transformations at the Beach - River Dell Regional School ...

    Transformations at the Beach - River Dell Regional School ...

    Rotations- Slide 26. ... Coordinate notation is another way of describing a translation. For example, if we use point A (1,4) and point A' (3,6), the way to describe that translation with coordinate notation would be (x + 2, y+2)....
  • Policy during a resource boom - Department of the Treasury

    Policy during a resource boom - Department of the Treasury

    Calibri Arial Wingdings Treasury Corporate 1_Treasury Corporate Microsoft Excel Chart Tax policy during a resource boom Global transformation underway World GDP projections Australia's terms of trade (Index 1900-01 to 1999-00 = 100) Mining share of investment Projections of the global...