By: Bumhwan Cha, Alan Chao, Dan Hirsch, Juan M. Navarro, Charles Roh

1. There exists a UNIX feature called "close-on-exec" file descriptor. Such a file descriptor is closed on

1. fork()
2. getpid()
3. xor instruction
4. exec()

Answer: exec()

2. How many processes does this create?

 for(i = 100; i > 0; i--)
     fork();

 Answer: 2^100

 Explanation: Let f(N) be the number of processes that exist after N iterations of the for loop. Then,
              f(0) = 1
              f(1) = 2
              f(2) = 2 * f(i - 1)    , for N > 2

First, let us define some essential terminology:

• Principal: Refers to a model of a user given certain rights and privileges to execute functions on a particular system.

The primary goals of computer security boil down to one positive goal, and one negative goal:

• Positive Goal: The system must perform every legitimate function requested by a legitimate principal.
• Negative Goal: The system will not perform any illegitimate function requested by a principal.

How do we know if a function is either legitimate or illegitimate? Functions are policy based! The system administrators whose goals are to keep a system secure must define a set of rules that every potential user will have to follow. For example, a sample policy might be, "Only Human Resources (HR) can access everyone's social security number." After establishing a policy such as this one, however, other questions arise. Questions such as, "What if an unauthorized user claims to be HR?" lead the system administrators to implement mechanisms to ensure the security of the systems at hand.

Database-backed websites provide an easily-accessible web front-end to end users. The clean user interfaces provided by these websites hide a lot of functionality that is implemented in the back-end servers that support such sites. For example, a website might contain a "Username" and "Password" fields, for the user to log in to a user-specific portion of the site. To authenticate the user, however, the web service must communicate with a database that contains the user information of all valid users. This sample implementation leaves the system open and vulnerable to several attacks that could be performed by malicious users.

In order to ensure authentication, there must be a "secret" that is only known by the legitimate principal and the system. An example of this "secret" is a user password, or a pin number that is associated with a user name.

Sample pseudo-code written in PHP to authenticate a user might look like:

 $result = mysql_query("select username from users where username = '$u' and password = '$p'");
 if(mysql_count_rows($result > 0))
      okay();
 else
      bad_login();

An attacker seeking to exploit the bugs in this code could then enter the following information on the web front-end:

 Username: hr
 Password: ' or true

and have the system return all rows in the database! This type of attack is known as SQL Injection.

Another example attack that also uses SQL Injection can be:

 Username: hr
 Password: ', delete from users

In this case, all of the existing user information in the users table will be deleted!

How can such attacks be avoided? The solution is to check the user inputs before querying the database: this approach is known as "sanitizing database inputs."

The Cuckoo's Egg Bug is a problem introduced by Clifford Stoll, concerning an attack by a malicious node. Consider the nodes A, B and X, as shown in the picture below.

Suppose node B stores the Access Control List for a web application, and allows remote logins from node A. This access control list defines which users have access to the web application. In step 1 (denoted by "1st"), node A sends a request "A1" to B requesting to connect. In step 2, node B then sends a response "B8, A1" back to A. In step 3, node A then acknowledges the response from B by responding with "A2, B8." At this point, B knows that A is on the other end of the channel because A has responded back to B with the information that B has been sending to A. Namely, the "B8" message that B sends to A serves as a "secret" that only A and B know.

In step 4, the malicious node X pretends to be node A, and sends a message "A3" to node B. Since node B believes that node A sent the "A3" message, node B then sends a response "B1008, A3" to node A, thinking that node A initially sent the "A3" message. Upon receipt, node A responds with a "WHAT?!" message, indicating that it is receiving information from B that it never requested.

In this example, we see that node X fails to connect to node B. Yet, a workaround can be found to allow node X to connect to B! How can this be done? X needs to know that node B will respond back to A with a "B1008" message. Thus, X can attempt to predict node B's messages to gain access to the resources that node A has access to on node B. An attempt to predict the response of a server from a client requests is more feasible if the attacker knows the operating system used by the server.

Such an attack can be carried out as depicted in the image below:

