Tomas Rosa, http://crypto.hyperlink.cz
Email to: tomas_dot_rosa (at) rb_dot_cz
This material can be freely used for an educational purpose only. Anyway, its usage can be a subject to a law regulation.
The author takes no responsibility for any direct/indirect damage or incident done by exploiting the content of this page.
Last update: November 28th 2011
Page history
November 28th 2011: References update
November 16th 2011: XBRF paper updated to reflect an already existing countermeasure
November 11th 2011: Cross-Binder Reference Forgery (XBRF)
November 11th 2011: Page created
Abstract
This page contains certain security-related details of the Android binder mechanism. Most of them are results of a reverse engineering process, since there is quite a few information available besides the source code itself. Unfortunately, the binder framework source code is far from being an example of well-commented program text. This makes any security assessment an adventurous procedure. The binder mechanism, on the other hand, is the central part of the Android operating system. We may actually say that the whole binder framework is what enables Android to be a truly object-oriented operating system sitting on the top of an Embedded Linux kernel. From the security viewpoint, it follows that to fully understand Android security, we also need to fully understand the binder mechanism itself. By sharing selected parts of his own research, the author of this page hopes to motivate and promote further independent research in this area.
FAQ and other important notes
The binder – what is it? Looking into Android Open Source Project and Android developers guide, we can quickly notice a binder is almost everywhere. There is a kernel driver of this name, there are various C++ and Java constructs bearing this name, there are some notes mentioning a binder in API-doc, etc. This is because the binder framework is really the core and vital Inter Process Communication mechanism of Android. It would be terribly misleading to simply think that “the binder equals the kernel driver”. Actually, most of the time, a binder does not refer to the kernel driver itself, it refers to a code that can be invoked remotely through that driver. More generally, a binder is an abstract interface of such code. Of course, we must carefully distinguish the context in which we are talking about a binder. Furthermore, what appears as a nice object-oriented design in the user-space application level reduces to a simple transaction-oriented message passing between two processes when it comes to the Linux kernel level. Anyway, the reader may consult the terminology of the former, more general concept of the OpenBinder (cf., however, the note bellow). Note that we will use a lowercase ‘b’ when referring to a binder in general. This is to avoid collisions with C++ and Java constructs of the same name. We also do not use “The binder” and “A binder” when referring to the whole framework or to a particular interface implementation, respectively. We simply use the whole expression “a binder framework” or “Android binder (framework)” when referring to the former case. Again, this is for the sake of readability.
Is it the OpenBinder? Unfortunately, not exactly. The Android binder is definitely based on the OpenBinder – that is true. On the other hand, the OpenBinder was far more general concept some parts of which were not included in Android (e.g. the OpenBinder object-oriented shell). Anyway, it is worth it to consult the documentation of the OpenBinder, since a lot of ideas still apply in Android. For instance, the description of the message passing procedures related directly to the kernel driver was the only reasonable information source about this particular subject at the time when XBRF attacks study began (cf. below).
Cross-Binder Reference Forgery (XBRF)
This is yet-potential weakness discovered in the binder reference passing mechanism of Android. Description of the reference passing mechanism together with introduction of a hypothetical XBRF scenario is given in the following short paper.
Rosa, T.: Android Binder Security Note On >Passing Binder Through Another Binder<, seminar note, November, 2011
The last update of the paper noted above shows that at least somebody was probably already aware of the XBRF scenario before. This may actually signalize this is not a prevalent weakness. On the other hand, it is still interesting to explore whether appropriate countermeasures already exist in all the relevant parts of the Android OS. It shall be emphasized that the countermeasure noted above is based on an explicit checking mechanism that has to be done by the user space code serving the remote binder. Anybody, who plans to write its own binder from a scratch shall be fully aware of the XBRF threat and shall consider using similar checks as well. Anyway, a plausible proof-of-concept demo that would illustrate a real possibility of XBRF is still under search. Of course, it will be put here when available together with further possible updates of this topic.
Recommended References
[1] Android Open Source Project (AOSP)
[2] Hackborn, D.-K.: OpenBinder version 1.0, visited 11/11/11
[3] Kobayashi, T.: Android Binder blog, (very interesting, unfortunately a lot of texts in Japanese – anyway, it is worth looking at the source code examples at least), there is also English-written blog of the same author here.
[4] Yaghmour, K.-J.: Embedded Android Workshop, ELCE 2011