7 ms·

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 t

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.

kpcyrd 11y ago
It's trivial to do this with closed source applications as well.
franciscop 11y ago
> "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-proprietary/ http://www.techrepublic.com/article/open-source-vs-proprieta...
- bluedino 11y ago
  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.
  - the_af 11y ago
    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?
- justsaysmthng 11y ago
  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.
  - cesarb 11y ago
    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.
danieldk 11y ago
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.)
- danieldk 11y ago
  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.
  - arm 11y ago
    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-ransomware-keranger-infected-transmission-bittorrent-client-installer/ http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
SwellJoe 11y ago
"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.
- deleted 11y ago
  [deleted]
- justsaysmthng 11y ago
  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.
  - snom380 11y ago
    ..and the same is true for closed source software. Replacing installers and patching binaries isn't difficult.
woodman 11y ago
> 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 http://computervirus.uw.hu/ch04lev1sec2.html
- justsaysmthng 11y ago
  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.
  - woodman 11y ago
    > 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.
dave2000 11y ago
> 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?
- the_af 11y ago
  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".
- cyphar 11y ago
  > > 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.
godzillabrennus 11y ago
It's a risk inherit in using any software you didn't write.
cooper12 11y ago
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 https://wiki.debian.org/ReproducibleBuilds

kpcyrd 11y ago

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

franciscop 11y ago

> "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-proprietary/ http://www.techrepublic.com/article/open-source-vs-proprieta...

bluedino 11y ago
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.
- the_af 11y ago
  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?
justsaysmthng 11y ago
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.
- cesarb 11y ago
  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.

danieldk 11y ago

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

danieldk 11y ago
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.
- arm 11y ago
  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-ransomware-keranger-infected-transmission-bittorrent-client-installer/ http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...

SwellJoe 11y ago

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

deleted 11y ago
[deleted]
justsaysmthng 11y ago
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.
- snom380 11y ago
  ..and the same is true for closed source software. Replacing installers and patching binaries isn't difficult.

woodman 11y ago

> 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 http://computervirus.uw.hu/ch04lev1sec2.html

justsaysmthng 11y ago
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.
- woodman 11y ago
  > 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.

dave2000 11y ago

> 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?

the_af 11y ago
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".
cyphar 11y ago
> > 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.

godzillabrennus 11y ago

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

cooper12 11y ago

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 https://wiki.debian.org/ReproducibleBuilds