MIT course "Computer Systems Security". Lecture 20: “Mobile Phone Security”, part 2

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
Lecture 2: “Control of hacker attacks” Part 1 / Part 2 / Part 3
Lecture 3: “Buffer overflow: exploits and protection” Part 1 /Part 2 / Part 3
Lecture 4: “Privilege Separation” Part 1 / Part 2 / Part 3
Lecture 5: “Where Security System Errors Come From” Part 1 / Part 2
Lecture 6: “Capabilities” Part 1 / Part 2 / Part 3
Lecture 7: “Native Client Sandbox” Part 1 / Part 2 / Part 3
Lecture 8: “Network Security Model” Part 1 / Part 2 / Part 3
Lecture 9: “Web Application Security” Part 1 / Part 2/ Part 3
Lecture 10: “Symbolic execution” Part 1 / Part 2 / Part 3
Lecture 11: “Ur / Web programming language” Part 1 / Part 2 / Part 3
Lecture 12: “Network security” Part 1 / Part 2 / Part 3
Lecture 13: “Network Protocols” Part 1 / Part 2 / Part 3
Lecture 14: “SSL and HTTPS” Part 1 / Part 2 / Part 3
Lecture 15: “Medical Software” Part 1 / Part 2/ Part 3
Lecture 16: “Attacks through a side channel” Part 1 / Part 2 / Part 3
Lecture 17: “User authentication” Part 1 / Part 2 / Part 3
Lecture 18: “Private Internet viewing” Part 1 / Part 2 / Part 3
Lecture 19: “Anonymous Networks” Part 1 / Part 2 / Part 3
Lecture 20: “Mobile Phone Security” Part 1 / Part 2 / Part 3

Before starting a detailed review of the system, let's try to figure out one interesting thing. Why did these guys develop a completely new modular design for Android applications? There are desktop applications, web applications, why did they need to invent a completely new way of writing software? Indeed, in a sense, this is confusing to the developer. Because, let's say, I am used to writing my small C program with the main function, and so I look at it and say: “what the hell? What will I do with all this? I have to define four kinds of components and send intentions, instead of using C-structures and writing code in regular lines ”?



So, what are the pros and cons of existing application models? We have desktop and Internet applications, why do we need a third type of application?
Student: but the model has completely changed, right? I think that you should not trust desktop application developers as much as mobile application developers. In addition, you have more experienced users compared to the number of experienced users of computer applications, and they want to use a whole bunch of applications isolated from each other.

Professor: quite possible. So, do you think that in the case of desktop applications, we should not trust their developers too much?

Student:Of course, because there is always a more experienced son or cousin who will help you solve problems with computer programs, but things are different with the phone.

Professor: it is, of course, cool that phones do not need a cousin to take care of them. But from a security point of view, computer programs have one characteristic feature - installing a new application on a computer can be quite a time consuming process. Maybe this is not entirely true, because you can always click on the executable file and start the installation, but I do not think that people regularly install desktop applications. After all, as a rule, you have a fixed set of software that you run.

In this sense, a distinctive feature of web applications is their easy launch. You just go to the site, and you do not need to do anything, except to click on the link, and here you are on some new site running some new application. So this is a pretty good feature of a web application.



A bad feature of computer applications is the lack of isolation of the application. Perhaps this is in a certain way due to the fact that when you install such an application, you completely trust him with everything that is on your computer. In fact, there is no isolation between the application you install on your laptop and any other program or data that already exists there, while in the case of a web application there is some reasonable isolation. As long as you trust the Same Origin policy, you are safe. Therefore, it is safe enough to go to any arbitrary website and start using its application. If this application does not take advantage of your browser's vulnerabilities, then it will not interfere with the operation of sites opened in other browser tabs.



It seems that web applications are still in a better position, as they are easy to use and isolated. Why don't these guys use web apps for Android?

Student: Web applications contain an operating system inside themselves, that is, for example, there is a Firefox OS, which is essentially a mobile Internet OS.

Professor: for sure. You claim that these guys are really wrong. They did not have to create a new Android OS, but simply make a giant web browser for your phone.

Student: at least Mozilla has shown that this is possible.

Professor:well, that's pretty fair. At the very least, it’s wiser to take the road of creating web applications than desktop systems, at least for a phone.

Student: since you are making a phone call from a web application, you need to create a completely new API to connect the web application interface with the phone.

Professor: for sure. Thus, web applications have one limitation that can be fixed, the lack of interface API for some mobile devices. But such applications are becoming less. For example, for a camera or for a GPS navigator, they slowly, but still add the corresponding interface to the web applications. But there, in web applications, probably, there is no API for making calls, sending SMS messages and the like.

