Paul Kocialkowski's coding blog

Free software, programming and stuff

The Samsung Galaxy back-door was bullshit. Really?

Written by Paul Kocialkowski - - 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.

18 comments

#1 Simon said :

Did you try to contact Samsung prior to the disclosure?

#2 Paul Kocialkowski said :

@Simon : We did not. As a matter of fact, we thought it would make the biggest impact to release our research by surprise, catching Samsung off-guard. What we discovered seemed fairly unacceptable to us and we felt disclosing that out of the blue was the best way to blow the whistle efficiently. Moreover, there is no known remote exploit to trigger that anti-feature: that's not the part we worked on, so not contacting Samsung beforehand didn't cause any further security problem.

#3 Simon said :

By not communicating with Samsung first I fear you may have contributed to their defensive stance. It is uncertain whether they will take any action to fix the issue, especially considering there is no known exploit.

Had you talked to Samsung and explained the implications, there was a possibility, however small, that they would have listened and, given the time to implement it, released a fix. That is responsible disclosure. If Samsung did not respond after a reasonable period of time, then by all means go ahead and disclose anyway.

By doing this you do more to get them on the same side, rather than, as I see far too often with FSF campaigns, simply alienating the very entities you're trying to get to change their ways.

On the flaw itself, I don't consider it to be completely irrelevant in terms of security. Far too often people seem to assume that if it's not exploitable then it's not an issue, but that instantly changes when somebody finds a way to exploit this. I would expect the actual exploit would involve one or more other vulnerabilities, which leads me to...

Some (many?) whitehat security researchers, and security teams in companies, are conditioned into treating vulnerabilities in isolation, so if you can't create an exploit from a single vulnerability the risk is considered to be negligible. The guidelines for CVSS 2, an attempt at a standard vulnerability scoring system, explicitly state that each vulnerability should be scored independently (although the concept of "chained vulnerabilities" may appear in CVSS 3).

An issue that is theoretical with no known exploit or impact will normally be treated with lower priority than one with more certainty, but that does not mean it is not still an issue. (CVSS2 does take "exploit ability" and "report confidence" into account in its temporal metrics, but they are rarely used.) For that, I disagree with Dan Rosenberg that this is a non

#4 Paul Kocialkowski said :

@Simon :
> By not communicating with Samsung first I fear you may have contributed to their defensive stance. It is uncertain whether they will take any action to fix the issue, especially considering there is no known exploit.

I don't think they're going to do anything about it now, unfortunately. I also really doubt they would have reacted any different if we had told them beforehand. The point we have made is that this back-door doesn't let anyone access files remotely, but it lets Samsung do it, since they have control over the modem (simply due to the fact it's proprietary software). Hence, we didn't expect any positive answer unless this was made a scandal, considering they (or whoever they grant access to) are the attackers.

> Had you talked to Samsung and explained the implications, there was a possibility, however small, that they would have listened and, given the time to implement it, released a fix. That is responsible disclosure. If Samsung did not respond after a reasonable period of time, then by all means go ahead and disclose anyway.

The only real fix here is to have a free software replacement. Given that there is no remote exploit, as you said, I don't see why that would have changed their position of not releasing the source code for that software.

> By doing this you do more to get them on the same side, rather than, as I see far too often with FSF campaigns, simply alienating the very entities you're trying to get to change their ways by negative campaigning.

Raising public awareness and having people to complain about an injustice seems to me like a pretty straightforward way to fight against it and demand change.

> On the flaw itself, I don't consider it to be completely irrelevant in terms of security. Far too often people seem to assume that if it's not exploitable then it's not an issue, but that instantly changes when somebody finds a way to exploit this. I would expect the actual exploit would involve one or more other vulnerabilities, which leads me to...

I don't think it is only dangerous after one finds a remote exploit anyone can use. As soon as you consider the modem to be compromized, this is a wide-open gap. The fact that the modem is running proprietary software is enough for me (and many others) to assume that some people can control it remotely. By some people, I obviously don't mean some random attacker, but rather any intelligence agency Samsung is cooperating with.

