10 ms·

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizati

by cs702 13y ago

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizations, and individuals around the planet who need to safeguard their private or confidential information now have reason to mistrust proprietary (unauditable) software and hardware. Free, open software and hardware are less likely to have secret 'back doors' installed or embedded in them because their innards are under constant public review by multiple eyes -- out in the open, not behind closed doors. -- Edit: added last sentence.

astrodust 13y ago
Mistrust of commercial solutions does not translate into trust for open-source ones. Have you audited the crypto code of all your packages? Would you even know how?
- Zigurd 13y ago
  Which would you trust more?
- acqq 13y ago
  Exactly. Even more interesting, all of the source code can be OK and just some subtle configuration tweaks can be enough to compromise you. Or just some build flag that you don't even see in sources. Often you don't know the build flags of every binary as soon as you use binaries. You also don't know if the compiler is tweaked to do some preprocessing you don't know about (see Reflections on Trusting Trust by Ken Thompson): http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html For security conscious the prefect state is the OS which changes very, very slowly, fixing only security bugs and having binaries used by as many people as possible and which change so seldom that more people can even check them by disassembling them. You don't want to only check sources, you want to disassemble the binaries and decide if they match the sources. And only then you want to be sure that all configurations are what they should be. Not easy at all.
  - dllthomas 13y ago
    You can (which is not, necessarily, to say do) know if the compiler is tweaked: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust This only works if you are building things yourself or trust the group building things, of course, but it's way easier than audit by disassembling binaries.
    - flyinRyan 13y ago
      How does this deal with [1]? Also, how do you know that your disassembler isn't compromised? [1] http://programmers.stackexchange.com/questions/184874/is-ken-thompsons-compiler-hack-still-a-threat http://programmers.stackexchange.com/questions/184874/is-ken...
      - acqq 13y ago
        Disassemblers produce assembly code, not the HLL code, so they are many orders of magnitude easier to write from the scratch than modern compilers. They typically expect human involvement as soon as there's non-trivial assembly-level engineered self-modifying code. Hopefully there's no much of such code in the results of the compilers we use. Also if you check the whole discussion you'll see I already discussed Ken's work.
        flyinRyan 13y ago
        Ok, I appreciate this information (and I'm trying to follow the discussion but I didn't see you talking of Ken's work). But I'm still curious; even though you can write the disassembler by hand, how can you be sure that you're compiling it with a non-compromised compiler? Or do you mean write it in e.g. ELF format directly (and that's assuming the OS isn't involved in filtering offending code, though it seems extraordinarily unlikely that the OS could be generally modified in such away without detection)?
        dllthomas 13y ago
        The more general and diverse the tools you use, the less likely they are all compromised in the same way, and the more likely any compromise will show up in other contexts. Using tools at different meta-levels may also be worthwhile (machine-code vs. interpreter).
- ChrisAntaki 13y ago
  There are many developers who like audit small pieces, and then share their findings.
  - acqq 13y ago
    Just believing "somebody would see it" is provably not enough. http://www.schneier.com/blog/archives/2008/05/random_number_b.html http://www.schneier.com/blog/archives/2008/05/random_number_... The bug was introduced in September 2006. Discovery published May 2008. Affected: the most popular Linux distribution, all the keys generated on it in that period. Scary. Moreover, the bug was not found by reading the source code. The keys generated by all the existing system were analyzed. If I remember, only the keys generated by mentioned Linux distros stood out (and some hardware devices using customized firmware or poor implementations). Windows and OSX weren't there.
    - dllthomas 13y ago
      But the odds it will be found (and publicly acknowledged) is higher than with closed-source software. Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.
      - acqq 13y ago
        The mentioned bug was not discovered by reading sources. The sources were available for one and half years and were used for the most popular Linux distributions. What can we expect for less popular ones then? I'm not saying that it's better to have closed source, even if we can discuss that too when we consider how often the changes are introduced (for security: the less often the better provided the start is good enough) I'm saying that just believing something is secure simply because "it's open source" is pure hand waving.
        dllthomas 13y ago
        Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.
- Arnor 13y ago
  I for one have not done so and would not know how. However, I'd like to so hopefully some wise hacker will respond with recommendations here. IMHO the best thing that could come out of the Snowden leaks is a rallying cry for an explosion of crypto/privacy advances in the FOSS community.
- deleted 13y ago
  [deleted]
- jokoon 13y ago
  > Mistrust of commercial solutions does not translate into trust for open-source ones. Well, how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. The fact that proprietary agrees with a sound market economy makes it somehow more functional and more attractive, but when you're concerned about ethics, it's a totally other concern.
  - acqq 13y ago
    how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself. And you'd have to verify the compiler and your disassembler that way too. It's all possible, but requires more than it's currently being done, at least on the level of the stuff openly available. And even if you manage to verify everything you have to check the computer. Modern computers be it servers or notebooks start to have BIOS-es that can even phone home and allow remote access without your control (having the keys which you can't control!).
    - dllthomas 13y ago
      "Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double compiling: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust
      - acqq 13y ago
        Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched? Please a specific example of what would be needed to prove GCC and LLVM now. EDIT: I'm not interested in toy compiler and theoretical pie-in-the-sky examples, I want to know how practical it is for the systems in real use. GCC and LLVM as they are now please. If the proposition is "suppose that we have something that can compile gcc sources and we trust it" tell me what is that, does it exist and how hard would it be to make it. Don't talk to me about your experiment where you change one line in TTC and then prove it's changed by comparing the binaries.