In this scenario, malicious node X first attempts to establish a connection with node B, by sending the initial "X3" message. Upon receipt, node B responds with a "B1008, X3" message to node X, acknowledging the initial request. In step 3, node X then sends a message "A4" to node B, pretending to be node A. In response, B sends a message "B2008,A4" to node A in step 4. Simultaneously, node X can then send a high volume stream to node A, attempting to slow it down just enough, so that the message "A5, B2008" reaches node B in step 5. Upon receipt of message "A5,B2008" at node B, node X has successfully attacked node B, and now node X can access the resources that node A could access on node B. In step 6, node X maliciously sends message "A6, B2009" to node B, requesting that node X be added to the Access Control List on node B.

This kind of attack produces an authentication failure, since an illegitimate principal has gained access to the system. A solution to this vulnerability involves the use of random initial sequence numbers on packets to prevent malicious hosts like X from being able to predict what other nodes will send in response to user requests.

Here is an unofficial list of History's worst Software Bugs

A few bugs that are of particular interest to this discussion include the Morris Internet Worm and the Ping of Death

Consider the following scenario as an example that even the most brilliant of programmers are not always perfect. Here is a web application that allows users to login with a username/password and submit a paper to a conference. There is also the familiar feature of requesting that your password be sent to your registered email address in case you happen to forget it.

Now suppose the designer of this application decided to implement an additional feature. For the purposes of testing the appearance of the email that would be sent out upon a password request, what if the email was simply displayed on the screen as opposed to being sent out? In practice, this would result in a severe information leak as any casual user could simply supply an email address that belonged to someone else and would instantly gain access to their password. If the password belonged to the site administrator, for example, the user could easily assume control of the website.

A threat model is the set of attacks the system is designed to prevent or the set of components that must be secure in order to preserve system security. Threats are potential security violations either due to a planned attack by an adversary or unintended mistakes by legitimate users of the system. The designer of a secre computer system must be consider both.

Using the above example, the threat model for the conference system would include:

• The security of the user's email address - Is the principal the only person who has access to the user's email?
• The security of the network between the service and the user's inbox - Is there a way that a third party can intercept or view the password as it's sent to the user's inbox?

There are three broad categories of threats:

• Unauthorized information release : an unauthorized person can read and take advantage of information stored in the computer or being transmitted over networks.
• Unauthorized information modification : an unauthorized person can make changes in stored information or modify messages that cross a network.
• Unauthorized dnial of use : an adversary can prevent an authorized user from reading or modifying information, even though the adversary may not be able to read or modify the information.

Lastly, we can now summarize what is involved with computer security:

1. Authenticity - Is the principal legitimate? Is the agent's claimed identity authentic?
2. Integrity - Did the request come from the authentic principal? Is this request actually the one the agent made?
3. Authorization - Is the principal allowed to perform the request? Has a suitable authority provided permission to the agent to perform this action?
4. Correctness - Does the code correctly perform the request?

The point of encryption is to keep secrets secret.

It relies on the complexity of mathematical functions

• Determining whether a number is prime is easy
• Prime factorization is difficult

Let E be a function, M be a message, K be an encryption key, and K-1 be the decryption key.

• Given E, K, M, it is easy to find E(K,M).
• Given E, E(K,M), it is hard to compute M, K-1.
• Given E, E(K,M), K-1, it is easy to compute M.

Example:
E(K,M) = XMPPR.
This is difficult to decode into M, but when given K:

Then the message can be decoded to be:
M = HELLO

Goal: Establish a secure communication between A & B. It is a modification of an another encryption 1) with a fix to correct the freshness2) flaw.

Assumption: All principals know KA, AB

• only A knows KA-1
• only B knows KB-1

1. A -> B: Certificate_A, Certificate_B,{{KAB, Expiration}KA-1}KB
   • KAB is a shared but temporary key to decipher the message
   • KA-1 is used to authenticate the trust of the user
   • KB is for secrecy/confidentiality from anyone else
2. B -> A: {Hello!}KAB
3. A -> B: {Hi Yourself}KAB