1 Why do Programmers Write Insecure Code? There is no curriculum that addresses computer security in most schools. Programming books/classes do not teach.

1

Why do Programmers Write Insecure Code?

• There is no curriculum that addresses computer security in most schools.

• Programming books/classes do not teach secure/safe programming techniques.

• No one uses formal verification methods.

2

• C is an unsafe language, and the standard C library string functions are unsafe. This is particularly important because C is so widely used − the ``simple'' ways of using C permit dangerous exploits.

• Programmers do not think ``multi−user.'‘

• Programmers are human

• Most programmers are simply not good programmers. ·

3

• Most programmers are not security people; they simply don't often think like an attacker does.

• Most security people are not programmers.

• Consumers don't care about security.

4

Paranoia is a Virtue

5

• Open source vs. closed source security!

• Which is better?

6

Saltzer [1974] and later Saltzer and Schroeder [1975] list the following principles of the design of secure protection systems, which are still valid:

•Least privilege.

Each user and program should operate using the fewest privileges possible. This principle limits the damage from an accident, error, or attack. It also reduces the number of potential interactions among privileged programs, so unintentional, unwanted, or improper uses of privilege are less likely to occur. This idea can be extended to the internals of a program: only the smallest portion of the program which needs those privileges should have them.

7

•Economy of mechanism/Simplicity.

The protection system's design should be simple and small as possible. In their words, ``techniques such as line−by−line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential.'' This is sometimes described as the ``KISS'‘ principle (``keep it simple, stupid'').

8

•Open design

The protection mechanism must not depend on attacker ignorance.

Instead, the mechanism should be public, depending on the secrecy of relatively few (and easily changeable) items like passwords or private keys. An open design makes extensive public scrutiny possible, and it also makes it possible for users to convince themselves that the system about to be used is adequate. Frankly, it isn't realistic to try to maintain secrecy for a system that is widely distributed; decompilers and subverted hardware can quickly expose any ``secrets'' in an implementation. Bruce Schneier argues that smart engineers should ``demand open source code for anything related to security'', as well as ensuring that it receives widespread review and that any identified problems are fixed [Schneier 1999].

9

•Complete mediation.

Every access attempt must be checked; position the mechanism so it cannot be subverted. For example, in a client−server model, generally the server must do all access checking because users can build or modify their own clients.

10

•Fail−safe defaults (e.g., permission−based approach).

The default should be denial of service, and the protection scheme should then identify conditions under which access is permitted.

11

•Separation of privilege.

Ideally, access to objects should depend on more than one condition, so that defeating one protection system won't enable complete access.

•Least common mechanism.

Minimize the amount and use of shared mechanisms (e.g. use of the /tmp or /var/tmp directories). Shared objects provide potentially dangerous channels for information flow and unintended interactions.

12

•Psychological acceptability / Easy to use.

The human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly. Mistakes will be reduced if the security mechanisms closely match the user's mental image of his or her protection

·

13

14

Requirements and Safeguards for ECommerce

• Entity authentication

• Message integrity

• Payment non-repudiation

• Effective audit mechanism

• Privacy

15

POLICY

16

17

http://www.fish.com/security/murphy.html

ALL: .bad.domain: finger -l @%h |\ /usr/ucb/mail root

18

19

Basics

• Kernel based systems (Unix, Linux)vs

• Microkernel based systems (Win2k, GNU HURD)

• Mandatory access control (common criteria)

http://www.radium.ncsc.mil/tpep/library/fers/index.html

20

• UID 0

• GID 0

• Processes

• Threads

21

Typical attributes associated with each process in a Unix-like system:• RUID, RGID

– real UID and GID of the user on whose behalf the process is running ·

• EUID, EGID

– effective UID and GID used for privilege checks (except for the filesystem) ·

• SUID, SGID– Saved UID and GID; used to support switching

permissions ``on and off''

22

• setuid or setgid files

