1

2

Requirements and Safeguards for ECommerce

• Entity authentication

• Message integrity

• Payment non-repudiation

• Effective audit mechanism

• Privacy

3

POLICY

4

5

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

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

6

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

7

• UID 0

• GID 0

• Processes

• Threads

8

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''

9

• 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?

10

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

11

• 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

12

• Creation Time Initial Values

• Changing Access Control Attributes

• Using Access Control Attributes

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

13

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)

14

Links

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

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

• http://tangentsoft.net/wskfaq/

15

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.

16

• 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.

17

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).

18

Dynamically Linked Libraries

• /etc/ld.so.conf

• Various environment variables can control the process of loading DLLs

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

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

19

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)

20

PAM

• Pluggable Authentication Modules (PAM)

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

21

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.

22

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.

23

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

24

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

25

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

26

• 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).

27

EALs

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

• EAL 1 to 7

28

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?)

29

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

30

• 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)

31

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)

32

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

33

• 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

34

• Cookies

• Delimiters

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

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

35

• 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

36

• 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

37

• 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

38

• 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

39

• 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();

40

File Descriptors

• Suid and standard input, output and error

41

File Names

• ..

• \/

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

• BO using globbing?!

• rm –f/

42

File Contents

• 0x90 0x90 …etc.

43

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!

44

Locales and i18n

• Locale information provided by Environment variable

• catgets, catopen, gettext– NLSPATH

45

Buffer overflows

46

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.

47

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

48

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

49

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.

50

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

51

• 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

52

• Minimize the Functionality of a Component

• Avoid Creating Setuid/Setgid Scripts

53

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.

54

• Default passwords!

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

55

Load Initialization Values Safely

• Input validation

• Make sure an attacker cannot change configuration files

56

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

57

58

Avoid Race Conditions

• SLIP in attacks

• Deadlocks

59

• 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!

60

• Temp files

• Locking

61

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)

62

Set up a Trusted Path

• Fake login programs– ctrl-alt-del

• Networked applications

• Web applications– http://www.ibm.com/stuff@mysite.com– http://www.ibm.com/stuff@mysite.com– http://www.ibm.com/stuff@mysite.com

63

• Use Internal Consistency−Checking Code– Asserts

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

– http://www.bloomberg.com@www.badguy.com– WWW.BLOOMBERG.COM

• Be Careful with Data Types– Signed vs. unsigned

64

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

65

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).

66

• 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

67

• 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

68

• 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

69

Visual identification of high entropy regions

70

• 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

71

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

72

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

73

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