Courses/Computer Science/CPSC 525.W2013/Lecture Notes

Jump to: navigation, search


January 9: Introduction

Today we briefly covered the course outline, structure, topics, and policies. We also talked about the efficacy of some "basic hygiene" security advice.


Notes/Links from Class Discussion


January 11: The Security Mindset

In this session, we will more closely consider how to develop a security mindset, with special reference to the readings for last session and this. We will also briefly consider how to read an academic paper because many of the readings in this course rely on original research papers.


Notes/Links From Class Discussion


January 14: Ethics and the Security Mindset (Cont)

In this session, we will discuss some ethical frameworks, point out some important related legislation, and discuss some example areas, like ethics review for research and issues surrounding "responsible" disclosure.


Notes/Links From Class Discussion

Vulnerability Disclosure

  2. CERT's stance:


January 16: Foundations of Protection

In this session, we will consider some of the foundational concepts of computer security, including protection, access control, and the limits of such mechanisms. We will also take a look at some very common expressions of these concepts.




  • The Craft of System Security: 1.1 The Standard Rubric
  • The Craft of System Security: 1.2 The Matrix
  • The Craft of System Security: 1.3 Other Views
  • The Craft of System Security: 1.4 Safe States and the Access Control Matrix
  • The Craft of System Security: 1.5 Other Hard Problems
  • The Craft of System Security: 1.6 Takehome Message
  • Protection. Proc. 5th Princeton Conf. on Information Sciences and Systems, Princeton, 1971. Reprinted in ACM Operating Systems Rev. 8, 1 (Jan. 1974), pp 18-24 PDF
  • "Protection in Operating Systems" by Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman (ACM Digital Library, available via U of C with appropriate network address)

January 18: Access Control

In this session, we will consider some basic access control concepts and terminology.




The readings for today reinforce some of the foundations of protection by illustrating how they were mapped to the design of an early multi-user system, Multics, that took protection and security quite seriously. You can see remnants or echos of these ideas in other commodity computing systems (e.g., x86 segments and privilege rings).

January 21: Security Models: Overview

In this session, we will conduct an overview of the background knowledge needed for discussing specific security models (details of which will occur on the 28th and 30th). Topics include information flow, categories, and partial orders.




  • TCSS 2.1, 2.2, 2.3, 2.4, 2.5

January 23: Basic Crypto: Overview of Symmetric Key Block Ciphers

In this session, we will take a break from basic computer protection ideas to consider the role that basic cryptography has in protecting a system. We will examine a common form of encryption: symmetric key block ciphers.


  • TBD


  • TCSS: 7.1: Framework and Terminology
  • TCSS: 7.3: Symmetric Cryptography
  • TCSS: 7.4: Applications of Symmetric Cryptography (optional)

January 25: Basic Crypto: Attacks Against Block Ciphers

As part of our theme of learning through failure modes, we will consider how to attack block ciphers...ask yourself what security guarantees cryptography provides.


  • TBD


  • TCSS: 8.1: Breaking Symmetric Key without Brute Force
  • TCSS: 8.2: Breaking Symmetric Key with Brute Force
  • TCSS: 8.4: Breaking Cryptography via the Real World

January 28: Security Models: Bell-LaPadula, Biba, Chinese Wall

In this session, we will pick up with a more detailed examination of three security models.



January 30: Security Models: Clark-Wilson

In this session, we will examine the Clark-Wilson integrity model (this is probably about the only Wikipedia link I will give you...ask yourself why)




Feb 1: Role-Based Access Control

In this session, we will consider RBAC and related ideas.




  • None, work on HW1

February 4: Langsec Roots: A Theory on one Source of Insecurity

In this session, we will touch on several ideas related to langsec, particularly the principle that: a thing is not what it is named, but rather a thing is what can be done to it. This principle connects with langsec because we often try to create systems that recognize a thing either by its label or by what it does or by what happens to it. We use the Gostak game to motivate this discussion.

