Race Attack

As with the other labs, this lab is about both attacks and protection. The focus is on exploiting races conditions and on protection against them.

The lab consists of two parts.

Part One

In part one, the scenario is a race attack on a simple password database. The attack is mounted by two principals Malin and Kalle (running as separate threads) that collaborate to exploit a race condition in order to overwrite the password of an honest principal Bob (which is yet another thread). You need to implement the vulnerable database operations, an attack, and fix the database operations.

Concretely, you need to write a Java program that includes classes Password, Principal, and PasswordApp. These classes can be described as follows:

• class Password handles a password database. It should implement interface IPassword, which contains the following methods:
  • check() - this method accepts a user name and a password and returns a boolean that indicates whether the provided password matches the one from the database.
  • updatePwd() - this method accepts a user name, old password, and new password. It should check whether the old password matches the one in the database, and if so, then update the password with the new password. The method returns a boolean that indicates whether the update has succeeded.
  • deleteUser() - this method accepts a user name and a password. It checks whether the password is correct, and if so, erases the user/password pair from the database. The method returns a boolean that indicates whether the deletion has succeeded.
  • maxReqTime() - returns the maximum time (in milliseconds) taken by check(), updatePwd(), or deleteUser() requests so far. Clearly, the latter methods need to keep track of time they take to serve requests from principals.
• class Principal describes the behavior of a principal, whether it is Malin, Kalle, or Bob.
• class PasswordApp, which contains method main(). This class should start all necessary threads.

Demands

• The Password class should not have other vulnerabilities than race conditions. It should not contain unjustified code.
• Furthermore, Password should not have basic race conditions (such conditions are due to unprotected fields). In order to verify this, you need to make sure that the CheckSync tool (which implements Eraser for Java) gives no warnings on your program.
• You may insert some delays in the code for Password to help you expose interleavings for which the attack works.
• It should be obvious from the output generated by your program that the attack succeeds. Printing the log of an action by a principal should be, of course, done by the respective principal thread. Expected output (when running on a student machine such as remote4.student.chalmers.se) should be as follows:

  > java PasswordApp
  ...
  Kalle logged in as Bob
  Maximum request time: 3007
  

  Where

  Kalle logged in as Bob

  is printed by thread for Kalle on a successful login with username Bob. The last output

  Maximum request time: 3007

  is printed at the end for statistics by some thread other than Malin, Kalle, or Bob.
• Make sure that PasswordApp is a public class. The output sync.log from CheckSync should contain no warnings:

  > setup_course tda600
  > java -cp /chalmers/groups/tda600/CheckSync/checkSync.jar:. edu.umd.cs.pugh.CheckSync PasswordApp
  ...
  Kalle logged in as Bob
  Maximum request time: 3007
  > cat sync.log 
  >
  

• Provide a fixed version PasswordFixed, which is free of races.
• Include a report file that
  • contains documentation for the program,
  • argues that Password does not have other vulnerabilities than race conditions,
  • states your assumptions about Bob,
  • explains the attack, and
  • explains the protection technique.

Part Two

In part two, the scenario is a console password prompt in Java. As passwords are typed in the console they need to be hidden (by, for example, "*" characters). You need to evaluate multi-thread solutions offered by the Sun Developer Network.

Demands

• Test and evaluate the Simple Solution part. In the report, discuss the following:
  • Does the solution work?
  • If not, enumerate vulnerabilities.
  • If there are any vulnerabilities, what is the root of the problem?
  • If there are no vulnerabilities, argue that it is the case.
• Test and evaluate the Making the Code Secure and Reliable part. In the report, discuss the following:
  • Does the solution work?
  • If not, enumerate vulnerabilities.
  • If there are any vulnerabilities, what is the root of the problem?
  • If there are no vulnerabilities, argue that it is the case.
• What conclusions can you draw from such a use of multithreading?
• What is the proper way to implement password prompt in Java?

Downloads

• The file IPassword.java contains the interface for the password database.
• The file Password.java contains an initial code template, where the simple database representation (two arrays of strings) is defined.

Notes

Please stick to the simple database structure provided in Password.java. No complex database representations are needed to illustrate race attacks and protection.

Reporting

Submitting instructions

Links

• Lecture slides from the lecture on races.
• Savage, Burrows, Nelson, Sobalvarro, and Anderson, Eraser: A Dynamic Data Race Detector for Multithreaded Programs, 1997.
• CheckSync