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

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

Student: now many applications do not have the ability to delete permissions.
')
Professor: yes, in the new version of Android this is not, just there are descriptions of permissions. But you can use the Android Permission Manager, or the Android permission manager, which allows you to view a list of all the permissions for each application and delete specifically those that you consider unnecessary. But I do not know how this thing is popular among users.

Student: if the labels do not match the permissions that the application requires, does this lead to a serious error or does everything continue to work normally?

Professor: I think it depends on what the application is trying to do and what the label permits. For example, if an application is going to send an Intent and sending this intention requires a certain DIALPERM type label, then it first calls the reference monitor, which says: “unfortunately, there is no application in the system that is ready to accept your message.” And in response to this application is taking some reasonable steps.



Otherwise, for example, when accessing the network. If you do not have access to the network, and you are going to open a socket or give the command to connect to an IP address, the kernel will reply you with the message EPERM, “operation is not allowed”, that is, you cannot do this. And who knows what the application is going to do in this case? It is possible that in some way it will throw an exception of a null pointer or do something like that.

One of the arguments against this is that Android applications, at least initially, did not expect that some of their appeals would fail, because they were told that the manifest is all or nothing, that is, the user approves installation application or not. So the application developers have written the code correctly that fails or does something unexpected if it is denied access. Maybe by depriving the application of the access permissions it needs, you thereby provoke its failure.

Suppose you have an application that needs access to the camera. And if you take away his right of access, a simple picture template will appear on the smartphone screen, or maybe the application will crash. It's not very good. Probably, it would be possible to create a more complex system, which in the case of denial of access to the camera, would simply depict the black screen all the time. Android doesn't do this, but you can imagine alternative situations in which this can happen.

So, we looked at where these lines come from in the labels of Android apps. But who defines these lines, where do they get their meaning from? You can list all kinds of lines in a manifest file, but how do you decide which lines matter where the INTERNET or FRIENDVIEW lines come from? Who gives them value in the system?



I see you have no ideas. I think that none of these lines should be something magical or predetermined. Almost all of these lines are mostly agreements between two applications, when one of the applications is ready to provide something under the protection of a certain Label line, and another application wants to request permission to talk to the application that the component provides.

Thus, these tags are usually defined by an application that provides some services. If you have permission DIALPERM, then it must be defined in the application that defines what it means to dial a phone number. Probably, the application for making calls on your phone is what defines this line and says that, yes, this DIALPERM thing exists, and my components will be protected by it. Then other applications that want to interact with the calling application will be able to request this permission from DIALPERM for themselves.

Of course, there are some built-in things, such as permission to use the Internet, a camera, and so on. But you can perceive them as the source applications of the “Android” runtime, which is responsible for providing access to this resource and determines the string that will protect this resource.

What does this mean? What else is associated with the label in Android, besides the fact that it is used by the application when it needs to request permission? It turns out that there are several things that are associated with a label. In addition to the string, the label has several interesting properties. In particular, in Android there are 3 types of tags. The first one is permissions of the usual type, the second one is unsafe permissions and the third type is signed permissions.



The application that determines this permission first of all gets the opportunity to select the type and all other fields for the label, which we will talk about in a second. So what are these label types? Why do Android tags need types?

Student: do they serve as a warning to the user?

Professor: just like that. Then why not make all the labels unsafe type? What is the semantics of these types? Simply put, the “dangerous” label is used to allow an application that can mess up something. It warns users when installing an application when an application requests access to an insecure permission. At the same time, the user should look at this message and say: “Yes, I am ready to give an unsafe permission to this new application.” If applications request a tag of the usual type, the user does not receive a message about the need to give permission for this action. What is the point of ordinary permissions if all applications receive them? Is there a reason why we should use the usual type of tags?

One example of normal resolution in Android is the installation of on-screen wallpapers. If you have an application that is going to set the wallpaper, I can, as an application developer, indicate in my manifesto that I just want to set you a wallpaper. And if you click "install", nothing interesting will happen, because you do not need to give this application any permissions.

Student: but these permissions usually require confirmation from you, right? If the application wants to change the desktop wallpaper, the system will ask you if you want to change the wallpaper.

Professor: no.

Student: no?

Professor: no, it will just change the wallpaper, because it is just access to the API call. If I have this permission, I just make an API call.

Student: maybe the application developer wants to make sure that users do not do this by chance?

Professor: Yes, I think that this is one of the reasons why you may need these permissions, is to help the developer avoid errors. If you are worried that your application may accidentally do something wrong or there may be errors in it that can be used, then the existence of a set of permissions that you may or may not receive reduces the likelihood of abuse of your application. So if you have a harmless application that does not need to install any wallpaper, you will not need to ask for any permission, because this is better for the user on whose phone it is installed. To some extent this is a kind of privilege.

Another thing is that the existence of tags of the usual type allows you to perform some kind of audit, both from the developer and from the user. If your phone changes the wallpaper on the screen every second, then you can go in and see which application has permission to do so. Even if you didn’t approve of giving such permission, you can still go and check which application is currently changing wallpapers.

Thus, these usual resolutions seem to be a good security measure, or more so, a good opportunity to audit application activity. Typically, this type of tag is not used for really important things, such as working with data or accessing services that cost money.

The third type of label is the permission to sign. An interesting feature of Android is the ability to provide access only to applications that are signed with the same digital signature as the application in which the access right is declared. The lecture article describes an example with the FRIENDVIEW application. If viewing friends has defined permission with this type of tag, then only applications signed with the same developer key will be able to get the same permission. What is the point of this thing? Why not just mark them unsafe? Why do we need the third type of Labels?