Another disadvantage of web applications is the inability to establish limited access to other applications. We talked about implicit intentions in Android, where you could just say: “I want to watch this JPEG image, but who knows which application will open it? Or I want to view this PDF file, or share this photo I just made with my camera via a friend, but I don’t know which email application will be used. ” So let's just ask the link monitor to find me some email program that is going to send this photo. On an Android-based device, this is easy to do, but in the case of web applications, it will be very difficult, as with each interaction you must refer to a specific URL.



So if you don’t know which PDF viewer someone is using, then you won’t know which URL you can use to view your file.

Student: probably, the disadvantage of web applications can be considered that JavaScript is very difficult to read?

Professor: yes, it is, another disadvantage is that they are all written in JavaScript. So potentially it may not be very good in terms of performance, it may be difficult to understand what the program does, it may be difficult to compile efficiently, and so on.

Let's return to the programs for the computer. A useful feature of desktop applications is the ability to share files. All your files are available in each application, because you just share them. Thus, you have easy access to any data available on your computer.



The fact that it is a bit difficult to implement in Android is easy to do in computer applications. In the case of desktop operating systems, if I want to compile a piece of software, I will run MAKE, run GCC and possibly some other programs, and they will all work on the same source C code in the same directory. This is much more difficult to do in Android, where the data is associated with the main application that is stored by the content provider. So you have to tinker, first using the source code repository, and then installing the C compiler, the MAKE program, the assembler, and so on. It’s much harder to make them work together.

This can be done by circumventing some of the limitations of Android, but in any case more difficult than on desktop systems.

Student:I think that it is quite difficult to optimize web applications, they are limited by the use of RAM and the processing power.

Professor:Yes, the principles of optimizing web applications and desktop applications are different. I believe that the disadvantage of web applications, at least when Android was designed, was that it was very difficult to start a web application offline. If your phone catches a weak network signal, then some applications will be difficult to launch, especially if some parts of them “dropped out” of the cache. However, I think, as you have noticed, web applications, albeit slowly, are “catching up” with Android by eliminating the existing limitations. So it is quite possible that web applications will serve as a reasonable model for launching a new operating platform of the phone. But five years ago they were not good enough for this.

But even despite the existing shortcomings, it will now be much easier to “push” web applications into the niche occupied by Android, rather than starting the development of a new mobile OS from scratch. So I think we can still talk about the success of what Android has done, although perhaps today you would prefer not to do it that way.
I think that in terms of isolation, the security of the Android system is much higher. As I mentioned, Android relies on the Linux kernel to isolate applications from each other. The Android platform actually sets up user IDs for user IDs, so this App1 application will have a UID of 1001, App 2 will have a UID of 1002, and the reference monitor, which usually has root rights, has a UID of 0. So the Linux kernel is largely responsible for isolation of applications from each other.



Basically, the interaction between user IDs occurs through intent intentions. There are many more nuances about how the Linux kernel manages applications using the UID, we'll talk about this a little later.

One interesting question: why did these guys choose Java? What is the role of Java in Android? Why is it even needed? If instead of Java we write all applications in C, or, for example, in Assembler, can something break?

Student: if you have vulnerabilities, the use of these languages ​​can lead to a distortion of important indicators for the system.

Professor: Yes, this can happen, for example, in an application, a buffer overflow may occur. What else?

Student: permissions confusion may occur.

Professor: with what permissions?

Student: with such as latency, latency.

Professor:let's look at this in more detail. So, as we said, the link monitor checks for us tags and actually stores in the “Android” system a list of all installed applications, along with tags that correspond to all these applications. So, you probably don’t want the link monitor to make mistakes no matter what language it is written in. So having a link monitor written in a type-safe language is a good solution. I like Java because it is a type-safe language with good features. But even if the application were written in C and there was a buffer overflow in it, it still would not be able to damage the tags that are in the link monitor. So it would not be a big problem.

Student:perhaps there is some system that can damage the code itself written in C?

Professor: yes, therefore, in principle, it would be nice to avoid applications that speak directly to the Linux kernel. In Android, it is not. Android applications can make arbitrary system calls if they wish. In fact, for performance reasons, applications cannot affect arbitrary components written in C or Assembler, so some games “talk” to Java.

Student: I think in some ways this is an opportunity to use all the material written for Java, that is, the creators of "Android" wanted to simplify the creation of applications for developers. And one of the easiest ways to do this is to create the ability to take advantage of the large Java libraries.

