Samsung Galaxy Back-door | Hacker News Reader

Samsung Galaxy Back-door

redmine.replicant.us

437 pointswfn93 comments

My understanding is that there's simply filesystem access for the modem, through some Samsung supplied kernel driver. Replicant implies Samsung may have another backdoor in the modem itself, allowing to remotely issue commands accessing the phone's filesystem. That is pure speculation and FUD.

"Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device. In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is likely that it offers over-the-air remote control, that could then be used to issue the incriminated RFS messages and access the phone's file system."

Nothing substantiated there, just speculation.

Edit: This is not even interesting, and I'll explain why: normally, any component that has a kernel driver can already access all your data. The network interface in your PC can already do just the same - it has some proprietary firmware running on it, as well as a privileged OS driver that can see anything the system does; and it's connected to the internet.

Most likely, Samsung placed the driver there for providing a convenient storage area for the modem's firmware, in case it requires one (for logging, updating or whatever).

You don't have to suspect a deliberate back-door in the "modem" software to be worried about this; you just need to think that it might have an exploitable bug. And odds are very good that it does. See, for example, the following:

http://www.osnews.com/story/27416/The_second_operating_syste...

No doubt this thing is full of holes, but the fact the modem can directly access the RFS barely registers as an elevated security threat. There's so much an attacker can normally do when they control the modem (MITM, exploiting system services, etc).

A modem can't MITM https without the key. And all http traffic can be MITM'd anyway. So having control of the modem doesn't get you anything that you wouldn't otherwise be able to get by vacuuming up the traffic further upstream.

What's an example of exploiting system services?

Let me get this straight, you're equating having control of a device with DMA with being able to sniff a network connection?

If you really think they're the same thing, I have some baseband software for you.

I didn't know they had DMA.

Ding!

That's the key. There is no news here because every phone running every OS is back-doored[1]. Completely, totally back-doored. This includes every single phone "replicant" has ever been installed on.

There is a computer in your phone, that you cannot access, running a closed source, proprietary OS that your carrier controls, that has (in many cases) DMA access to your "actual" phone.

Your carrier has total control over that computer in your pocket.

Game Over.

[1] With the very tiny exceptions of calypso-based motorola phones running osmocom and possibly the neo freerunner phones ... but I could be wrong about those...

The modems in question here don't have direct access to system ram or flash, which is why Samsung is using an RPC mechanism to the application processor to store data on behalf of the modem (which quite possibly has no local flash at all -- designs do vary). Typically these are supposed to restrict the modem's storage to its little sandbox -- sounds like this one fails to do so (and runs as root which should not be necessary to provide the service).

This is merely a helper, but not necessarily to circumvent "sandboxing". Probably the honest firmware update routines use this route to make code smaller.

How do you MITM someone specific that may be thousands of miles from you? Much easier when you have access to their modem.

Exploiting system services - you can attack any kind of non encrypted traffic flowing through the modem. Such as unsecured applications running with broad permissions. Or you can inject data into kernel services that communicate directly with the modem.

I don't know if on these phones the modem presents itself as a simple serial device, or if it has its own kernel driver (/dev/modem). If it does have its own kernel driver running in the phone, then this driver becomes an easy target for attack, granting full system access.

You are clueless on how the modem works on Android phones. On all nexus, which I'm familiar, modem firmware runs with more ring priority/privileges than the OS.

Have https keys in memory? Now so does the modem firmware if it wishes.

I've spoken to a Qualcomm engineer about this article. He responded by telling me, in fact, he was one of the engineers that dealt with the issues that highlighted after it was published. He asserted all of those remote-execution holes were addressed, and the article has been a constant pain since because it was never updated to reflect that.

I'm not a close friend of his, but I've met him on multiple occasions and felt confident he was telling the truth.

I'm not sure what this post is supposed to accomplish.

Even if Qualcomm has patched all their vulns and isn't in cahoots with the NSA (a laughable claim), it still needs to prove that to the users.