- snambi 13y ago
  Most people don't. But if the need the need comes, it can be done. It may need some effort, but can be done. Can you audit microsoft code?
  - joshSimms 13y ago
    True, you cannot audit msft code. Have you checked on the size of the linux kernel lately? Yes I could audit the source, but in reality only a select few will have deep knowledge of only small parts of the code
- dllthomas 13y ago
  Paying someone to audit source I have available to me is going to be cheaper / easier than paying 1) the one group that has access to the source to audit it (in which case I still have to trust them), or 2) paying someone to audit binaries through disassembly.
Renaud 13y ago
There is always going to be an issue of trust at some point: the linux code base is public, but almost none of us compile linux and the packages we need to build a complete OS from source. We end-up getting pre-built packages from repositories that are often distributed all around the word. How easy/hard would it be to compromise some packages or some repositories if you are determined enough? You certainly could not compromise a base as large as the number of Windows users, but you could target your efforts on distributions that have key infrastructure roles, like servers, routers, firewalls... Another vector used to compromise free software is to participate in it. Paid agents can actively participate in open source projects and allow clever exploits that could pass as bugs if uncovered.
- snambi 13y ago
  Sure, it is possible. But it is harder, and the possibility of those "patches" getting discovered some randome users are much higher. It is much easier to use proprietary tool like microsoft to spy others.
- mtgx 13y ago
  But at least it's harder to hide it, and at some point you know it's going to be found out. If we found out about the proprietary solutions spying on us, I think we'll find out even sooner about the open source ones.
  - jiggy2011 13y ago
    Security vulnerabilities are found in OSS programs all the time, how do you tell the difference between negligence/incompetence/mistakes and malicious activity?
- marcosdumay 13y ago
  If you have some valuable secret to keep (classified documents, trade secrets, whatever), you'd be stupid if you didn't compile all the software that touch it yourself. "We" get pre-built packages from repositories, but only because "we" don't value our privacy enough.
amanne 13y ago
To me it looks like most of the issue is with storing information in the cloud rather than natively running programs. Is there any indication that software running on the client is at risk? The article goes to great hyperbole but unless you're using Skydrive, I don't see how Office files are at risk with the recent revelations. Not that they aren't, it's just that I didn't see any information that they are. I don't think storing information in the cloud using FOSS software is going to magically protect your information. E.g. How does using Thunderbird to access Gmail afford greater protection than using Outlook to access Gmail?
- marcosdumay 13y ago
  > Is there any indication that software running on the client is at risk? Yes, Microsoft shares all of Windows vunerability with the NSA long before fixing them. > I don't think storing information in the cloud using FOSS software is going to magically protect your information. And you are right, it won't. Anything you send to 3rd party severs is gone. To keep data private, you must keep it at your computers, run only audited FOSS that you compiled with a trusted compiler, encrypt it all the times it goes into a network (even your LAN), and hope that there isn't a firmware or hardware backdoor in your computer.
