daily

News Update

What You Need to Know About iOS Malware XcodeGhost – Mac Rumors

I don’t think that’s a correct analysis of the situation.
What has really happened here? Developers have used the wrong tool (we’ll discuss that later) and that tool has embedded some unwanted additional code in their apps. BUT look what still worked
– each broken app STILL has to be submitted to the app store, with identification and an audit trail

– even when the app is on an iOS device, there are severe limits to what it can do. It still can’t break out of the OS protections, randomly control the device, etc. The type of info being sent back to base is, let’s face it, not THAT serious — not ideal, but not control of the machine.

– The items that ARE problematic (and which Apple should work on fixing) are items that were problematic before we knew about this, and that have been used in other contexts — the ability to phish for passwords by throwing up fake dialog boxes, and the way the current sandboxing FORCES Password apps like 1Password to transfer data over the Clipboard.

What this REALLY provides is a way to throw out a bunch of these phishing scams in a way that can’t be traced back to the real scammer; only to the developer using the wrong tool.

Which gets us to that issue. I don’t know enough about XCode to know what was and was not breached on that front. Obviously the entire XCode package should be signed, and obviously if you’re stupid enough to install an XCode package that complains about being unsigned, you’re setting yourself up for trouble. But blaming the victim, especially when the security landscape changes every year is not helpful — how could Apple do better?
You can’t really avoid people being able to write their own compilers and dev tools, and you can’t stop those dev tools from doing god knows what to the code they create — this has been known since Pike’s infamous C compiler of the early seventies.
What you SHOULD be able to do is not allow code that has been created by such dev tools into the app store. THAT seems to be the flaw that needs to be fixed — that any tool that’s generating binaries that will land up in the store needs to be provably signed. But I don’t know how feasible that is. Obviously the last stage (the actual store submitter app) is provided by Apple and signed, and using the developers signature. But what about the linker beforehand? And the compiler before that? And you then need the binaries passed between the two to be encrypted? It’s just totally inimical to the current expected model of how we code.

So what about at a higher level? Do something that’s a ugly hack, but basically FORCE that any installer that calls itself “XCode” has to be signed no matter what? That’s one package that you can’t install regardless of your GateKeeper settings except from Apple. But then you get a wack-a-mole of packages called “XCode 7” and “XCode!” and “XCode Pro”.

Good analysis, but there is something Apple could have done, and I have been saying as much for over a year. Here’s the more strongly worded one:

They should ban their in-house teams from throwing up a password request box. Absolute ban. It has got out of hand recently with stock apps asking for the password without any justification or explanation and pretty much at random. I’ve said it over and over, Apple have been training their users for exactly this scenario – enter password whenever anyone asks. If an app needs the iCloud password it should instruct the user to enter it in the appropriate settings page. Train users: only the settings app should be trusted with passwords.

What You Need to Know About iOS Malware XcodeGhost – Mac Rumors

Comments are closed