Security and protection

CS 273 (OS), Fall 2020

Preliminaries

• Issues of security vs. protection mechanisms to address them.

• Categories of security issues

  • Availability: selectively allowing agents rights to access assets; keeping those assets available

  • Secrecy: selectively denying agents access to assets; enforcing those limits

  • Authenticity: verifying an agent and that agent's access rights

  • Integrity: maintaining consistency and functionality of assets

  Terms

  • Asset -- information, system resource, subsystem, etc.
  • Agent -- an entity capable of using an asset, whether human or computational
  • Access -- the ability for an agent to use an asset
  • Right -- a particular access privilege, allowing an agent to use an asset in a specific way

• Ethical issues related to security. Examples:

  • Privacy
  • Property rights
  • Equity and access
  • Risk and reliability
  • Use of power
  • Honesty and deception
  • Quality of life

• Scale of intentionality; scale of danger.

Examples of famous security flaws

What went wrong in these? How could they be fixed?

• lpr -rm (...as setuid root)

• mkdir (...when creating i-node and changing ownership was not atomic, substituting link to passwd)

• Multics poor security for batch processes

• Trojan horse attack, e.g., editor.

• TENEX password checking and page boundaries. (Brute force attack; inferencing)

• OS 360 authentication then read a user-modifiable data structure to perform a system call, e.g., to read a (secret) file... combined with DMA operation from tape to user space to overwrite that data structure just after authentication.

• Internet worm (1988, Robert Morris)

  • Strategy: 99-line bootstrap ll.c compiled on target machine; bootstrap loads another program that tries to break passwords on other machines.
  • Methods for infecting another computer with the bootstrap:
    • rsh (predecessor of ssh)
    • Overwrite finger stack with a long parameter in order to modify return address from request handler function to worm's code (see buffer overflow attack below).
    • Debug mode in sendmail to run remote process

Types of security attack

Internal

• Trojan horse

  • An innocent-looking program performs unexpected, undesirable functions
  • Example: hide a malicious program la (typo misspelling of ls) in an obscure directory on default PATH
  • A form of masquerading
  • Example countermeasures:
    • Make directories in standard executable-search paths writable by trusted accounts only.
    • Disallow current directory in paths, or place only at end of path.

• Login spoofing

  • Create program that simulates login, but also captures unencrypted password.
  • A form of masquerading
  • Example countermeasure: Require a key sequence that cannot be processed by a user program to initiate login sequence (Windows 2000)

• Logic bomb

  • Developer secretly inserts code into a product that is capable of damaging the system. Possible motivation: reprisal for getting laid off.
  • Could cause a catastrophic or subtle corruption of the system.
  • Example countermeasure: Code review

• Trap door

  • A system programmer adds bypasses of usual security checks
  • Examples: Internet worm's sendmail attack; add a special case to authentication code.
  • Example countermeasure: Code review.

• Buffer overflow

  • Exploit a lack of runtime bounds checking for array, stack, etc., to modify a program's code or data.
    See Fig 9-24, p. 660: calling a procedure A with fixed buffer size for parameter, but supplying an oversize parameter, causes A to overwrite its own return value when copying that parameter, and to supply alternate code (in that parameter) to execute on return of A.
  • Example: Internet worm's attack on finger
  • Example countermeasure: Programmer or system must vigilantly check range bounds.

• Covert channel

  • Convince an insider to leak electronic data to a collaborator in a way that system manager won't notice.
  • Examples: induce poor system performance to indicate a 1, better performance to indicate a 0, with Hamming code to handle the "noise"; steganography (see Fig 9-16, p. 640)
  • Countermeasures are solutions to the confinement problem

• Generic system attacks

  • Examples:
    • Peruse unallocated pages, disk blocks, etc., that have not been erased, without modifying any data (browsing).
    • Try illegal system calls, or legal system calls with illegal or unreasonable arguments. Likewise for library functions, system programs, etc.
    • Send interrupts during login sequence, setuid scripts, etc.
    • Find user-space data structures that are shared by the kernel, and modify them. (Illustration: Suppose struct sockaddr was used by kernel after an original bind() call)
    • Look for "Do not do X" in manuals, and try as many variations of X as possible.
    • Bribe the secretary. (Security leak)
    • Get physical access to machine; reboot with your own boot CD.
  • Typical countermeasure: Hire a tiger team to perform such attacks on your system and report what they find to you. Then take countermeasures accordingly.

External

