MIT course "Computer Systems Security". Lecture 1: Introduction: Threat Models, Part 1

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: "Introduction: threat models" Part 1 / Part 2 / Part 3

Nikolai Zeldovich: in this class, our lectures will be attended by a co-rapporteur, visiting professor James Mykens from Microsoft Research. Later, he will talk about topics such as Internet security.
')


This year we have 4 assistant teachers, these are Stephen, Webb, Hogan and James. If you need help, you can contact them during business hours throughout the year.

The topic of these lectures is to understand how to create secure systems, why computer systems are sometimes unsafe, and how to fix things if something goes wrong. There is no textbook on this topic, so you should use the notes of these lectures, which are also posted on our website, and you guys should read them in advance. There are also a number of questions that you will need to answer in writing, and you can send your own questions before 10:00 pm before the lecture day. And when you come to the lecture, we will discuss your answers and questions and find out what this system is, what problems it solves, when it works and when it does not work, and whether these methods are good in other cases.

I hope that through this kind of training we will get some understanding of how we actually build systems that are secure.

On the site we have a preliminary schedule of lectures, it is quite flexible. If there are other topics of interest to you, or there are some paper notes, you can send them to us by e-mail, and we will try to accommodate your wishes. So if you want to hear something more than what is foreseen, just let us know.

In the same way, if you ever have a question or notice any mistake, just interrupt and ask us at any time lectures. Safety largely consists of parts, so they should pay attention. I, of course, will make mistakes, so you should take a chance to say so. Just interrupt the report and ask, so we will find out what is going wrong and how to fix it.



As for the organization of lectures, then most of them will be laboratory work. The first is already posted on the site. They will help you understand various computer security problems and how to prevent them from appearing on a simple web server. Therefore, in lab # 1, you simply take the web server that we provide you with, and try to find ways to hack it using a buffer overflow vulnerability. You will gain control over the site by simply sending to it carefully crafted requests and packages.
In other labs, you will look for ways to protect the web server, look for “bugs” in the code, write “worms” that run in the user's browser, and study other interesting types of Internet problems.

Many students are surprised that each laboratory work (LR) uses its own programming language. So, LR No. 1 uses C and Assembler, the second LR uses programming in Python, the third is still some other language, JavaScript appears in the fifth, and so on. This is inevitable, so I apologize in advance that you will have to learn all these languages ​​if you still do not know them.

In a sense, it is even useful, because this is the real world. All systems are complex and consist of various parts. In the end, it will be useful for your moral self-affirmation. However, this will require some training, especially if you have not seen these languages ​​before. So the sooner you start to study them, the better.

In particular, LR # 1 will be based on a set of subtleties of the C language and Assembler code, which we do not teach here in as much detail as in other courses. We will ask teaching assistants to allocate a couple of hours next week to conduct something like a training session on how the program looks from binary codes, how to disassemble them, how to figure out what is on the stack, and so on.

Another innovation is that since this year we have been making videos of our lectures, which can then be viewed online. We will post them as soon as we receive from videographers. In addition, you can ask questions online using the Piazza portal, as you did during the other courses.

Before we begin to study computer security issues, I will tell you one thing. There are certain rules that our institute complies with in accessing the MIT network, therefore, when conducting security research, it must be borne in mind that not everything that you can technically implement is legal. In the course of this course, you will learn how to hack or disrupt the system, but this does not mean that you can do this anywhere. In this lecture there is a link to the rules in which all this is described in detail. In general, if you doubt the legality of a particular step, it is better to ask a lecturer or assistant teacher. In the end, this is not a puzzle. And do not hesitate to ask questions.

So what is safety? Let's start with some basic things and consider some general examples of why it is difficult to ensure security, which means trying to build a secure system. These considerations are not described on paper and are not highly intellectual arguments, but they will still clarify the background of the issue and give you some food for thought about how to think about the security of systems.

In general, security is a way to achieve a goal, the ability to resist the presence of a real enemy. Think of the fact that in this case there are always “bad guys” who want to make sure that you will fail. They want to steal your files. They want to delete the contents of your hard drive. They want to make sure that nothing works for you, your phone cannot get in touch, and so on. So, safe is a system that really can do something no matter what the bad guy is trying to do with you.