Professor: quite possible. I think one of the main reasons for using Java is usability. They were probably more concerned with programming and ease of development, since Java has little to do with security.

Another thing that has a place here, unlike iPnone. The operating system "iPhone" also has the ease of development, but uses C, and if you try, then it can cause a buffer overflow. In addition, there is a specificity for a particular equipment, so all can not have the same library. I think that the main reason why Android developers chose Java is because they initially did not know the characteristics of the devices on which this OS will work. For example, the creators of the iPhone knew for sure that they would have an ARM processor on their phone, so they compiled the software with this model in advance. And this approach is more efficient, because the battery consumption is of great importance for the phone.



The fact that Android guys are using Java is probably less effective in terms of power saving or processor performance, because it’s associated with the JRE and so on. But then there is the advantage of porting the OS to devices with different architectures. Therefore, if you have phones with MIPS, ARM, or x86 processors, a Java application can be run on all three devices. The developers of Android wanted their platform to be used on any kind of equipment or phone. So probably this is the main reason why they sacrificed security for Java.

It turns out that the Java runtime environment does not provide any special security benefits for applications, it is just a handy thing for developers and users. But from the point of view of isolation, everything here basically depends on the kernel and the reference monitor that controls the operation of applications.

Student: Doesn't simplicity of development lead to some application security? After all, when writing a monitor of references to C, there are many more ways to make mistakes.

Professor:Yes, you are absolutely right! In fact, I should not have said that the ease of development has nothing to do with security. This is completely stupid, because you want to do it as easily as writing the right code. So in a sense, a system for which you can easily write the correct code in itself provides greater security. In a sense, you are right in assuming that the Android developers wanted to avoid mistakes when writing code, so you didn’t want to write it in a complex C language. And I don’t know why Apple chose C as the programming language when developing its OS.

Because such a choice creates a buffer overflow problem in the application, and if this application is important, then it is potentially vulnerable. Not regarding the compromise of other applications, but you still don’t want your banking application to be written in C.



Student: Link Monitor written in Java or C?

Professor: in Android, the reference monitor is mainly written in Java. However, there are some “hooks” in it in order to communicate with external interfaces and applications that use native code. But most of the logic is written in Java. So this is actually quite a safe plan.

And now we will try to figure out what else UID applications are used for, except for separating applications from each other in terms of the processes they initiate. The main reason for using a UID is to create the ability to share access to shared resources and exchange data in the system.

We have already seen one mechanism for this — sending intent to the monitor of links. But in Android there are a lot of things that are not executed through the intent to monitor links. Probably not everything is sent via Intent for performance reasons. You do not want to call the monitor of links for each operation that you do in the system, first of all it concerns access to the Internet. If you want to access the Internet on a device running “Android”, then simply open the socket, just like in any standard Linux application. An application can simply ask the kernel: “I need a socket, because I want to connect to this machine”, this is how the Internet is accessed.

Further, it should be noted access to removable media. If your phone has an SD card, it also communicates directly through the kernel. In general, any kind of access to the file system, or at least direct access to the file system, is carried out directly through the kernel, because there is already a file system there. This is done to avoid performance overhead. In addition, as with most hardware devices, Android allows an application to communicate directly with the device instead of transferring access via the reference monitor. This applies to such things as the camera, GPS-navigator, compass, and so on.



This hardware simply appears in Android, as in Linux, in the form of / dev / camera. It's just a Linux device that you can open to get data from the camera or control the camera in any way, and so on. The cool thing is that if you want to do something special with this device, you are not limited to what Java allows you to do. You can always write code in C or even Assembler, which will communicate directly with the kernel and perform the necessary operations on this Linux device, making arbitrary system calls. And you can clothe it in your own Java interface to conveniently present other Java applications.

Student:but we still check these system calls anyway, because when you open a socket, someone has to check if these applications are allowed to open a socket?

Professor:Yes, so this is an interesting thing! After all, now these operations are outside of our model based on intentions. So how are we going to protect them? This kind of interaction comes down to what you did in lab # 2, entering user IDs into the system. The Android runtime is responsible for carefully organizing the UID and GID applications in accordance with the policies specified in the appropriate tags. For each of these resources, there is a predefined label string that defines the access rights to this resource. So for network access, I think there is a line containing something like “android.permission.internet”, and this is the label that the application can request.