• Virus

  • Code that can reproduce itself by attaching itself to the code of another (legitimate) program.
    Virus writer inserts virus into his/her own copy of program, using a dropper tool, then gets people to download the infected program.
    Virus code typically first tries to infect other programs on a machine, then executes its payload.
  • Some types of viruses:
    • companion virus -- e.g., "jacket" in shortcut
    • overwriting virus -- overwrite the code of process when program executed.
    • parasitic virus -- e.g., append virus code to executable file, and modify program to jump to that virus code then return to carry out program as usual
    • cavity virus -- hide virus in internal fragments (if they're loaded)
    • memory resident virus -- e.g., jacket around an interrupt vector entry (perhaps the one used for system calls)
    • boot sector virus
    • device driver virus
    • macro virus
    • source code virus
  • Example countermeasures:
    • Virus scanner
    • Integrity checker -- compare checksum of executable to original checksum value, to detect changes.
    • Behavior checker
    • Virus avoidance

• Denial of service attack

  • Occupy so many resources of a system (computer, server, etc.) that others can't use it.
  • Example: Thousands of computers send time-coordinated requests to a target web server; virus that consumes CPU time or DMA
  • Example countermeasure: Detect source of attack, block that source, and restart system

• Worm

  • Standalone program that infects other computers via network
  • Examples:
    • Applet
    • "Agent" such as a web crawler
    • Postscript file
  • Example countermeasures:
    • Sandboxing: limit virtual address range of mobile code
    • Use an interpreter, e.g., JVM, to limit the permissible operations of downloaded code.
    • Run downloaded applications only from trusted sources; use digital signatures to authenticate source.
  • Java started with sandboxing (JDK 1.0), proceeded to digital signatures (1.1), then to a complicated system (1.2)

Authentication

• Passwords

  • Encryption of passwords.
  • Easily guessed passwords, e.g., obvious relationship to username, short, appears in a dictionary, small universe of characters.
    Note. 8 digits-->10⁸; 8 letters-->26⁸ = 2.1x10¹¹; 8 digits or letters, both cases-->62⁸ = 2.2x10¹⁴; 8 printable ASCII-->223⁸ = 6.1x10¹⁸
  • Salting the password file.
  • Password generating programs
  • One-time password
  • Challenge-response (user and system agree on an algorithm)
  • Question and answer ("What did Mrs. Woroboff teach?")

• Physical identification

  • ID card
  • Signature analysis
  • Thumbprint; voice analysis
  • Finger length; retinal scan?

• Some other authentication strategies

  • Dial-up callback; cf. pizza.
  • Two factor
  • (Increasing) delay between unsuccessful login attempts
  • Record of logins; report of last login.
  • Set a trap, e.g., unprotected account
  • Demise of anonymous FTP

Protection mechanisms

• Basic concepts

  • Protection domains, e.g., (uid, gid)
  • Domain switch
  • Protection matrix: objects x domain

    	Object
    Domain	file1	file2	file3	file4	file5	file6	pr1	pr2
    1	R	RW
    2			R	RWX	RW		W
    3						RWX	W	W

• Access control lists

  • Explicit list of domains and rights per object
  • Owner may modify the list
  • Example: RCS files (e.g., ~cs273/.bin/submit.sh)
  • Compare: Linux (uid,gid)
  • St. Olaf's 10G network switch software

• Capabilities

  • Explicit list of objects and rights per domain. A capability is an element of this list.
  • Users must not add or remove capabilities. Locate in kernel? Encrypt?
  • Manager modules per type of object (which must have their own capabilities).
  • Difficult to revoke access

Standards

• Orange Book (Trusted Computer System Evaluation Criteria) (1985), produced by U.S. Department of Defence (DoD).

• Common Criteria (for Information Technology Security Evaluation) (2005), produced by International Standards Organization (ISO)

Some principles of security

• Be educated about security as a user, system administrator, implementer and/or designer.

  • "Dot" should only appear last in PATHs
  • Pick good passwords. Never write them down, especially on any computer.
  • Know examples of security flaws.

• Think security throughout design and implementation.

  • Consider security thoroughly at every phase of software development, starting with fundamental design.
  • Check for current authority. (Multics)
  • Make security-related operations atomic, e.g., mkdir
  • Know and avoid implementation practices that have security implications, e.g., check for buffer overflow.
  • Make unsuccessful attempts look like successful attempts for as long as possible. For example, don't report illegal username before reading entire password and processing it as normal.

• Make security design simple and verifyably correct

  • Make protection mechanisms simple, uniform and built into the lowest layers of a system. (Multics)
  • Verify security design and implementation using logical rigor, e.g., asserts.

• Beware of unsafe assumptions upon which security depends.

  • Make the system design public (Multics), lest designers delude themselves about what an attacker wouldn't know.
  • Never fall into the trap of trusting "security through obscurity."
  • Verify beliefs about your system's security with rigorous logic and mathematics.

• Give the least possible access in every conceivable way.

  • The default should be no access (Multics). For example, IIT doesn't even allow ssh connections from remote machines.
  • Give each process the least possible privilege (Multics). For example, shells on firewall unable to execute anything except an internal connection to a couple of closely monitored machines.

• Seriously test security.

  • Look for "hints for hackers" that may be present in your system. Even the most indirect clues can and will be used against you.
  • Give no hints in documentation about potential vulnerabilities in the system. Also, prevent security vulnerabilities in the system (see think security throughout design and implementation, make security design simple and correct, etc.).
  • Hire a tiger team.

• Security/convenience tradeoff.

  • If a system requires a different password for every computer, and if users need to use multiple computers, they will tend to use post-it notes to remember all the passwords, compromizing security.
  • Two-character passwords are convenient; empty passwords are even more convenient.
  • Psychologically unacceptable schemes (e.g., involving bodily fluids) will not be used. (Multics)