Otherwise it's just the word of some anonymous person on the internet who "knows a guy at Qualcomm" ....

I'm glad you trust the guy but I'd rather not waste time on this. The world needs a modern, auditable, free RTOS for baseband processors.

Yeah, I agree. I just wanted to mention it, since that article does get dragged out quite often.

Unless they can point to a update that have been pushed to all Galaxy devices which solves this problem I don't think Qualcomm can complain.

I've worked with Qualcomm chips before and I guarantee you that it was only due to the public response that they fixed those holes. Qualcomm has an institutional problem that makes it nearly impossible for them to make secure silicon and any fixes they apply now are just damage control.

For example, this is how firmware is treated: https://news.ycombinator.com/item?id=7336248

That anecdote appears to relate to Broadcom rather than Qualcomm.

I think the point is that Qualcomm is quite similar. I wonder why.

Taking a closer look at these functions, using the objdump decompiler, reveals that they are actually called from the ipc_recv_rfs function, itself called from process_ipc_notify_message, which appears to handle the received messages from the modem. Hence we can deduct that the incriminated functions are actually called upon modem request.

This could just as well be a result of the modem's normal runtime (e.g. logging). No one has proven this interface is deliberately accessible over the air.

I think your onus of proof is backwards. We shouldn't need to prove that this interface is accessible over the air. They need to prove to us that it's not. It's not easy to prove it's accessible over the air. But it's easy for them to prove that it's not. They hold all the cards, after all.

Actually, my interpretation (which admittedly is based off of limited knowledge of hardware, the Linux kernel, and operating systems in general) was that the baseband processor itself doesn't have a kernel driver, per se, because it's software doesn't run within the Linux kernel on the main CPU; rather it runs on the baseband processor, and presumably communicates with the kernel via some bus. It is my understanding that the alleged "backdoor" is based on the fact that the kernel allows the baseband processor to access the device's filesystem over this bus, via the libsamsung-ipc component. Please do correct me if I'm missing something here.

Now, if that's correct, then this is in fact significant, because the baseband processor would not otherwise have such access to the filesystem (since it's not, as I understand it, running in the kernel as a driver).

All that being said, the entire thing hinges upon what really goes on in the baseband processor? There are certainly legitimate engineering uses for such filesystem access (as pointed out elsewhere in these comments), so is there really a corresponding backdoor in the modem to allow an attacker full filesystem access on Galaxy devices?

We may never know...

You are not missing anything. However you have so much Samsung code running in privileged mode on these devices, that picking this issue out and calling it a "backdoor" (implying malice) is an especially nasty PR tactic. This leads to classifying legitimate engineering decisions as something of an evil nature.

I would have to agree with you somewhat. Perhaps this is just FUD.

However, I will say that a lot of the FSF's/GNU project's platform is based on the idea that, with unchecked closed-source code running on a device, such backdoors are possible. (Call it FUD if you like.) Fifteen years ago in the days of Windows '98, that might have seemed ridiculous or improbable, but I believe that in the present climate their concerns have become more relevant than ever. In that sense I think that this Replicant project is really interesting, and I'll probably be paying attention to it in the future.

That being said, they surely aren't making any friends at Samsung by doing this, which could hurt them in the long run (compare to the relatively fruitful, although sometimes tumultuous, relationship between Cyanogen Mod and Google).

Also, the elephant in the room here is still the unchecked software running on the baseband processor, no matter which way you look at it.

>> Now, if that's correct, then this is in fact significant, because the baseband processor would not otherwise have such access to the filesystem (since it's not, as I understand it, running in the kernel as a driver).