We really start our discussion of langsec by asking the questions "Why do things break?" and "Why do things continue to break?"

We considered a few reasons why things seem to break beyond convenient excuses like lazy programmers and "dangerous" languages, including complexity and composition as hidden by abstraction.



  • The Gostak


  • Composition Patterns of Hacking. Sergey Bratus, Julian Bangert, Alexandar Gabrovsky, Anna Shubina, Daniel Bilar, and Michael E. Locasto. Proceedings of the 1st International Workshop on Cyber Patterns. pp. 80-85. 9-10 July 2012, Abingdon, Oxfordshire, UK

February 6: Langsec Roots: A Talk on Certificate Manipulation




February 8: Langsec Roots: Weird Machines


  • No slides -- retro paper surfing on the document display overhead!



  • USENIX ;login: articles in the December "Security" issue:
  • Exploit Programming: From Buffer Overflows to "Weird Machines" and Theory of Computation. Sergey Bratus, Michael E. Locasto, Meredith L. Patterson, Len Sassaman, and Anna Shubina. USENIX ;login: vol. 36, no. 6, pp. 13--21 December 2011. Paper

February 11: Langsec Foundations: Exploits as Weird Machines

In this session, we will take a look at several types of code injection attacks as a way to help build our intuition about weird machines.


  • None - we will be looking at code and papers.


  • HW2 is released


  • Jedidiah R. Crandall, Zhendong Su, S. Felix Wu, and Frederic T. Chong. On Deriving Unknown Vulnerabilities from Zero-Day Polymorphic and Metamorphic Worm Exploits. In the proceedings of the 12th ACM Conference on Computer and Communications Security (CCS 2005). Alexandria, Virginia. November 2005. pdf
  • Daniela Oliveira and Jedidiah R. Crandall. Holographic Vulnerability Studies: Vulnerabilities as Fractures in Interpretation as Information Flows Across Abstraction Boundaries. In the Proceedings of the New Security Paradigms Workshop (NSPW 2012). Bertinoro, Italy. pdf

February 13: Langsec Foundations: Weird Machines (cont)

In this session, we will continue our gdb-based exploration of types of code injection attacks.

We use these examples to drive our understanding of what elements of the computing environment we need to know in order to find vulnerabilities and construct exploits for them. It isn't simply a matter of guessing where the right bytes should be, or shoveling a piece of execve-invoking x86 shellcode at any open port.

You need to understand the particular input format you're dealing with, how it is consumed (i.e., parsed!) by the application's logic, the state of the process address space, location of various important pieces of state (e.g., function pointers, return addresses, saved registers), how your input gets mapped into that space, how you can supply other input that gives the space structure and predictability (e.g., heap-spraying), how to avoid certain countermeasures, etc.

This whole concept hearkens back to the Cyberpatterns paper about the exploit engineering workflow.

Finding success in building a weird machine means that you need to understand the langsec properties of the program you are targeting.



February 15: Langsec Foundations: Weird Machines and Heap Attacks

We continue our discussion of weird machines with respect to attacking parts of the process address space other than the stack.


February 18, 20, 22: No class

This is reading week. Please digest the following:


  • Thomas Dullien and Halvar Flake "Exploitation and State Machines" PDF
  • F. B. Schneider. Enforceable Security Policies. ACM Transactions on Information and System Security, 2(4), Mar. 2000.
  • A Language-Based Approach to Security. Fred B. Schneider, Greg Morrisett, and Robert Harper2

February 25: Langsec Applications: Intrusion Detection

In this session, we will consider the common security subfield of intrusion detection, and how langsec (as an explanation of insecurity) fouls many of the good intentions we have when we attempt to detect malicious content in network traffic or machine actions. If defense is predicated on detection, and detection is predicated on recognition -- we are in quite a pickle if we're trying to detect arbitrary computational constructs.