brudgers 13y ago
It would be grossly unprofessional of the three-letter agencies if they should have failed to run counter-intelligence operations upon the open source communities. Futhermore, given their resources to hire hackers and long history of infiltrating loosely affiliated organizations, it is hard to image that they have struggled to place moles deep within many critical projects. Open source communities have no membership committee or state-funded security apparatus. Contributions are accepted based on trust and trust is established by technical merit. The means the three-letter agencies used against Microsoft and other corporations are not the only strategies they have available. Maybe Linus doesn't have a price. I hope so and I trust him. But regardless of my trust and hope, there is no verification. My trust still acknowledges that no one is scanning Swiss accounts for activity which might be linked to him - and even if there were someone doing so, what would be my basis for trusting them? Again, I'm not saying I don't trust in the integrity of Linus, but it's hard for me to trust everyone contributing to my Linux distro. Patriots and mercenaries can contribute to open-source just as well as anarchists and Samaritans. Microsoft's closed source model required a more transparent method to subvert [more transparent than a black operation]. Subverting open source requires little more than a clever branch and merge with a veneer of social engineering. The fruit is so low hanging that merely singing the Open-Source Internationale, will get one street cred. Anyone who thinks they are immune, isn't. This is state level resources - put a man on the moon and bring down communism scale.
- rfnslyr 13y ago
  Let's just go back to type writers and sending encrypted letters.
  - rorrr2 13y ago
    http://www.bbc.co.uk/news/world-europe-23282308 http://www.bbc.co.uk/news/world-europe-23282308
    - rfnslyr 13y ago
      Very smart. We have reached a tipping point. I honestly do not trust any software anymore. :(
mtgx 13y ago
In times like these I wish Ubuntu wasn't made by a US company. It could've been a huge winner out of this, and they could've played used it to the full extent in their marketing campaigns. I'm not sure they can still do that. At least if the EU countries want to go about "standardizing" around one Linux distro (like China did), they will just pick one, and not have one for each country.
- radio4fan 13y ago
  Canonical are a UK company. Not that that will help much.
- deleted 13y ago
  [deleted]
ianterrell 13y ago
What we need is a Linux Distro co-maintained by the US, China, Iran, Russia, Israel, ...; Abundant resources and mutual distrust should ensure a rather secure OS.

by cs702 13y ago

astrodust 13y ago

Mistrust of commercial solutions does not translate into trust for open-source ones. Have you audited the crypto code of all your packages? Would you even know how?

Zigurd 13y ago
Which would you trust more?
acqq 13y ago
Exactly. Even more interesting, all of the source code can be OK and just some subtle configuration tweaks can be enough to compromise you. Or just some build flag that you don't even see in sources. Often you don't know the build flags of every binary as soon as you use binaries. You also don't know if the compiler is tweaked to do some preprocessing you don't know about (see Reflections on Trusting Trust by Ken Thompson): http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html For security conscious the prefect state is the OS which changes very, very slowly, fixing only security bugs and having binaries used by as many people as possible and which change so seldom that more people can even check them by disassembling them. You don't want to only check sources, you want to disassemble the binaries and decide if they match the sources. And only then you want to be sure that all configurations are what they should be. Not easy at all.
- dllthomas 13y ago
  You can (which is not, necessarily, to say do) know if the compiler is tweaked: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust This only works if you are building things yourself or trust the group building things, of course, but it's way easier than audit by disassembling binaries.
  - flyinRyan 13y ago
    How does this deal with [1]? Also, how do you know that your disassembler isn't compromised? [1] http://programmers.stackexchange.com/questions/184874/is-ken-thompsons-compiler-hack-still-a-threat http://programmers.stackexchange.com/questions/184874/is-ken...
    - acqq 13y ago
      Disassemblers produce assembly code, not the HLL code, so they are many orders of magnitude easier to write from the scratch than modern compilers. They typically expect human involvement as soon as there's non-trivial assembly-level engineered self-modifying code. Hopefully there's no much of such code in the results of the compilers we use. Also if you check the whole discussion you'll see I already discussed Ken's work.
      - flyinRyan 13y ago
        Ok, I appreciate this information (and I'm trying to follow the discussion but I didn't see you talking of Ken's work). But I'm still curious; even though you can write the disassembler by hand, how can you be sure that you're compiling it with a non-compromised compiler? Or do you mean write it in e.g. ELF format directly (and that's assuming the OS isn't involved in filtering offending code, though it seems extraordinarily unlikely that the OS could be generally modified in such away without detection)?
        dllthomas 13y ago
        The more general and diverse the tools you use, the less likely they are all compromised in the same way, and the more likely any compromise will show up in other contexts. Using tools at different meta-levels may also be worthwhile (machine-code vs. interpreter).
ChrisAntaki 13y ago
There are many developers who like audit small pieces, and then share their findings.
- acqq 13y ago
  Just believing "somebody would see it" is provably not enough. http://www.schneier.com/blog/archives/2008/05/random_number_b.html http://www.schneier.com/blog/archives/2008/05/random_number_... The bug was introduced in September 2006. Discovery published May 2008. Affected: the most popular Linux distribution, all the keys generated on it in that period. Scary. Moreover, the bug was not found by reading the source code. The keys generated by all the existing system were analyzed. If I remember, only the keys generated by mentioned Linux distros stood out (and some hardware devices using customized firmware or poor implementations). Windows and OSX weren't there.
  - dllthomas 13y ago
    But the odds it will be found (and publicly acknowledged) is higher than with closed-source software. Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.
    - acqq 13y ago
      The mentioned bug was not discovered by reading sources. The sources were available for one and half years and were used for the most popular Linux distributions. What can we expect for less popular ones then? I'm not saying that it's better to have closed source, even if we can discuss that too when we consider how often the changes are introduced (for security: the less often the better provided the start is good enough) I'm saying that just believing something is secure simply because "it's open source" is pure hand waving.
      - dllthomas 13y ago
        Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.
Arnor 13y ago
I for one have not done so and would not know how. However, I'd like to so hopefully some wise hacker will respond with recommendations here. IMHO the best thing that could come out of the Snowden leaks is a rallying cry for an explosion of crypto/privacy advances in the FOSS community.
deleted 13y ago
[deleted]
jokoon 13y ago
> Mistrust of commercial solutions does not translate into trust for open-source ones. Well, how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. The fact that proprietary agrees with a sound market economy makes it somehow more functional and more attractive, but when you're concerned about ethics, it's a totally other concern.
- acqq 13y ago
  how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself. And you'd have to verify the compiler and your disassembler that way too. It's all possible, but requires more than it's currently being done, at least on the level of the stuff openly available. And even if you manage to verify everything you have to check the computer. Modern computers be it servers or notebooks start to have BIOS-es that can even phone home and allow remote access without your control (having the keys which you can't control!).
  - dllthomas 13y ago
    "Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double compiling: http://www.dwheeler.com/trusting-trust http://www.dwheeler.com/trusting-trust
    - acqq 13y ago
      Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched? Please a specific example of what would be needed to prove GCC and LLVM now. EDIT: I'm not interested in toy compiler and theoretical pie-in-the-sky examples, I want to know how practical it is for the systems in real use. GCC and LLVM as they are now please. If the proposition is "suppose that we have something that can compile gcc sources and we trust it" tell me what is that, does it exist and how hard would it be to make it. Don't talk to me about your experiment where you change one line in TTC and then prove it's changed by comparing the binaries.
snambi 13y ago
Most people don't. But if the need the need comes, it can be done. It may need some effort, but can be done. Can you audit microsoft code?
- joshSimms 13y ago
  True, you cannot audit msft code. Have you checked on the size of the linux kernel lately? Yes I could audit the source, but in reality only a select few will have deep knowledge of only small parts of the code
dllthomas 13y ago
Paying someone to audit source I have available to me is going to be cheaper / easier than paying 1) the one group that has access to the source to audit it (in which case I still have to trust them), or 2) paying someone to audit binaries through disassembly.