You'd think so... The baseband processor is actually integrated on the die of current gen SoCs from Qualcomm and plenty of the teardowns I've seen for high end phones use them. I haven't used these chips but everything I've read leads me to believe that there is a lot more integration between the radio and processor (that's the point)... and as a result, a larger attack surface.

Yes.

Some further research I did since this thread started has shown that in some phones, even the microphone and camera are under the direct control of the baseband processor. In others, it's not. But in most phones, the CPU and BB share memory, which opens the door for the BB to do all sorts of nasty things to the OS on the CPU.

https://www.youtube.com/watch?v=fQqv0v14KKY

The FSF stance is equally opposed to the proprietary network interface in your PC, so I don't see why that diminishes anything. They propose people ideally use PC's with completely Free/Libre drivers for everything and BIOS even, for these reasons, among others.

apologetic much? Its funny that you mentioned updating, its in fact the case that any network operator (or potentially anyone who can afford the equipment and has the knowledge/keys for it) can upgrade the firmware of the baseband processor remotely (OTA). So you don't even have to exploit a vulnerability or use a backdoor (that people can STILL deny their existence as conspiracy theory is hilarious).

And whats the difference to other entry points in the android operating system itself, a apologist may ask? First of all you have control over this portion of the device, you can read and audit the source code and employ selinux to harden the OS. The baseband processor on the other hand does a _LOT_ of complex parsing of huge binary protocols, exactly the point where you would want to have open source auditable software, the opposite is the case: The baseband firmware is largely a black box, nobody (not even the manufacturer of your phone) has access to the source code and can independently audit the security and remove backdoors placed there by the manufacturer hinthint.

"normally, any component that has a kernel driver can already access all your data" bullshit.

Any thoughts on whether or not this is part of the OTA update infrastructure? Seems like having the modem be able to put data into the file system at a particular place that the boot loader/flasher knows to look for would be a typical sort of "install firmware when the firmware is broken" kind of thing.

This is certainly possible (also possible for the modem to leave instructions for the phone to perform a remote wipe, for example).

The other way around is also imaginable - where the modem temporarily stores new firmware on the RFS upon reception, before updating itself, to reduce its own (likely expensive NOR-based) flash memory requirements.

Typically these services are intended to allow the modem to access factor calibration data, possibly page firmware in, or to store nonvolatile information it needs longer term. They should be restricted to just storing data on behalf of the modem and not providing broader filesystem access (that's at the very least (assuming incompetence rather than malice) a bug).

Brian Swetland! Source of great wisdom in the early days of Android.

Wouldn't that assume the Linux userland was up and running when the bootloader wanted to update itself after rebooting? I don't believe that is the case.

In modern qualcomm devices the primary boot loader (PBL) can usually only boot from it's own area of the eMMC (embedded SD card essentially, but based on MMC 4.0 not SD 2.0), possibly from a connected microSD card, and from an authenticated (and probably signed) download over USB or serial. This is controlled by one time use fuses (called Qfuses or Efuses).

The PBL loads and authenticates the secondary bootloader, SBL/QCSBL which runs a more advanced version of the download protocol and normally will launch the userland bootloader. (I'm not sure where the modem software is started here. The SBL may very well support the same or similar RFS IPCs from filesystem access to the eMMC, though I don't know of any RE that indicates that.

Of course, a compromised firmware could also reprogram pins and bitbang the eMMC, or just use it's own MMC interface as the bootloader can, rendering much of this moot.

I'm sure saurik or comex could add a lot more to this discussion.

This reads mostly like an advert for Replicant.

"However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors."

I am sure that people who run alternative ROMs/OSes would like to know if they are affected or not, but there doesn't seem to be much mention of that... except this line, which seems to indicate that at least Cyanogen IS affected:

"Alternatively, the kernel could block the incriminated RFS requests and keep a trace of them in the logs for the record. That option would work for CyanogenMod, where the incriminated proprietary blob is still used."

I've heard about Replicant before and am interested in it, but something about a self-serving warning like that turns me off.

EDIT: Okay, my bad. I thought this was like a public announcement, not just a wiki page. That makes the context different, so my comments about reading like an advert are not nearly as applicable.

I know this will not be a popular thing to hear, but the scope of the problem has convinced me that this won't end until everything is open. The only trustable stack is one that begins with open hardware and ends with creative commons content in ogg in VLC on linux.

I love open source, but.... it's going to be damn hard to turn a buck.

So, which do we want more: the ability to make money and the right to be paid for our work, or liberty and privacy?

That is one hell of a would-you-rather. Thanks, NSA, for forcing a disgusting thought experiment into the real world.

> it's going to be damn hard to turn a buck

How about turning a micro Bitcoin with it?

An open stack is not enough because you can't trust any compiled software. In practice, even if we had a completely open stack and no binaries, we can't even begin to write error free code. Defeating the NSA [via software], a billion dollar agency with the power to ruin your life is completely unrealistic. Any real change must come through political action.

Political action? How has voting worked for you? My hope is as the dollar starts to inflate away (like every other fiat currency that has ever existed) we all instead turn to a block chain currency. Something that can't be manipulated. Something that can't be stolen from us and used to fund three letter agencies.

How are those hyperinflation calls working out for you?

idk about American inflation, but as a Canadian getting paid in USD, the value of USD has decline significantly since last year. Lowest since 2009:

http://www.xe.com/currencycharts/?from=CAD&to=USD&view=10Y

I got a nearly 10% raise thanks to a strong Canadian economy and weak American one. Keep it up guys.

> the value of USD has decline significantly since last year

According to your chart a year ago 1 CAD got you around 1 USD and today it gets you 0.90 USD. Normally that's not interpreted as a decline in the strength of the dollar.

Unless I've had a stroke this morning, according to this chart, the value of the USD has strengthened compared to the CAD over the last few years.

It doesn't appear that random guys on the internet are having much trouble stealing blockchain-based currency. I'm not sure why you think the NSA couldn't do it too.

When you store your private keys in a centralized repository, where they can be taken by asking nicely (as in SQL injection), you are either not using a blockchain-based currency, or you are using it badly.

The same is true if you generate a private key with a lower entropy source to simplify encoding (called a brain wallet for some reason.) Yes there a longer passphrases that do have more entropy, but you are still limiting the alphabet and the complexity for dictionary attacks.

used to fund three letter agencies.

I mean apart from sanitation, medicine, education, wine, public order, irrigation, roads, the fresh water system and public health, what have the [government] ever done for us?

If you really want no tax, go move to Vanuatu. It's a lovely, sunny place, the people are happy, the army and the police are the same thing and only 800 strong, the government is small, it's off the political radar so draws little interest from TLAs, English is an official language... and there is no income tax (with the exception of landlords), nor are there several other taxes on businesses (as it's a tax haven).

You don't want money 'stolen' from you? Then here is a realistic option available to you, one that is entirely achievable rather than pretending that it's possible to turn a country with a major economy into a tax-free zone, and wringing your hands that it obviously can't be done.

Property tax could be enough to fund most of the essential things you listed and is still enforceable even if a cryptocurrency is a primary currency. While your currency and income might be hidden, you still need to live in a house on land.

ala https://en.wikipedia.org/wiki/Geolibertarianism

Despite the extremely common misinterpretation by the public, ~90% of libertarians are not anarchists who completely oppose taxation. They are "small government" (aka minarchist), not "no government".

You're right, kansface. But I'm not a U.S. citizen, so political action isn't really a practical option. Also, it is arguably wrong to interfere in the political machinations of a foreign democratic country, no matter how irrationally that other country is careening.

While you're right about binaries, there is nothing impractical about compiling things (cf ports tree).

Open Source is something that works now, today, here. It's not a great solution -- see above -- but like democracy, it might be the best we've got. (Or in this case, got left.)

Trusting compiled software isn't a big deal with digitally signed deterministic builds like Bitcoin and Tor are starting to do (http://gitian.org/)

Unfortunately it's a huge pain to do with existing toolchains.

How do deterministic builds address exploits compiled into the compiler itself?

Ah yes, the Ken Thompson hack. It's possible in theory, but I don't think anyone is seriously worried about it.

One way to mitigate the attack: if your compiler is open source you could compile the compiler with multiple (open source and proprietary) compilers, then compile your application code using the resulting compiler binaries in the deterministic build process. If the resulting application binaries match, then either none of the compilers are compromised, or all of them are. The latter seems highly unlikely.

Also, open source software compiled by the user would be just as vulnerable.

Open is more trustworthy than closed but that doesn't imply open is truly trustable. Ultimately do we need to trust the hardware at all? Can't we eventually just trump everything with encryption?

I think you'd have to analyze all of the hardware you use, which seems impossible given the sheer quantity of hardware in use.

To actually use your data you have to decrypt it somewhere...

It's hard to profit because of competition from proprietary stuff. If we could stop people using and paying for proprietary, there'd be enough funding for Open Source everything.

It is a false assumption to think that software/hardware would not get made and paid for if it had a different economic model. Like if everyone was used to toll roads, it would be pretty common for people to say things like, "our road system could never be any good without tolls."

Society has undergone massive economic and cultural changes that most people thought were impossible.

I bet 100 years ago that 98% of people would say "impossible" to the prospect that hospitals would exist that would treat anyone without requiring them to pay.

You're right, I did make that false assumption. Thanks for pointing it out.

Thank you for that example. It's very illustrative. Everything is impossible until it happens, at which point it often becomes everyday.

So it seems our biggest worry, that the modem firmware could be backdoored was very warranted indeed. We need to push OEMs and modem makers to open source the firmware for their modems.

Which doesnt help against silicon-level backdoors, which for all we know, exist and get exploited :/

edit: this includes so called "undocumented features" like maintenance access etc.

That's my least concern to be honest. My rice cooker could have a spy device installed without me knowing. I think the first priority is software exploits and backdoors because they are the easiest to implement and the cheapest to operate with.

Actually, it's sort of a myth that hardware is fundamentally harder than software. The toolsets simply haven't been as powerful until recently.

Hardware can be thought of as hardcoded software. But it's no longer the case that hardware is hardcoded. Hardware is becoming increasingly sophisticated, especially in their ability to be reprogrammed on the fly.

> "Hardware.. ability to be reprogrammed on the fly."

Um.. that's not hardware.

Yeah, firmware. Programmable hardware. And these days, everyone and their dog is programmable...

The line is a little fuzzy, but I'd consider EEPROM to be essentially programmable hardware. x86 has dozens of nonstandard but functional opcodes; how do you know that none of them does something unfortunate?

You don't even need that. You could even just have a completely ordinary, run of the mill, valid opcode do something unexpected when given "magic" data. Like if you mov the value 0xDEADBEEFBAADF00D, the code also jmp's to the top of the stack, as an easter egg.

FPGAs are pretty much hardware. And they're reprogrammable, as in "re-wireable".

Interesting. I did not know that.

Regarding hardware reprogrammed on the fly. That sounds like something FPGA is really good at for powerful computation, except, you can't make a sensor detector unless there is already a physical sensor detector attached. It would be cool to make hardware to make hardware :)

That's true, but network equipment, including mobile baseband processors, are silicon as well. Exploiting them would need help from the network operator, but I think mobile carriers are not very protective of their customers against government inquiries (or at all).

Why go to the network operator? Simply fire up your own, the hardware is sub-$1000 these days and the software open source.

That's exactly right.

Also, maintenance access is one of the easiest backdoors to exploit. The Target credit card breach was done through the maintence access in the HVAC system.

True. Nevertheless, silicon backdoors tend to be way more expensive to exploit and often require physical access.

This is in opposition to software backdoors which allow someone sitting in a room 4000km away to own you with no outlay of money or resources on their part.

One problem at a time. Once we get the software stack open, then we can start going after the hardware stack.

For those who are saying that this isn't a backdoor, you can actually force execute this command on GSM phones for a few thousand dollars [1] [2].

[1] http://rangenetworks.com/products/openbts-development-kit

[2] https://www.youtube.com/watch?v=RXqQioV_bpo

Free Software Foundation & Richard Stallman always warned everyone of the potential dangers of non-free software, even as drivers like these modem drivers.

It's not clear to me the important issues: what data can they access (all of it?), who can access it, and under what circumstances?

On phones where the IPC driver is running as root, then it can access any file on the device. On phones where it is running as the user, then it can access any file owned by the user. There's a chart.

It's a Samsung. I find hard to believe that Samsung smartphone users have any concern about privacy and/or security.

Care to elaborate?

As a linux user, and (very) amateur kernel hacker I've always bought Samsung phones because they've been pretty forecoming with releasing the source for their android devices: http://www.androidcentral.com/samsung-galaxy-s4-kernel-sourc...

Obviously this is a GPL compliance thing, but it enables security minded people like myself to root the device, inspect the underlying source, and secure it pretty much like a regular box.

What alternative do you suggest?

> releasing the source for their android devices

> it enables security minded people like myself to root the device

Actually, having kernel sources doesn't enable you anything except for, possibly (but not certainly), building (but not installing) your own kernel.

You're able to install customized kernel and/or recovery on most Samsung phones, but that's completely unrelated to any FLOSS source code releases. Actually, this is usually done using proprietary tool (ODIN) communicating with proprietary hardware and firmware. They're just generous to allow you to do so (but they tick a flag stating your firmware is unofficial, and recently they started to blow a fuse to prevent unticking)

In my understanding, it needs operator level access to control the modem, or is it also possible to control the model using a MITM like scenario (off the air interception). If the latter is possible, it can become all the worrisome! Any ideas?

Yeah, of course. Calls itself IMSI Catcher (the variant used by police/secret service). You can build one yourself with OsmocomBB and the rest of that open-source GSM network infrastructure stuff.

Voila, there is your operator-level access from the radio side.

> Samsung Galaxy devices running proprietary Android versions ... > Nexus S

I am confused. The Nexus S does not run a proprietary Android version.

I may be misreading the link, but proprietary seems to be using to describe non-open source binary blobs. This is typical of drivers, most chips on cellphones do not have open source software to control them. Typically these pieces of software are modem/radio chips etc.

It does - the stock "unspoiled" version of Android that comes with Nexus devices still has lots and lots of proprietary binary-only code.

This post is from the Replicant project, who are trying to build an open source system on top of the free Android subset.

I wonder how many individuals right now are working on exploiting this potential hole to steal BTC.

NSA approved phone.

eli5?

This isn't reddit, and if you are five, then you should be in day care.

You shouldn't insult people who are curious to learn and/or shun them.

I agree that the response was disrespectful. But I also don't think the original post showed much intellectual curiosity.

Hacker News is a marketing implement for a business development company, whose primary mission is taking inexperienced people and giving them a leg up.

The idea that you have to be an expert in everything before you ask anything runs counter to the point of the site.

Your phone has 2 (or more) processors in it. One that runs the kernel and the operating system that you think about as being Android. The other is another ARM processor that runs closed, proprietary code, and it controls the radio.

The concern is that the proprietary code has an API that can access the filesystem. If the MODEM receives a command from the cellular tower, or another device that looks like the cellular tower, it looks as though the radio's processor could be instructed to extract data from your phone and perhaps send it out over the radio to some other party. The reverse could be done as well, putting data on your device.

Since this happens low-level, it communicates with the kernel on your main processor and is outside the normal security measures placed on regular applications running on your device. If the radio firmware doesn't have an explicit way to perform this task, the other concern is that a vulnerability in the radio firmware might be exploited to do this anyway. Because the radio firmware itself is closed source and proprietary, the real implications of this are still not well understood.

The project that discovered this about the radio firmware is trying to create an open-source replacement firmware that runs on your radio's processor. In the course of trying to implement a compatible firmware, they discovered these questionable APIs.

The implication is that even if you completely replaced your ROM on device with a trusted and secure open-sourced one, the proprietary closed-source drivers that are needed to communicate with the hardware, may be able to do things without your permission or detection.

thanks:)

Reply on news.ycombinator.com