• May cause race conditions– Setuid scripts (#!/bin/sh)

• Open setuid script and Find needed interpreter

• Run it and set its uid

• It reopens the script to run it

• ??

– Linux?

23

Files

• The root or /• File systems: FAT, NTFS, EXT2, ..etc• FSOs

– ordinary files

– directories,

– symbolic links,

– named pipes (also called first-in first-outs or FIFOs),

– Sockets

– character special (device) files

– block special

24

• Most filesystems on Unix-like systems store at least the following:– owning UID and GID - identifies the ``owner'' of

the filesystem object– permission bits - read, write, execute bits for each

of user (owner), group, and other. · – ``sticky'' bit– setuid, setgid - when set on an executable file,

executing the file will set the process' effective UID oreffective GID to the value of the file's owning UID or GID (respectively)

– timestamps

25

• Creation Time Initial Values

• Changing Access Control Attributes

• Using Access Control Attributes

• Filesystem Hierarchy– http://www.pathname.com/fhs

26

System V IPC

• System V message queues• semaphore sets• and shared memory segments• Each has the following attributes:

– read and write permissions for each of creator, creator group, and others

– creator UID and GID - UID and GID of the creator of the object

– owning UID and GID - UID and GID of the owner of the object (initially equal to the creator UID)

27

Sockets and Network Connections• creates an endpoint for communication and returns

a descriptor• The parameters for socket specify the protocol

family and type (e.g., TCP/IP, Novell's IPX, …)• A server Application typically calls

– bind(2)

– listen(2),

– accept(2)

– select(2)

• A client typically calls– bind(2)

– connect(2)

28

Links

• http://www.lowtek.com/sockets/

• http://www.ibrado.com/sock-faq/

• http://tangentsoft.net/wskfaq/

29

Signals• Signals are a simple form of ``interruption'' • A process can set a ``signal'' on another process

(say using kill(1) or kill(2)), and that other process would receive and handle the signal asynchronously.

• To send an arbitrary signal to other process, the sending process must either have:– root privileges, or– the real or effective user ID of the sending process must

equal the real or saved set-user-ID of the receiving process

– some signals can be sent in other ways• SIGURG can be delivered over a network through the TCP/IP

out-of-band (OOB) message.

30

• Where possible, have your signal handlers unconditionally set a specific flag and do nothing else If you must have more complex signal handlers, use only calls specifically designated as being safe for use in signal handlers.

• In particular, don't use malloc() or free() in C (which on most systems aren't protected against signals), nor the many functions that depend on them (such as the printf() family and syslog()). You could try to ``wrap'' calls to insecure library calls with a check to a global flag (to avoid re-entry), but I wouldn't recommend it.

• Block signal delivery during all non-atomic operations in the program, and block signal delivery inside signal handlers.

31

Quotas and Limits• support filesystem quotas and process resource limits• ``hard'' vs. ``soft'' limits

• A ``hard'' filesystem quota limit is a never-to-exceed limit, while a ``soft'' quota can be temporarily exceeded– See quota(1), quotactl(2), and quotaon(8).

• rlimit mechanism process quotas:– file size, – number of child processes,– number of open files, and so on.

• ``soft'' limit (also called the current limit) and a ``hard limit'' (also called the upper limit). The soft limit cannot be exceeded at any time, but through calls it can be raised up to the value of the hard limit– See getrlimit(2), setrlimit(2), and getrusage(2), sysconf(3), and ulimit(1).

32

Dynamically Linked Libraries

• /etc/ld.so.conf

• Various environment variables can control the process od loading DLLs

• Permitting user control over DLLs could lead to interesting effects for setuid/setgid programs!

• http://www.dwheeler.com/program-library/

33

Audit

• Different Unix-like systems handle auditing differently. In Linux, the most common ``audit'' mechanisms are:– syslogd(8) – klogd(8)– wtmp(5) and utmp(5)– lastlog(8)– acct(2)– server programs (such as the Apache web server) also

have their own audit trail (see /var/log)

34

PAM

• Pluggable Authentication Modules (PAM)

• PAM permits run-time configuration of authentication methods (e.g., use of passwords, smart cards, etc.)

35

Specialized Security Extensions for Unix-like Systems• Jail

• http://docs.freebsd.org/44doc/papers/jail/jail.html

• Security-Enhanced Linux• http://www.nsa.gov/selinux/

• Rule Set Based Access Control (RSBAC) for Linux

• http://www.rsbac.de/

• Pluggable linux security module framework • http://mail.wirex.com/mailman/listinfo/linux-

security-module

• ... etc.

36

Security Requirements `Do you mean that you think you can find out the answer to it?' said the March Hare.

`Exactly so,' said Alice.

`Then you should say what you mean,' the March Hare went on.

`I do,' Alice hastily replied; `at least--at least I mean what I say--that's the same thing, you know.'

`Not the same thing a bit!' said the Hatter. `You might just as well say that "I see what I eat" is the same thing as "I eat what I see"!'

`You might just as well say,' added the March Hare, `that "I like what I get" is the same thing as "I get what I like"!'

`You might just as well say,' added the Dormouse, who seemed to be talking in his sleep, `that "I breathe when I sleep" is the same thing as "I sleep when I breathe"!'

`It IS the same thing with you,' said the Hatter, and here the conversation dropped, and the party sat silent for a minute, while Alice thought over all she could remember about ravens and writing-desks, which wasn't much.

37

Security Requirements

• “Before you can determine if a program is secure, you need to determine exactly what its security requirements are.”

• the Common Criteria, standardized as ISO/IEC 15408:1999.– The Common Criteria for Information Technology

Security Evaluation (CC). August 1999.– Version 2.1. Technically identical to International

Standard ISO/IEC 15408:1999.– http://csrc.nist.gov/cc/ccv20/ccv2list.htm

38

The Common Criteria for Information Technology Security Evaluation

• The CC document has three parts:– the introduction (that describes the CC overall),– security functional requirements (that lists various

kinds of security functions that products might want to include), and

– security assurance requirements (that lists various methods of assuring that a product is secure).

• the "Common Evaluation Methodology" (CEM)– guides evaluators on how to apply the CC when doing

formal evaluations

39

• The CC is typically used to create two kinds of documents:– a ``Protection Profile'' (PP) or – a ``Security Target'' (ST).

40

• To create a PP or ST– go through a process of identifying

• the security environment,

• Your assumptions,

• threats, and

• relevant organizational security policies.

• Two kinds of security requirements:– Functional requirements (what a product has to

be able to do), and– Assurance requirements (measures to inspire

confidence that the objectives have been met).

41

EALs

• Pre-created sets of assurance requirements called ``evaluation assurance levels'' (EALs)

• EAL 1 to 7

42

Security Environment and Objectives

• Consider:– the physical environment (can attackers access

the computer hardware?),– the assets requiring protection (files, databases,

authorization credentials, and so on), and – the purpose of the system (what kind of product

is it? what is the intended use?)

43

Security Functionality Requirements• the major classes of CC security requirements

– Security Audit (FAU)

– Communication/Non-repudiation (FCO)

– Cryptographic Support (FCS)

– User Data Protection (FDP)• access control or information flow rules,

• develop various means to implement the policy,

• possibly support off-line storage,

• import, and export, and provide integrity when transferring user data

44

• Identification and authentication (FIA)

• Security Management (FMT)

• Privacy (FPR)

• Protection of the TOE Security Functions/Self-protection (FPT)

• Resource Utilization (FRU)

• TOE Access (FTA).– controlling sessions (concurrency,

locking, ..etc).

• Trusted path/channels (FTP)

45

Security Assurance Measure Requirements• Configuration management (ACM)

• Delivery and operation (ADO)

• Development (ADV)

• Guidance documents (AGD)

• Life-cycle support (ALC)

• Tests (ATE)

• Vulnerability Assessment (AVA)

• Maintenance of assurance (AMA)

46

Input Validation

• Determine what is legal and reject anything that does not match that definition.

• Do not do the reverse: – identify what is illegal and write code to reject

those cases

• Use “illegal” values as a set of tests to be sure that your validation code is thorough

47

• Examples:– For strings, identify the legal characters or legal

patterns (e.g., as a regular expression) and reject anything not matching that form. There are special problems when strings contain control characters (especially linefeed or NIL) or metacharacters (especially shell metacharacters); it is often best to ``escape'' such metacharacters immediately

– Limit all numbers to the minimum (often zero) and maximum allowed values.

– email address (checker is actually quite complicated, because there are legacy formats that complicate validation)

– Filenames– URIs

• Also remember to decode any encoding first (IIS)– Cross site scripting

48

• Cookies

• Delimiters

• Special character/scripts/../../../winnt/system32/cmd.exe?/c+dir

/scripts/..%255c..%255c../winnt/system32/cmd.exe?/c+dir

49

• Command line– A setuid/setgid program's command line data is

provided by an untrusted user!– must not trust the name of the program reported

by command line argument zero

50

• Environment Variables– By default, environment variables are inherited

from a process' parent.– The calling program can set the environment

variables to arbitrary values.– setuid/setgid invoker can completely control the

environment variables

51

• Some Environment Variables are Dangerous– For example

• the IFS variable is used by sh and bash to determine which characters separate command line arguments

• /bin/sh

vs

• bin sh

52

• Environment Variable Storage Format is Dangerous– environment variables are internally stored as a pointer

to an array of pointers to characters; this array is stored in order and terminated by a NULL pointer

– The pointers to characters each point to a NIL-terminated string value of the form “NAME=value”

• environment variable names can't include the equal sign

• neither the name nor value can have embedded NIL characters.

• allows multiple entries with the same variable name with different values (e.g., more than one value for SHELL)

– Don’t manipulate environment variable yourself use glibc instead

53

• The Solution - Extract and Erase

• Extract the variables you need

• Erase the entire environment space

• If needed set the environment values once more

• environ = NULL;• clearenv();

54

File Descriptors

• Suid and standard input, output and error

55

File Names

• ..

• \/

• globbing– ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*

• BO using globbing?!

• rm –f/

56

File Contents

• 0x90 0x90 …etc.

57

Web-Based Application Inputs

• %HH encoding

• %2500 => %00 => NULL• http://victim.com/defualt.asp%00

• Cookie values

• Other http header fields

• Performing client side checking and forgetting server side checking!

58

Locales and i18n

• Locale information provided by Environment variable

• catgets, catopen, gettext– NLSPATH

59

Buffer overflows

60

Structure Program Internals andApproach• Follow Good Software Engineering Principles for

Secure Programs– Least privilege. – Economy of mechanism/Simplicity. – Open design. – Complete mediation.– Fail−safe defaults (e.g., permission−based approach). – Separation of privilege.– Least common mechanism.– Psychological acceptability / Easy to use.

61

Secure the Interface

• Interfaces should be:– minimal (simple as possible)– narrow (provide only the functions needed)– non−bypassable

• Trust should be minimized

• Consider limiting the data that the user can see

62

Separate Data and Control

• Any files you support should be designed to completely separate (passive) data from programs that are executed

• Don’t include scripts or macros• Especially auto-executing macros• I you have to violate the above make sure the

scripts run in a good sandbox!• Have the dynamic parts stored separately from the

static parts (e.g., separate file), so that it's easier to block them out when needed

63

From: http://www.cl.cam.ac.uk/~rja14/

I don't execute programs sent to me by strangers unless I have good reason, and then only after appropriate precautions. This means, in particular, that I don't read attachments in formats such as Microsoft Word, unless by prior arrangement. I also discard html-format emails unread, as the vast majority of them are spam. If you're trying to contact me from a hotmail account and don't get an answer, this may be the reason.

64

Minimize Privileges

• Minimize the Privileges Granted– For example:

create a special group, change a file's group ownership to that group, and then make the program setgid to that group

• consider creating a new pseudouser or pseudogroup – For example:

web servers typically need root privileges to start up (to use port 80), but once started they usually shed all their privileges and run as the user “nobody”

• If a process must run as root consider using POSIX capabilities

65

• Minimize the Time the Privilege Can Be Used

• Minimize the Time the Privilege is Active• Minimize the Modules Granted the

Privilege• Consider Using FSUID To Limit Privileges• Consider Using Chroot to Minimize

Available Files• Consider Minimizing the Accessible Data• Consider Minimizing the Resources

Available

66

• Minimize the Functionality of a Component

• Avoid Creating Setuid/Setgid Scripts

67

Configure Safely and Use Safe Defaults

• Configuration is considered the number one security problem

• you should – make sure the initial installation secure– make it easy to reconfigure the system while

keeping it secure.

68

• Default passwords!

• A program should have the most restrictive access policy until the administrator has a chance to configure it.

69

Load Initialization Values Safely

• Input validation

• Make sure an attacker cannot change configuration files

70

Fail Safe

• Bad example: Switch mode to hub mode• Good example: web server dropping long

requests• Consider what’s more important: the

confidentiality of information or service continuation

• Consider carefully what you send back in error messages

71

72

Avoid Race Conditions

• SLIP in attacks

• Deadlocks

73

• Atomic Actions in the Filesystem– Access then create

vs. – open with O_CREAT | O_EXCL

• Create files properly– the case of DEADJOE

• Changing meta information (permissions, owner, ..etc.)– Use fchown( ), fstat( ), or fchmod( ) on open

files– Don’t use chown(), chgrp(), and chmod() on

closed files!

74

• Temp files

• Locking

75

Trust Only Trustworthy Channels

• Don’t trust information controlled by local users (environment variables, ttyname)

• Don’t trust unauthenticated network transmissions

• Trusting DNS!

• Email

• HTTP (HTTP_REFERER)

76

Set up a Trusted Path

• Fake login programs– ctrl-alt-del

• Networked applications

• Web applications– http://www.ibm.com/[email protected]

77

• Use Internal Consistency−Checking Code– Asserts

• Self−limit Resources• Prevent Cross−Site (XSS) Malicious Content• Foil Semantic Attacks

– http://[email protected]– WWW.BLOOMBERG.COM

• Be Careful with Data Types– Signed vs. unsigned

78

Random Numbers

• In many cases secure programs must generate “random” numbers that cannot be guessed by an adversary.

• Truly random sources: values based on atmospheric noise, or thermal noise in electrical circuits.

• Some computers have a hardware component that functions as a real random value generator

79

random numbers that are sufficiently random!

• measuring variances in timing of low−level devices (keystrokes, disk drive arm jitter, etc.) in a way that an adversary cannot control.

• A cryptographically strong pseudo−random number generator (PRNG), which uses the state to generate ``random'' numbers.

• A large number of bits (in both the seed and the resulting value used).

80

• Do not use the PRNG included in programming libraries

• linear generators: next == (aX+b) mod m

• If possible, you should use OS services that are designed to create cryptographically secure random values– Linux: /dev/random

• use cryptographic hash functions (e.g., SHA−1) on PRNG outputs

81

• Protect Secrets (passwords, keys) in user memory– Disable core dumps via ulimit;– mmap to prevent swapping out the data;– don’t use immutable strings to store passwords;

• E.g., In Java, don't use the type String to store a password because Strings will not be overwritten until garbage-collected

• Maybe reused, possibly a far time in the future).• Instead, in Java use char[] to store a password, so it

can be immediately overwritten

– erase quickly once used

82

• Use existing unpatented crypto algorithms and protocols;

• don’t invent your own, use:– SSL/TLS, SSH, IPSec, OpenPGP(GnuPG),

Kerberos– AES– RSA/ElGamal– move from MD5 to SHA-1

83

Visual identification of high entropy regions

84

• While getting a true measure of entropy is a complex task, in practice the entropy of most program code is so low that a true measure is not needed.

• Examining a sliding window of 64 bytes of data and counting how many unique byte values were used gave a good enough measure of entropy.

• In the first body of code worked on the average window of data contained just under 30 unique values).

• The windows which covered the key data averaged 60 unique byte values

85

IEEE SECURITY & PRIVACY MARCH/APRIL 2003 http://computer.org/security/

86

IEEE SECURITY & PRIVACY MARCH/APRIL 2003 http://computer.org/security/

87

IEEE SECURITY & PRIVACY MARCH/APRIL 2003 http://computer.org/security/