Hacker News Reader

Comment by microtonal | Hacker News Reader

If a hacker gets access to a server holding the binaries for an open source app (which most people download), the hacker can just compile the program from sources and add his own code in there and place the installer online.

Code signing is used to prevent this. So, either the attacker has an Apple developer account (and is hopefully traceable through their credit card information), the Transmission project was sloppy with their signing key, or the machine of the developer with the signing key was compromised.

People have been ranting negatively about the Mac App store. But this is exactly why we need sandboxed applications by default (which is what the Mac App Store enforces). A sandboxed application cannot take your data hostage.

(Yes, I understand that App Store distribution is probably not possible for a Bittorrent Client.)

View on HN

So, either the attacker has an Apple developer account (and is hopefully traceable through their credit card information), the Transmission project was sloppy with their signing key, or the machine of the developer with the signing key was compromised.

Sorry, I forgot another possibility: some other developer's key was compromised.

Or, as is the case here, the malicious party was simply issued a key by Apple (for apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple (for free) and use it to digitally sign their apps, the purpose being that Apple can revoke it after the fact if it turns out to be malware):

“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”

From: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...

Interesting. It seems that this is actually a legitimate company:

http://www.bloomberg.com/research/stocks/private/snapshot.as...

So, it could be that the malicious part was not issued a key, but stole the key from this company.

OK so let's imagine sandboxing is on by default, then "Transmission" pushes an update that asks for read/write access to the whole home directory. You don't know if Transmission has some legitimate need for that or not, so you just shrug and click Allow. Boom—infected.

So I think sandboxing is basically useless against these kinds of attacks. Either they allow apps to elevate their entitlements in an update, or they don't and developers will always out-out from the start (or pick the widest set of entitlements available).

If sandboxing is forced with no opt-out, then users will have to jailbreak their computers so they can install Parallels...

then "Transmission" pushes an update that asks for read/write access to the whole home directory.

There is no such entitlement:

https://developer.apple.com/library/mac/documentation/Miscel...

If you are talking about the 'open directory' dialog. Well, if a user is careless enough to just give a sandboxed app access to their complete home directory - tough luck.

So I think sandboxing is basically useless against these kinds of attacks.

No, it's not, because no entitlement allows blanket access to the user's home directory. Hence, an application cannot just encrypt all of the user's data.

Reply on news.ycombinator.com