Langsec Principle: Alice and Bob are talking, but whomever is listening is highly confused.


  • We looked at a paper (Handley et al.) and a couple of small demonstrations of this principle in action, like:
  • looking at Snort rules
  • disassembling network packets captured via tcpdump with udcli


  • Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection by Thomas H Ptacek and Timothy M. Newsham
  • Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics. Mark Handley and Vern Paxson and Christian Kreibich USENIX paperhtml

Related Work

February 27: Midterm Exam

27 February is the midterm exam.

March 1: Langsec Applications: Intrusion Detection (cont)

Today we will talk about polymorphic shellcode and the challenges it presents to detection.


  • reading week readings
  • a note on system call profiles (strace-based profiling); a note on process relationships; provos work on systrace
  • blog post on utility of AV (link above)
  • x86 polymorphic shellcode disassembly example


  • On the Infeasibility of Modeling Polymorphic Shellcode. Yingbo Song, Michael E. Locasto, Angelos Stavrou, Angelos D. Keromytis, and Salvatore J. Stolfo. In the Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS 2007). pp. 541--551. October 2007, Alexandria, VA.
  • paper on "English Shellcode Mason, Small, Monrose, MacManus. CCS 2009.

March 4: Langsec Applications: Confusing the PHY Layer

This session is a case study of Goodspeed's recent work in "Remotely Exploiting the PHY Layer".



March 6: Langsec's Relationship with Interpreting and Enforcing Security Policy

This session will feature a guest lecture by Robin Gonzalez.

March 8: Langsec Meets MLS in Weird Machines

We'll talk about Deep Introspection, and some approaches to enforcing code-data ownership for real systems.

March 11: HW2 and Related Topics

Today we will discuss various topics related to HW 2, gdb, and shellcode. Consider this an "in-class" tutorial session. Feel free to bring your laptops/notebooks/devices.



Please read this material; it sets up our discussion of security architecture and concepts like privilege separation.

March 13: Security Architecture

In this session, we will consider some security design principles. We will highlight some countermeasures against various forms of popular code-injection attack. It will help motivate our discussion of security architecture and the application of the Saltzer-Schroeder principles. We will begin by considering a case study of the security mechanisms present in the Linux kernel. We will continue by engaging in a design exercise -- this will likely span into the next session.


Case Study: the set of "security" mechanisms present in the Linux OS.


  • Some Thoughts on Security After Ten Years of qmail 1.0, DJB, CSAW 2007 PDF

March 15: Security Architecture (cont)

Design Exercise: A Mobile Transit Safety App

March 18: Isolation: Wherefore art thou reference monitor?

In the last few sessions, we touched again on the concept of a reference monitor or security kernel. This highly privileged component is responsible for parsing, interpreting, and enforcing security policy. Many different real-world software systems attempt to provide this role, and one of their major security or protection guarantees is isolation.

In this session, we will consider the utility of using virtualization to provide isolation or execution containers.

Notes From Class

  • TBD


  • Steven M. Bellovin. Virtual machines, virtual security. Communications of the ACM, 49(10), October 2006. “Inside RISKS” column. html
  • VM-based Security Overkill: A Lament for Applied Systems Security Research. Sergey Bratus, Michael E. Locasto, Ashwin Ramaswamy, and Sean W. Smith. Proceedings of the 19th New Security Paradigms Workshop (NSPW 2010). September 2010. Concord, MA, USA. PDF

March 20: Security Evaluation (Overview)

Up until this point in the semester, we've discussed two major concepts:

  1. why things break (langsec)
  2. what traditional approaches to protection and security are and what they provide

In this session, we will begin to think about how to evaluate what level of security you achieve and how you can measure or assess this in a principled fashion.




March 22: Security Evaluation Exercise

In this session, we will begin a security evaluation exercise. This exercise will last for about three sessions.

In this first class, we will cover the ground rules and structure of the assignment.


