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: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" 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 the side channel" Part 1 / Part 2 / Part 3
Lecture 17: "User Authentication" Part 1 / Part 2 / Part 3
Lecture 18: "Private Internet browsing" 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 used to write my small program in C 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 changed completely, 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 with the phone things are different.

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 laborious 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 a 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 it 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 the 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 some 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 within 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 is wiser to follow the path of creating web applications than desktop systems, at least for the 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 an 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 so on.

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 see 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: perhaps 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 this 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 optimizing web applications is quite difficult, they are limited by the use of RAM and 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” from the cache. However, I think, as you noticed, web applications, albeit slowly, but “catch up” with Android by eliminating the limitations that exist today. 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 start developing 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 app 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 will 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, Assembler, something can 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: maybe there is some system that can damage the code itself written in C?

Professor: Yes, so, 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 “speak” Java.

Student: I think in some way 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, as opposed to 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 libraries. 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 in 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 Android developers 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 significant, 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 find 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 of the reference monitor. 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 go online in a device running “Android”, then just open the socket, just like in any standard Linux application. : « , », .

. SD-, . , , , , , . , . , , Android . , , GPS-, .



«» Android, Linux, /dev/camera. Linux, , , . , - , , Java. C Assembler, Linux, . Java , Java-.

: , , - , ?

: , ! , . ? , №2, ID . Android UID GID , . , . , , , - «android.permission.internet», , .



, . , , , . — Linux Android. , - , - , , Linux. Android GID 3003, . , , . , - . Android - , . , GID UID .

SD-. GID, SD-, , . , . , SD- GID SD-.
, , Android.



, , , . , SQL -, , . — UID , , .

, , , GPS, . GID, . , , dev/camera - GID, , , GID .

, , №2, , UID GID , - .

, SD-? , SD-? , SD- , , . ?

: , , , , .

: . , Android , . , SD- . , , SD- . , Android , , , FAT, - . , , - .

: , ?

: , . , , . , , , , . , .



— , , ? , , DIALPERM, INTERNET, FRIENDVIEW?

: , , ?

: , , , . , , . , . Android , iOS, , iPhone , , , SMS-, JPEG . .

– , , . . , Android , , . , - «», , , , , OK. , , .

, , , Android , — , . , , , . Android, 4.3, , , . , . , , , , . , , API, , .

55:10

MIT « ». Lecture 20: "Mobile Phone Security", part 3


.

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

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

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?