Renaud 13y ago

There is always going to be an issue of trust at some point: the linux code base is public, but almost none of us compile linux and the packages we need to build a complete OS from source. We end-up getting pre-built packages from repositories that are often distributed all around the word. How easy/hard would it be to compromise some packages or some repositories if you are determined enough? You certainly could not compromise a base as large as the number of Windows users, but you could target your efforts on distributions that have key infrastructure roles, like servers, routers, firewalls... Another vector used to compromise free software is to participate in it. Paid agents can actively participate in open source projects and allow clever exploits that could pass as bugs if uncovered.

snambi 13y ago
Sure, it is possible. But it is harder, and the possibility of those "patches" getting discovered some randome users are much higher. It is much easier to use proprietary tool like microsoft to spy others.
mtgx 13y ago
But at least it's harder to hide it, and at some point you know it's going to be found out. If we found out about the proprietary solutions spying on us, I think we'll find out even sooner about the open source ones.
- jiggy2011 13y ago
  Security vulnerabilities are found in OSS programs all the time, how do you tell the difference between negligence/incompetence/mistakes and malicious activity?
marcosdumay 13y ago
If you have some valuable secret to keep (classified documents, trade secrets, whatever), you'd be stupid if you didn't compile all the software that touch it yourself. "We" get pre-built packages from repositories, but only because "we" don't value our privacy enough.