Student: Does it make it easier for a developer to manage their applications?

Professor: yes. It may be that this developer has internal APIs that he wants to isolate from the impact of third-party programs, but he also wants to bundle his own applications for productive interaction. Hypothetically, the creators of Facebook could have written several applications. They could have one application that preloads content from Facebook servers, another application mixes this content, a third tracks your location and all these components interact with each other. Here for such a case, they could use a signed permission.

One of the reasons why you would not want to designate this application as unsafe is the following. If you really know who can get this permission, you do not want the user to interfere with it. Because the user can always be deceived, forcing to give permission to a malicious application, so it is better that he does not interfere at all in granting internal privileges to some applications. So in this sense it is better to use signed permissions.

Labels are also associated with a description of permissions for the user. This is a description of what this permission entails. This description appears when you are asked to install a new application.



Thus, the Android runtime will look at all the lines of tags in the manifest of the application you are going to install and display to the user descriptions of all these marked lines, for example: “you are going to give this application the privilege to dial the number or allow sending SMS on your behalf” and etc.

An interesting question: what happens if a malicious application changes the label for some other application? After all, these tags are just free-form strings. So what happens if you are a malicious application that says: “oh, I have this new, big resolution! It is called DIALPERM. It has no unsafe tag, and its description does not give anything. Is it dangerous?

Student: it is likely that it will not be able to affect the structure of the domain name of the application.

Professor: yes, you can hope so, but, unfortunately, this is not compulsory. Usually, all permissions strings should have Java-style domain names, but there is no strict relationship between the labels that the application defines and the proper name of the Java-style application. There is nothing compelling that a Java-style application name be tied to something, so we don’t have a chance to find out if a developer’s public key that signs a specific application matches something on com.google.something or edu. mit.something.

There is one flaw in Android, or at least existed when I recently delved into this issue. So, when defining tags, the principle of “who came first is served”. That is, when you install an application, it defines a specific label, and you can decide what type of label it is and what its description is. For system permissions, this is probably not a big problem, because system permissions or embedded applications, such as a dialer, are defined at the very beginning. But applications that are installed later cannot redefine permissions, because this is due to the framework.

The problem is that if you first install a malicious application, and then some important application, then the malicious application can potentially distort the tags used later by a well-meaning application. The lecture article describes a case where an attacker forces the user to first install a malicious application that changes the label type for the FRIENDVIEW application to a normal type with a description string like "there is nothing interesting in this at all." Later, when you install the FRIENDVIEW applet, it can no longer override this label, because it is already defined, and now the user will not be able to prevent other applications from using the friend view permission.

Student: perhaps the system might warn about attempts to change the resolution?

Professor: in principle, the framework is capable of this, but when I tried to do this, no messages were issued. If you install an application that defines a label that is already defined, the system does nothing, it simply ignores the new definition of the label and uses the old one. Perhaps this is the problem, because of which everything can go wrong. At the very least, the system should have said: “I refuse to install this application because it has the definition of a label that already exists.”

Student: ... and belongs to another application.

Professor: yes, and may even belong to another key. Then at least potentially there is a chance to fix it. I did not track this problem, perhaps I have already fixed it. In any case, this is an interesting problem, when you really have to keep track of these names and find out who owns this name, and getting the right to commit such actions is really very important.

Another interesting Android issue is related to the Broadcast receiver, or the receiver of broadcast messages. It creates the ability to receive and respond to messages from other applications, carrying out something like sending messages between applications. First I have to describe how these messages interact with the receiver. Broadcast receivers are used for one application that is able to announce certain events for any other application in the system.



As we know, intentions are usually addressed to a specific component, such as the JPEG image viewer. But about events such as booting the system or “My friends nearby,” you can announce to each application that it concerns. This is the purpose of the Broadcast receiver.

In this case, you care about two things. First, the authentication of the source of the message, that is, you want to know who sent this message and whether you can trust it. Secondly, you want to control who this message is addressed to, who can receive it.

It seems to me that the Android developers did not quite correctly implement these things. In any case, in the initial version of Android, when you send a broadcast message to all other components of the system, these applications may or may not support this message. Therefore, if you have the “View Friends” application, it will support these messages by using the appropriate components, such as Action or Date / MIME, in its Intent filter of intentions. But most applications can always support all broadcast events in the system, and you can see everything that happens on the phone, or everything that is broadcast.

Thus, the Android framework added an extra argument for applications to indicate who can see the broadcast message.



, , – , , . , , , , .

, , , , , , . Android, , , , .

, ? , « » , . , ? ?

: ? ?

: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?

, . , , . , . ? , « »?

: , , ?
: . , — . , , « ».



Broadcast receiver, , , . , , , Label.

. Android , . « », . , . , , , .

RPC , RPC-, , . , .

: ?

: , , .

: , …

: , . – . . : « ».

: ?

: .

: , ?

: , , . . , , , . , — . , : « , », , , Dangerous Description.



, : „ , ». , , , , . , Android , .

, , Android. , , . , «», « ». , , .



, , . , , , , , . , Java. , , , , .

Android . - , , , , . «» , RPC . , .

, , . , Android , 5 6 . , , , - «». , , .

, Android , , Apple . , Apple iPhone , .

«», «», , , , , , , . , . , , Android, . , - .

, Android .


.

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?