And if an application has this label in its privilege set, then it must have access to the network. The label contains the policy of how this privilege is executed, that is, indicates what should happen as a result. And the execution mechanism is a small change in the Linux kernel for Android. Here, in order to make any network system calls, you have to be a member of some kind of magic group, that is, not like how Linux traditionally works. In Android, there is a certain magic group with the GID ID 3003, and this number is hard-coded in the kernel. If a process has this group ID in its group list, then it is allowed to use the system call associated with the network. And if not, then he is not allowed to make any network system calls. This is how Android can translate these tags into something like system policy support, applying them in various ways. Sometimes execution is initiated by the reference monitor, sometimes it is enforced by setting the GID group identifiers or UID users accordingly.

The same thing happens with SD cards. There is another GID that corresponds to access to the SD card, and there is a corresponding string that corresponds to it. The same thing happens with access to the file system, but only a little more complicated. I assume the SD card is in the file system and has a specific GID for accessing the entire SD card.
In the file system of the phone there is another kind of files for which compliance with the security policy is controlled not by tags, but by the design of Android itself.



This is because each application has a personal directory that it uses to store any files that it wants. In particular, the SQL database of the content provider that you intend to use as an application is stored in your personal directory. The following policy applies to it: only the UID of this application, and no one else can access this directory.

Thus, for devices inside the phone, there is a mechanism very similar to network access, in which there is a permission line for accessing the GPS module, camera, and so on. And for each of them there is a GID used in permissions on this device. So, for example, dev / camera belongs to some magical GID, and any application that needs access to this camera uses this GID if necessary.

I hope it was similar to what you did in lab # 2, not in the sense of tags, but in the sense of using UID and GID to get to some kind of application.

Another interesting question is why system developers came up with just such a way to manage an SD card? Why don't they have different applications that interact with different parts of the SD card? There are probably a lot of different things on my SD card, and I don’t want applications to access them. What do you think about that?

Student: perhaps this is due to the fact that the user must approve permissions for applications, and the lower the number of applications, the less likely that applications will interfere with the management of the memory card.

Professor:may well be. This is definitely an Android problem in general, and we will get to it in a minute. But I think that there is a slightly different problem with the SD card. This is due to the fact that you want the SD card to interact with the rest of the world. This is similar to one of the places where Android is not able to make arbitrary decisions, because you want memory cards to have a standard file system, namely FAT, because de facto it is a modern standard for storing data on a memory card. As a result, you cannot have a complex file system in which permissions for each file are stored, so it will be difficult to somehow separate these files and give different applications different access.

Student: what if each application is given different access to the map directories?

Professor: it is possible that you could give each application a different subdirectory on the memory card and open access to it. But in fact, this will mean providing each application with a separate storage on the map to make it impossible for it to read the entire contents of the map, because it may be contained in a different directory. Of course, there may be an application that you want to give access to the entire map or to several directories, but I do not think that you will have too many permissions options. So you're right, you could use a combination of both access methods.



It is interesting to discuss the next question - how do we decide which set of labels an application must have in order to access specific things? For example, who decides that this application should have a set of labels DIALPERM, INTERNET, FRIENDVIEW?

Student: probably the developer defines it in the manifest, so that the user does not?

Professor:Yes, it is in some way an advance system, in which the developer first of all lists all the things he plans to use in the future to make his applications work. And then the user is responsible for viewing this list and deciding whether everything is in order, whether he should allow the installation of these applications or not. Because of this, the user is an important part of the system in terms of security, because it almost always can approve or reject any permissions. In many ways, Android is more flexible than iOS, where third-party applications for iPhone are difficult to access other components of the phone, dial a number, send SMS messages, view JPEG, etc.

The price of such flexibility is that you must force the user to verify that the developer is requesting a reasonable set of permissions or that the user trusts this developer to have such privileges. So it's a little sad. Probably one of the biggest security concerns of Android is that users are willing to issue these permissions if they really want to install this application. For example, I found some application and click the “Install” button, and if the permissions for this application are a long list, and there is nothing alarming that immediately pops up on the screen, most likely, I just click OK. I can not waste time trying to understand why these permissions are really necessary.

Another nuisance is that at the time when this article was written by us, the Android developers decided that the user should have only two options - either install the application or not install it. Moreover, if the user really needs this application, he will install it, no matter what. Later versions of Android, starting with 4.3, introduced a more detailed application installation scheme that allows the user to select permissions from the list of permissions that the developer would like to have for his application. Thus, the user was able to remove some of these permissions from the application. It remains unclear how an ordinary user should use this, because it is rather difficult to study the entire list and decide what to allow and what not. But at least

55:10

MIT course "Computer Security". Lecture 20: "Mobile Phone Security", part 3


Full version of the course is available here .

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

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until January for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only here2 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?