amanne 13y ago

To me it looks like most of the issue is with storing information in the cloud rather than natively running programs. Is there any indication that software running on the client is at risk? The article goes to great hyperbole but unless you're using Skydrive, I don't see how Office files are at risk with the recent revelations. Not that they aren't, it's just that I didn't see any information that they are. I don't think storing information in the cloud using FOSS software is going to magically protect your information. E.g. How does using Thunderbird to access Gmail afford greater protection than using Outlook to access Gmail?

marcosdumay 13y ago
> Is there any indication that software running on the client is at risk? Yes, Microsoft shares all of Windows vunerability with the NSA long before fixing them. > I don't think storing information in the cloud using FOSS software is going to magically protect your information. And you are right, it won't. Anything you send to 3rd party severs is gone. To keep data private, you must keep it at your computers, run only audited FOSS that you compiled with a trusted compiler, encrypt it all the times it goes into a network (even your LAN), and hope that there isn't a firmware or hardware backdoor in your computer.

brudgers 13y ago

It would be grossly unprofessional of the three-letter agencies if they should have failed to run counter-intelligence operations upon the open source communities. Futhermore, given their resources to hire hackers and long history of infiltrating loosely affiliated organizations, it is hard to image that they have struggled to place moles deep within many critical projects. Open source communities have no membership committee or state-funded security apparatus. Contributions are accepted based on trust and trust is established by technical merit. The means the three-letter agencies used against Microsoft and other corporations are not the only strategies they have available. Maybe Linus doesn't have a price. I hope so and I trust him. But regardless of my trust and hope, there is no verification. My trust still acknowledges that no one is scanning Swiss accounts for activity which might be linked to him - and even if there were someone doing so, what would be my basis for trusting them? Again, I'm not saying I don't trust in the integrity of Linus, but it's hard for me to trust everyone contributing to my Linux distro. Patriots and mercenaries can contribute to open-source just as well as anarchists and Samaritans. Microsoft's closed source model required a more transparent method to subvert [more transparent than a black operation]. Subverting open source requires little more than a clever branch and merge with a veneer of social engineering. The fruit is so low hanging that merely singing the Open-Source Internationale, will get one street cred. Anyone who thinks they are immune, isn't. This is state level resources - put a man on the moon and bring down communism scale.

rfnslyr 13y ago
Let's just go back to type writers and sending encrypted letters.
- rorrr2 13y ago
  http://www.bbc.co.uk/news/world-europe-23282308 http://www.bbc.co.uk/news/world-europe-23282308
  - rfnslyr 13y ago
    Very smart. We have reached a tipping point. I honestly do not trust any software anymore. :(

mtgx 13y ago

In times like these I wish Ubuntu wasn't made by a US company. It could've been a huge winner out of this, and they could've played used it to the full extent in their marketing campaigns. I'm not sure they can still do that. At least if the EU countries want to go about "standardizing" around one Linux distro (like China did), they will just pick one, and not have one for each country.

radio4fan 13y ago
Canonical are a UK company. Not that that will help much.
deleted 13y ago
[deleted]

ianterrell 13y ago

What we need is a Linux Distro co-maintained by the US, China, Iran, Russia, Israel, ...; Abundant resources and mutual distrust should ensure a rather secure OS.