The cool thing is that we can potentially create systems that are resistant to the interference of the bad guys, the attackers, the hackers — call them whatever you like. And we are still able to create computer systems that can do their work in such cases.



To facilitate the understanding of security, we divide it into 3 parts. One part is the principles that your system must implement, that is, its purpose. Let's call it Policy. Actually, this is the goal that you must achieve by implementing a security system.

For example, only I have to read you the contents of this course 6.858. Or, maybe, assistant teachers, or co-rapporteurs - that is, this is our mission as a “system”. However, there are basic requirements for what I want from my system, how I want it to fulfill its purpose.

For example, one of the principles that you should write is related to data confidentiality, that is, you need to set access rights so that the lecture materials are available only to those who have the right to read the 6.858 course. Then one could think about honesty, that is, to introduce restrictions, that only teachers of the 6.858 course can change the grade file, or that only they have the right to submit to the department the final grade file.

Then you need to foresee such a thing as accessibility. For example, the site should be accessible even if the bad guys are trying to “put” it and organize some type of DOS-attack, Denial of Service “denial of service”.

So these are the characteristics of the system that should concern us. But since this is security, there is a bad guy involved. And we need to understand and think about what he is going to do. This is what we usually call the threat model, the Threat model is the second part of the security system. Basically, this set of assumptions about what constitutes a bad guy or an opponent.

It is important to have some assumptions about him, because he is omnipresent and can penetrate everywhere at once, and you will be forced to do what he wants, and in this case it is difficult to achieve even a similarity of security.

For example, you assume that the hacker does not know your password, or does not have physical access to your phone, to your keys and to your laptop. Otherwise, it will not be possible to achieve any progress in this game. It turns out that while it is actually difficult to figure out how else you can defend yourself, but I think it is better to overestimate the threat than to underestimate it, because the enemy can always surprise you in terms of putting the threat into practice.

Finally, to ensure security, in order to achieve our goal within the framework of the assumptions made about threats, we must consider some mechanism. Mechanism is the third part of the security system. Basically it is software or hardware or some part of the system design, implementation, etc., which will try to make sure that our system fulfills its purpose as long as the hacker's behavior matches the threat model. Thus, the end result is that while our threat model remains true, our system succeeds in fulfilling its mission. It's clear?



But why is it so hard to put into practice if our plan looks so simple? You have implemented all 3 principles, the system has earned and you have nothing more to do. However, in practice, you could be sure that computer systems always crack in one way or another. And hacks are pretty commonplace. The main reason why security is becoming a problem is the choice of the wrong goal (this was already mentioned in the 6.033 course), which means that we need to make sure that our security policy is in place regardless of what the attacker does.

Let's go from the reverse. If you want to build a file system and make sure my assistants can access the rating file, this is pretty easy. I just ask him: “Hey, guys, go and see if you can get access to the estimates?”, And if they succeed, then fine, the work is done, the system works.

But if it is necessary for me that no one but my assistants have access to the rating file, the implementation of this principle will present a more serious problem. Because now I have to find out what all those people who are not my assistants can do in order to get the rating file. They may simply try to open it and read it, and it is possible that my security system should prohibit it.

But they can try other types of attacks, for example, picking my assistant's password, or stealing his laptop, or breaking into his room, who knows?

All these hacking methods must be taken into account by our threat model. For example, I don’t worry about the rating file in case your laptop is stolen from a hostel. Although it might have been necessary to attend to this, it is difficult to say. As a result, these security games are not so clearly represented as to initially make the right assumptions about possible threats. Sometimes it happens that only after their implementation you think that it would be good to provide such a method of hacking in advance.

Therefore, as a result, it is a very iterative process. And only after you implement each iteration, you will be able to see where the weakest link in your system is. Maybe I didn’t make the threat model right. Maybe my mechanism contained some errors, since this software is for use in large systems, and they usually contain many “bugs”.

And you start to correct mistakes, change the threat model, redo the whole security system, and fortunately, make it better.