Welcome to IronRust Security Auditing Solutions, Inc. We have been asked to evaluate the security and assurance properties of a recent Internet-based mock vote. The "Green" Jellybean Party is asking for a recount and this assessment because they did not win (receiving only 111 votes out of 497 cast, good for third place behind Black (123) and Red (202), and ahead of Yellow (61)). According to pre-vote polls and exit polls, Green expected about 70 more votes, and is curious why their support seems to have broken for Black and Red. The Green candidate is an important client, and she wants answers.


This scenario is based on Edmonton's recently trial run of a mock election over the Internet to assess the feasibility of running a municipal election online. In preliminary assessment by the "Citizen Jury" process, their conclusion was:

"The verdict of the Citizen Jury was "Yes - Edmonton should adopt Internet voting as an option for future municipal elections". The verdict was delivered to the City Clerk and will be contained in the report going to City Council on January 23, 2013."

The city, however, has updated their page with the following notice:

"At the February 6, 2013 Edmonton City Council meeting, the decision was made not to proceed with the implementation of an Internet voting option in the 2013 General Election. Although not ready to move forward at this time, Council acknowledged the efforts made by City Administration to assess Internet voting as a potential option for voters."

Warmup Exercise 1

Please post to twitter using the hashtag #cpsc525vote whether you think Internet voting is a good or bad idea, and why.

Warmup Exercise 2

We will discuss this article:

Warmup Exercise 3

And we will vote in the Piazza poll for our favorite jellybean color (do this over the next two days). See if you can 'make' your candidate win (only limitations: don't do anything illegal, and don't violate Piazza terms of service).


  • IronRust Security Audit Solutions, Inc. will take the contract from the Green Jellybean Party, and to the best of our ability, perform a security postmortem on the election results and processes involved in creating and holding the election. We seek to answer the question: Does the JellyBean Mock Election demonstrate the feasibility of Internet voting in an Alberta Municipal election?
  • Therefore, your main task is an evaluation of the quality of the procedure (based on available documents) used in running the mock election, not a rant for or against Internet voting in general.
  • We are not addressing the question of a recount or what candidate should have won.
  • The 625 students are our board of directors.
  • Prof. Locasto is CEO.
  • We need to choose two Scribes who are responsible for taking notes on our discussions and deliberations.
  • We need to choose 4 team leaders (and their teams) to address the four main areas of our security evaluation.
  • No cross-team communication except through class reports and discussion, for example, to bring in an outside resource that team A noticed and thought would be useful for Team B.
  • You should find out what system was used, but do not attempt to obtain one.
  • Feel free to consult outside experts.
  • This is not a competition between groups. Do not actively interfere with the work of another group.
  • Members should not switch teams.


Since we do not have access to the actual software system used in this trial, we have to perform our security analysis without it. Based on the description of the program, we will form teams to try to answer these questions:

Team 1:

  • The main page says "Privacy, security, and confidentiality of the voting public is of primary importance to the City of Edmonton." What do you think these terms mean in this context? Why is this not an empty phrase?
  • What is the value of the final results file and the information contained therein? What do the other "vote results" for other questions show/demonstrate?
  • What is the credibility of the research team? The background? Possible biases?
  • What are the names and affiliations of other Internet voting experts?
  • What can we find out about the software used? How? (e.g., FOIA, purchase, etc.)

Team 2:

  • What software was used? What is the company's background? Were they involved in any way (beyond providing the software) with this mock election?
  • What are the security issues with the "approved" browsers?
  • In what ways is an IP address tightly bound to a person? In what ways is it not?
  • In what ways is an email address tightly bound to a person? In what ways is it not?

Team 3:

  • Can any of these mechanisms (e.g., registration) be subverted? How?
  • What is the value of the accepted list of credentials for the purposes of registration?
  • What is the security evaluation value of the "citizen jury" of 18 citizens?
  • Will the "real" election exactly duplicate the experiment? in scale, type, processes, etc.?

