Paul Kocialkowski's coding blog

Free software, programming and stuff

Awesome

The Samsung Galaxy back-door was bullshit. Really?

Written by Paul Kocialkowski - 15 march 2014 - 18 comments

A few days ago, I disclosed (on behalf of the Replicant projet) our research regarding a back-door found in a proprietary program running on Samsung Galaxy devices' applications processor. This back-door lets the modem perform I/O operations on the device's storage.

For the full statement, please refer to the article posted at Free Software Foundation's website. The relevant technical analysis is available at the Replicant wiki and a complementary statement was issued at the Replicant blog.

In the few hours following the publication, an outstanding number of technology-oriented websites relayed the news, including Phoronix, Slashdot, LWN and XDA-Developers. I'm very glad the press found interest in that research and I'm confident it'll help more and more individuals realize the importance of being in control of their computing: that is, to understand what's at stake with free software.

A few recent developments particularly caught my attention: Ars technica bothered to ask an actual security researcher, Dan Rosenberg his thoughts on our findings. Good thing they decided to go deeper than only duplicating the information. On the other hand, Samsung issued a statement about this issue:

Samsung takes the security of its products extremely seriously. We have investigated the claims that have been made and can confirm that there is no security risk. The Free Software Foundation’s recent allegations are based on a false understanding of the software feature that enables communication between the modem and the Application Processor chipset.

Mostly, the point that is argued by Dan Rosenberg is that there is no evidence of any ability for a remote party to use the back-door, nor any known exploit to make use of it remotely. As a matter of fact, we didn't look at how this could be used over the air: this was not the point of our research. The problem we intended to highlight is not so much about how in practical terms an intruder could use this anti-feature remotely to access and modify the data stored on the device, but rather to show that a particular proprietary software implements a feature that could be used to let the modem gain data I/O access over the device. This is where we find the back-door to be: at the interface between the modem and the applications processor. We do consider the modem to be an “unknown” area that offers no guarantee at all regarding security, since it is running proprietary software. Hence, we believe it is relevant to assume the worse and consider it compromised and subject to remote control. Several indications tend to make us think this is actually what is going on: Craig Murray described how a mobile phone had been remotely converted to a spying device in Murder in Samarkand. Considering the recent revelations regarding the practices of several governments' intelligence agencies, we find it hard to believe there is no way modems cannot be remotely compromised.

The goal of our action was to make people aware of that particular issue. One might consider it to have no value, provided they don't think modems can be remotely compromised and others might see it as a crucial security flaw in the event the modem is compromised, as we do. The fact that it was implemented for another purpose or was not intended to be used in malicious ways doesn't change anything at all: an attacker with remote access to the modem will be able to issue the incriminated requests. There is no possible “false understanding”, in the way Samsung seems to imply here.

For the record, we didn't at any point intend to distort the truth to bring attention to our project or our research, nor did we intend to ruin Samsung's reputation. We simply felt it was our moral responsibility to spread the word about it. I believe anyone can decide for themselves whether they have faith in Samsung's good word that this introduces no further security risk, but let it be clear that it doesn't get any more certain than what good faith can provide. We are still looking forward to working with Samsung to make things right, in case they decide to abandon their current position of denial.

What's up with the Android SDK?

Written by Paul Kocialkowski - 05 january 2013 - 11 comments

A couple days ago, I announced, on the behalf of the Replicant project, the release of the Replicant 4.0 SDK, motivated by some recent license change regarding the Android SDK: Google decided to put an overall non-free license for their SDK. After talking about it on IRC, FSFE member Torsten Grote decided to write an article to raise public awareness: Android SDK is now proprietary, Replicant to the rescue. In the next few hours, that news was being relayed by some online IT media and it sometimes got a bad review, calling our statement a “non-issue”. Let's check our facts and clear out the situation.

It was first brought to our attention that the SDK is being released under a non-free license only a couple days before releasing the Replicant SDK. We didn't know about it before and thus assumed that this was a recent license change. As a matter of fact, we were wrong: we have been told since then that these terms of use have been there all along the way and only a small part about fragmentation have been added with the Android 4.2 release. However, as far as I can remember from the past (and please let me know if I'm wrong), the end-user didn't have to explicitly agree to these terms before downloading the SDK. Now they are required to do so before being able to download the SDK package. That's one first thing that we find unacceptable: we believe that anyone should be able to develop applications for the Android platform without having to agree to such terms. Now let's take a closer look at what the user must actually agree to:

you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK.

These conditions seem totally unacceptable to me and are likely to cause a reaction such as calling the Android SDK proprietary from anyone who values software freedom. However, let's not stop there and let me get back to what is right before these statements in the license text:

You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, 

The last sentence is the meaningful one: it means that basically, the restrictions are not applicable to software that is covered by another free software license. So that's basically how Google can avoid breaking other licenses terms. Moreover, Google is not the copyright holder for all of the software released in the SDK, so they basically have no right to apply such restrictions to it. Huh, we're safe, after all, the Android SDK still is free software. But wait, is it really? Are all the files shipped with the Android SDK proven to be free software? If that was the case, then why would Google waste some time writing down these terms if they actually do not apply to anything in the SDK? So that point gives us fair enough reasons to suspect that there is actually proprietary software in the SDK. Yet another good reason to release a free SDK such as the Replicant SDK. Now let's consider the Android SDK manager utility: it is designed, down to the source code, to check for plug-ins and updates from Google. If I recall correctly (once again, correct me if I'm wrong), there used to be a clear license statement for each components: the Google APIs were shown as non-free software in an explicit way and the emulator images were somewhat shown as containing mainly free software. Now Google changed all this, and all the components show the same EULA terms. Now how can the user make any difference between what's free and what's not in that components list? Sounds harder than it used to be, and like a problem to us. That's why the Replicant SDK won't check for new components from Google. So here are the reasons why we call the Android SDK proprietary and why we think that there is a problem with it. Even though not all of this is a sudden change, why would it be any less relevant to try and raise public awareness about the issues we've spotted?

2013-01-06 Update: I've checked the license of the individual software components shipped with the Android SDK and it turns out that all of them are covered by a free software license. What's the point of that overall proprietary license then?