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: “Controlling 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 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 exactly 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 defines 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:exactly. 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, 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 don’t 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 may 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.
Therefore, when you send a broadcast message, it is supplied with an argument — an intent with an additional label that describes who can receive this message. That is, instead of broadcasting to everyone in the system, you can specify that only those applications that have permission to do so can receive your messages.
Thus, you can send confidential information, for example, the location of your friends, being convinced that only those applications that can see your friends list will receive your broadcast message. That is, in Android, at least in the case of a broadcast, you can control who receives the messages you send.
How to verify the authenticity of where the message actually comes from? The lecture article gives an example when you enter the My Friends Nearby application and receive a message that your friend is nearby. How do you know that this message came from the right component? How can you convince yourself of this?
Student: using kernel code? Don't you trust the core of the system?
Professor: maybe so. First, the message from App 1 is processed by the RM link monitor, which checks where the message came from, and then sends it to App 2, to the application that should receive it. But how do you check if this App 1 is the application that should send these intentions? Is there a way to make sure in Android?
I think you are right. Strictly speaking, yes, the source is always authenticated. You know exactly which application sent the message. But what about the source name? How can you verify that this particular source can send messages to the My Friends Nearby application?
Student: perhaps the label describes the privileges of the person who sends the message?
Professor: yes. Thus, one way to do this is to actually stick a label on the receiver of the broadcast messages. So you can say that sending messages to the receiver is allowed only to those applications that are labeled "My friends nearby."
If you put such a label in the Broadcast receiver, you will know that only messages sent by applications with the same label will get to it. Thus, one of the ways to filter those who are able to send you messages is to limit their credentials using the Label label.
In many cases, this is what happens. Android also provides a more specific feature that you can use. It is called "Privilege Check", and with its help you can check the rights of the sender. You can query the framework about whether the sender of the requested function is the owner of the label with the appropriate permissions. Thus, you can also judge which privileges are exercised by the sender of a particular message in situations where the framework does not ensure the correct use of the manifest mechanisms.
The sender privilege check feature is particularly useful in the case of RPC interaction between two applications, when the reference monitor does not actually participate in the mediation of RPC applications, but you also want to know if the privileges for such operations are used correctly. In fact, you can manually use this feature and find out what is in the application manifest.
Student: Is it possible to prevent the exercise of unauthorized privileges by installing signed labels?
Professor: I think yes, the signed type of tags can prevent this.
Student: the same signature is required as ...
Professor:quite right, you will need the signature of the same developer. The second way to prevent this is to mark permission as dangerous. In this case, the user will see a message on the smartphone screen. During the installation of the application, it will say: "This application requires permission to view the location of friends."
Student: but this is taken from the description?
Professor: quite right.
Student: what happens if just another description is used?
Professor:I must say that this description comes from the application that originally defines this label. There are two things in the application manifest. You can request access to existing tags, that is, you can say that this is exactly the application from which you need access to view friends. The second thing you can do in the manifest is to define a new type of label. That is, in addition to what you can say: “I have an application, and it has all the necessary permissions,” you can also define a new type of label, that is, indicate that it is an unsafe Dangerous label and it has an appropriate Description.
This is the place where we have a problem: "who came first was served." But as long as the application that is supposed to determine the label is installed first, you will not have problems. Any subsequent application will only request a label by the string name, and then the Android framework will extract the description and type from the application that first identified them.
I think I gave you some insight into how Android works. A useful feature is that you can get a manifest that sufficiently describes the security properties of the application. Another thing that came up with the developers of the “Android” framework is called “Mandatory Access Control”. In it, you can set the application's security policy apart from the application itself, and this policy will be implemented by the reference monitor, regardless of what the application itself does.
Thus, you get the opportunity to check the application, looking at the manifest file. But this property looks more like the politeness of developers than strict enforcement, because if an application really wants to circumvent its own manifesto, it probably can. But this is a good way to understand what is happening with the security problem of an application without diving into Java code. Of course, this is also possible, but you can still get an idea of what is happening from the manifesto.
We talked about one shortcoming of the Android runtime regarding the manifest. You can still write code that says about security checks, but it would be better if there were no security checks in the code at all, and all the checks would be performed in the manifest. However, this can “substitute” things in a framework like all RPCs and so on. Potentially, this is a small compromise that was used by system developers.
I guess it is quite difficult to modify the manifest file after you have developed the system. Surprisingly, the Android framework has not changed too much in terms of security since the system was created 5 or 6 years ago. Because, as soon as the application starts using this framework, it is difficult to say that some existing application can “break”. So basically, you should maintain backward compatibility, because you can't do everything again.
Another interesting thing that happened with Android after the release of this article is that developers borrowed the idea of Apple and are now analyzing server-side applications much more. So, Apple for its iPhone rather aggressively checks on its server all applications of developers for the presence of various recommendations, including with regard to security properties.
And the Android servers, or the Android market, I don’t know how else to name the sphere associated with this OS, are also intensively analyzing the applications delivered by developers to the market to make sure that they are in some sense not malicious. This is a positive process, which greatly strengthens the security architecture. One security architecture is already built into your phone, but for all other applications developed for Android, an external security check is in place. This is mostly true of phishing sites, where people are simply cheated without intent to use any specific vulnerability of the system core, and so on.
Hopefully we'll see you on Wednesday and talk about extending Android to ensure data privacy.
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 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 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?