Team 4:

  • Is "security" the goal here? Or is it citizen "comfort"? (As this page says, the main question is Is Edmonton Ready for Internet Voting?)
  • Is Internet voting any more or less dangerous or subject to manipulation than physical voting has been in the past?

Assessment of FAQs:

Your job is to assess the information contained in the FAQ answers.

  • Team 1: Questions 1-8
  • Team 2: Questions 9-18
  • Team 3: Questions 19-25
  • Team 4: Questions 26-34


  • Scribe notes go here.


March 25: Security Evaluation Exercise (cont)


A review of tweets.

Result of Piazza "election."

Preliminary reports and findings.

Small Group Discussions

The first half of the class will be small group discussions so that each team can "get on the same page". The latter half of the class period will be spent on discussing the preliminary opinions and findings.

March 27: Security Evaluation Exercise (cont)

Today we will continue and finish our discussion on an informal "audit" of an evoting experiment.

We have some material available in Piazza. After some initial discussion / presentation by the Prof, your individual teams will meet in small groups to assess this information.


March 29: No Class

Today is Good Friday and a University Holiday.

April 1: Verifiable Quantum Systems

As noted.

April 3: Overview of Automated Formal Methods

This topic is a bridge between the fundamental security models concepts introduced at the beginning of class and the topics associated with Security Evaluation and Assurance.



April 5: Hands-on GDB

In this class session, we will take another look at GDB (as requested via the Piazza poll). This session replaces the planned tutorial sessions. Bring your computer/notebook/laptop.

You will want to have your virtual machine that you set up before in the semester, or access to a LiveCD distribution, or some other Linux environment (even logging into one of the CPSC Linux machines to your home directory should suffice).


  • Nope: USRI survey starting at noon.

Supplemental Readings

I recommend the book "Hacking: The Art of Exploitation"

April 8: Hands On GDB

Program analysis, debugging, intrusion detection, security evaluation, vulnerability identification, and security policy enforcement are all sides of the same...coin.

Today we looked at the concept of watchpoints, and we attempted to debug the "broken.c" program at the link above. You do not have direct access to the source code. Using just the binary b32 or b64 (whichever is appropriate to your platform).

April 10: Hands On GDB and Pin

GDB is very useful, but sometimes changing the behavior of a monitored process is a bit easier with different tools like Pin or Valgrind.

In this session, we'll finish our consideration of the small bug in the program from Monday.

We will then take a look at Pin in a short presentation.


April 12: Bug Project Showcase

  • Syed Zain Rizvi
  • Dummy Dave N
  • Stephen Ma
  • Adrian Cristea


April 15: On "Hackers"

In this section, we'll consider whether our security mindset has helped us appreciate the complexity and variety hiding behind the word "hacker".

The topic of computer security includes a vast array of concepts, a rich history, and unique methods of learning and thinking. The hacking community, from companies with security professionals to black, grey, white, and straw-hat hackers holds such a variety of people with different background and experiences. It's really an amazing community, full of some of the most diverse and sharpest people you'll ever meet.

Yet, this community is often misunderstood and regularly misrepresented. Part of that comes from the inherent difficulty of boiling down or summarizing so many diverse individuals into a single "community". But another part of this misperception is deliberate and willful ignorance to actually know the people here -- outsiders tend to prefer thinking about hackers in the most pejorative sense possible, where a media tagline has given the work "hacker" a negative connotation.


Hacking Is OK and Attack Papers Are Good

Should Knowledge Be Locked Away?


People have been arguing about what the word "hacker" means for decades.

Surprise! The Internet was full of crap even before the web existed.

Is Hacking Easy?

Sort of. The initial learning curve may be steep, but we know that complex systems breed bugs.

How Should a Hacker Act?

You need to take precautions, but this hasn't been well-studied...yet.

Teaching Hackers

There are some places, schools, universities, programs, and shops that encourage the creation of new straw-hat hackers. This list of links is nowhere near exhaustive.

Misc Topics

(to be placed above)