One of the dangerous understandings of the topic of these studies is that you simply leave with the thought that everything is hacked, nothing works, we just have to fold our hands and stop using computers. This is one possible interpretation of the problem, but it is not entirely correct. The theme of these lectures is that we consider all these different systems in order to advance in their understanding.

We have to consider what happens if you do this? Will it break? And what happens if you try to do this? What will it lead to? It is inevitable that each system will have its own point of hacking, and we will sort out our problems when we discover it. We will understand that we can hack this system if we go this way, or that the system stops working under such a set of conditions.

Each system will inevitably have its own vulnerable place, but this does not mean at all that all computer systems are worthless and defenseless. This simply means that you need to know where and what system design to use. And exercises on finding vulnerable points will help you to know in which cases these methods work and in which they do not.

In reality, it has fuzzy boundaries, but the more secure you make your system, the less likely you are to get into the story on the front page of the New York Times, telling about how the social security numbers of millions of people got into open access. And while you pay less money to protect against this situation. One of the outstanding features of security is that it is capable of doing things that you could not foresee, because security mechanisms that provide the ability to protect against certain types of threats are extremely powerful.

For example, the browser used to be a rather boring thing in the sense of what can be done with it. You could only browse web pages or run some javascript. But now these are pretty cool mechanisms that we studied a few weeks ago and which allow you to run arbitrary x86 code and make sure that it cannot do anything “fun” with your computer. There is an interesting technology Native Client from Google, this is a “sandbox” that allows you to safely run machine code directly in the browser, regardless of the operating system.



Before you start a game on your machine, you must download it and install it, and for this you need to note in the dialog box that you allow it to perform a series of actions. But now you can just run it in the browser, without any additional clicks, and it will go. The reason why it is so simple and powerful is that the security system runs the program in an isolated sandbox, without prompting the user to decide anything about the security or harmfulness of this game or any other program running on the computer. In most cases, a good security mechanism allows you to design such cool new systems that could not have been created before.

Therefore, in the rest of our lecture, I want to give you a number of examples when the security system is not working properly. These examples will teach you how not to act, so that you have a better idea of ​​how you need to approach the solution of security problems. In this case, hacking the security system shows that almost every one of its 3 parts was made incorrectly. In practice, people make mistakes both in the functions of the system, in creating a threat model, and in the mechanism for implementing protective functions.

Let's start with examples of how to spoil the system policy, that is, the purpose of the system. Perhaps the clearest and most understandable example is a request to restore access to an account. As you know, when you log into your account on the site, you enter a password. But what happens if you lose it? Some sites will send you a password by email if you have lost your password, with a link to the password change page. So it's simple enough if you specify a backup mailbox. That was the security system offered by your email provider.



Just a few years ago, Yahoo created its e-mail on the Internet using a different password recovery mechanism. If you forgot your password from the Yahoo box, they could not send it to you anywhere, because the option of using a spare mailbox was not provided. Instead, to recover your password, you had to answer a couple of questions that only you could know the answers to. And if you forgot your password from your account, you could click on the link, answer the questions and get your password again.

What happened in this case? , , , . , , , . , .

, Yahoo. , : « ? ? ?» . . Yahoo, , . , .

, , , . , , . wired.com. , - Gmail . , ? , , .

, Gmail, , . , Gmail, . , - , , . , . - , : «, , foo@me.com, Apple».



, @me.com. , Gmail. , Apple @me.com, . , . , , , ? .

, Amazon.com, . Amazon , . . Amazon , , - .

Amazon.com , . , . , «» . , ? , , , . , .
Amazon , , . , Amazon, . ?
, , : «, , , !». – Amazon.com.

, Apple? Amazon . - , . 4 , , . , 4 , – . @me.com, Gmail.

. , . , , . . 3- , , .

, , , . , - , . . , .



, , , .

. , , , , . . , .

, , , , , .

, . «» 80- , «». . , «» . , . 56 DES (Data Encryption Standard). 80- .

, MIT . . , 6.858 , «» . 256. - ( ) «» . , 80-, . , .



, , , «», . – «» , . «», . - , , , «».

25:30

: MIT « ». 1: «: », 2


.

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?