Paul Kocialkowski's coding blog

Did you try to contact Samsung prior to the disclosure?

@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.

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

@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.

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

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.

@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.

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.

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

@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!

Hi,

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

Any news on this one?

@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.

@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.

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!

@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.

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

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