Hacker News Reader

Comment by justsaysmthng | Hacker News Reader

I've become increasingly paranoid lately, given that things like these happen and major bugs are uncovered in software that I use almost every day.

It's good that the Transmission developer reacted quickly and made waves so that people can at least be aware that they might have been exposed..

But I wonder how many more applications from the hundreds that I have installed on my machines contain weird stuff - either intentional (for money) or unintentionally (result of a hack).

Open source software is especially vulnerable to this kind of stuff.

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.

Given that many big governments are now involved in the information wars, this scenario is quite likely.

View on HN

"Open source software is especially vulnerable to this kind of stuff."

I'm not sure I follow on this front. Proprietary software could be compromised (whether intentionally by the vendor or unintentionally by some outsider working on the software) effectively forever with no one noticing. At least with OSS, the number of eyes on the source makes it less likely that an exploit will exist for long (though the definition of "long" could vary wildly dependent on popularity and the skill level of the software's normal users).

"Given that many big governments are now involved in the information wars, this scenario is quite likely."

Again, this one seems to point more to proprietary software then OSS. A government only needs to compromise a single company to make an exploit happen in commercial software. OSS exploits can be caught by the Linux distribution vendors that package the software, the users, the developers themselves (who are often working at different companies and in different nations), etc.

So, it may seem easier to compromise an OSS project, by attacking the distribution server and uploading a compromised binary built from source with patches...but, there are many good ways to guard against that (though any single mitigation, like signing with developer keys, can be compromised, the more eyes the less likely it is to succeed for long). But, if a government compromises a company, or someone within that company, all bets are off, and the problem literally may never be found.

I was thinking more about the users on Macs and Windows who use open source software..

The risk is not in the sources, but in the server which hosts the installers. A hacker could just build the software from sources (adding his backdoor) and replace the original installers with his own.

..and the same is true for closed source software. Replacing installers and patching binaries isn't difficult.

> "Open source software is especially vulnerable to this kind of stuff."

I am sorry, what? Why would open source contain more bugs/hacks than closed source specifically? It is more often in the news for few reasons, including that many projects are widely used. However it's against any PR from companies to have their security issues disclosed like they are in open source so they try to minimize the exposure. See [1]

[1] http://www.techrepublic.com/article/open-source-vs-proprieta...

Not because of the fact that it's open source, but because of the distribution models used.

SourceForge has been linked to bundled malware and hijacked projects like GIMP and FileZilla.

I don't follow, what does it matter for the "distribution model" if the software is open- or closed-source? The problem with SourceForge were its malware-riddled installers, how would it be any better if the downloads were proprietary software?

The risk is not in the software itself, but in the server which hosts the installers. A hacker could just build the software from sources (adding his backdoor) and replace the original installers with his own, if the server is not properly secured.

The risk is exactly the same with proprietary software. A hacker can unpack the installer and create a new one with his changes. Or, as they often do, create a wrapper which installs their malware and then calls into the original unmodified installer.

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

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.

> Open source software is especially vulnerable ... the hacker can just compile the program from sources and add his own code

You must be too young to remember how computer viruses originally spread by way of modified executable files: http://computervirus.uw.hu/ch04lev1sec2.html

Actually, dabbling in virus writing was the most exciting thing I could do on my 4.77Mhz 8086 running MSDOS 3.3 back in the day :).

Patching is possible, but why bother when you can compile the app from sources?

Nice book btw.

> but why bother when you can compile the app from sources?

Well, imagine that you are the attacker here. Would you rather keep your malware source in sync with the upstream code and build every target every update, or just use an off the shelf binary wrapper. Would you answer the same if you were targeting more than one app (in the case of a CDN attack)?

The only scenario in which source level malware makes sense to me is this: you are targeting a specific application and you are able to get your code into the project's SCM. In this scenario OSS is no more vulnerable than closed source.

It's trivial to do this with closed source applications as well.

Reproducible builds might be a possible solution to this (as long as we can verify the integrity of the checksum): https://wiki.debian.org/ReproducibleBuilds

> Open source software is especially vulnerable to this kind > of stuff.

Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?

Open Source software has existed for more than 2 or 3 years, you know.

All software is vulnerable to bad actors writing malicious code. What makes it any safer if its proprietary software? In any case, in a pessimistic scenario you'd have to change your sentence to "give it 2 or 3 years and stories will come trickling about how ALL apps, open or closed source, were tampered with by hackers, the government, etc".

> > Open source software is especially vulnerable to this kind > of stuff.

> Give it 2 or 3 years and stories will come trickling out about how most OS apps have had commits from hackers, governments etc. So far most source checking - to the extent that it happens at all - is all about buffer overruns and the like; micro stuff that's easily catchable. Well, you say that, but, you know, heartbleed etc. But what about whole modules designed with two purposes in mind?

Free Software has existed for over 20 years. Not to mention the fact that the same problem you describe is far more trivial for proprietary software. There's no straightforward way to find out if it's backdoored (although, luckily quite a few backdoors are done badly so we can find out). The point is that if you assume that all free software is compromised, you have to assume all proprietary software is compromised. I'd prefer to have some free software be compromised because then I'm not at the mercy of the vendor to fix it.

It's a risk inherit in using any software you didn't write.

Reply on news.ycombinator.com