#5 Ukraine said :

I would not find out about Replicant if not this issue. Thanks!

#6 Hexagonal said :

I will donate to Replicant project :)

Sigh, I've bought n9005 on Qualcomm, because it's easier than Exynos for open-source firmware makers, like Cyanogenmod, but now I have uneasy feeling about its modem which can access CPU DRAM.

And also the ARM (Dis)TrustZone! Another rootkit here, Samsung KNOX.

#7 Paul Kocialkowski said :

@Hexagonal : If Qualcomm is better for open source, it certainly is not better for free software. The amount of proprietary pieces is incredible with Qualcomm, not to mention that these platforms are known to have very poor (to inexistent) modem isolation, which is a big issue for security.

#8 Manish said :

It is naive to think that intelligence agencies are not using this exploit. They can access the filesystem of smarphones and they can even access the filesystem of other consumers products like personal audio recorders.

As far as the issue of "no known remote exploit to trigger that anti-feature" is concerned, If this exploit is being used by an intelligence agency and some one actually knows it and is being victimised by it then will he go against a government intelligence agency ? If a common man cannot go against big corporates and powerful intelligence agencies then I believe it will remain a non-reported exploit.

#9 Bill said :

Paul:
Can you help me UNINSTALL an Anti-Theft program that "locked" me out of my phone?

I've got the Samsung Galaxy Note (1) and when I was setting my security features the Anti-Theft Device locked my phone. I need to UNINSTALL the program using the Backdoor to Uninstall this.

I used my wife's phone as back-up for text messages but because this website ("Ghost" Anti-Theft Security) enables the phone through another matter I need this DISABLED because I cannot get to my (&^$%) PHONE !!!

https://play.google.com/store/apps/details?id=com.Deepsman.Apps.AntiTheftAlarmLite

HELP!!!

BH

#10 Paul Kocialkowski said :

@Bill : I suggest that you install a (more or less) free operating system on your device, such as CyanogenMod, OmniROM or Replicant. That'll solve the issue and grant you better security at the same time!

#11 mixed mind said :

Hi,

Have you got more information about this possible exploitation on Samsung?

#12 Joe said :

Any news on this one?

#13 Paul Kocialkowski said :

@mixed mind : We didn't hear reports of any actual use of this anti-feature, but there is currently nothing in place to alert the user when such an attempt takes place. Replicant will not cooperate though.

#14 Paul Kocialkowski said :

@Joe : The situation is still the same, there are still areas of work and community Android distributions other than Replicant don't seem interested in closing that backdoor.

#15 grafik said :

As a non-programmer with no vast knowledge about linux.
Could you give some easy insight on how to find out if my phone (S4) is affected and how i can patch it.
I read it already: http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor
but it´s not understandable.
I think that would help a lot of people out.
And is this: http://redmine.replicant.us/projects/replicant/wiki/Samsung-RIL
easily installable on CyanogenMod, or installable to non-Replicant roms at all?

Sorry for all these "Noobie-Questions", but making a solution available for the wide public with no extraordinary skills would be a great gift!

#16 Paul Kocialkowski said :

@grafik : I believe that the Galaxy S4 in its UMTS version matches every requirement that would let us suspect that the backdoor is present. Currently, community Android versions such as CyanogenMod didn't show any willingness to solve that issue, so perhaps you should raise the issue with them. Replicant doesn't support that device currently.

Samsung-RIL cannot be installed as-is on top of CyanogenMod, because it requires some in-depth changes to the system. A developer might be able to integrate Samsung-RIL in the CyanogenMod source code and build image with it.

#17 Rena Kunisaki said :

I guess the only way to convince them that it is an issue is to release a PoC. :p

#18 Paul Kocialkowski said :

@Rena Kunisaki : I don't really see how…

Write a comment

Capcha
Enter image code :