Avoid Non-Freedom Software

For system privacy, freedom and security it is strongly advised to not install proprietary ^[archive], non-freedom ^[archive] software. Instead, use of Free Software ^[archive] is recommended ^[archive]. As Free Software pioneer Richard Stallman ^[archive] puts it:

"... If you run a nonfree program on your computer, it denies your freedom; the main one harmed is you. ..."
"Every nonfree program has a lord, a master -- and if you use the program, he is your master.“
"To have the choice between proprietary software packages, is being able to choose your master. Freedom means not having a master. And in the area of computing, freedom means not using proprietary software."

Or as the GNU project ^[archive] puts it ^[1]:

Proprietary Software Is Often Malware ^[archive]
Nonfree (proprietary) software is very often malware (designed to mistreat the user). Nonfree software is controlled by its developers, which puts them in a position of power over the users; that is the basic injustice ^[archive]. The developers and manufacturers often exercise that power to the detriment of the users they ought to serve.
This typically takes the form of malicious functionalities.
Some malicious functionalities are mediated by backdoors.
Backdoor: any feature of a program that enables someone who is not supposed to be in control of the computer where it is installed to send it commands. (Note by editor: "Most times without user awareness or consent.")

The GNU project created a list with examples of Proprietary Backdoors ^[archive]. The Electronic Frontier Foundation ^[archive] (EFF) has other examples of the use of backdoors ^[archive].

Open Source software ^[archive] like Qubes, Linux ^[archive] and Whonix ™ ^[archive] is more secure than closed source ^[archive] software. The public scrutiny of security by design ^[archive] has proven to be superior to security through obscurity ^[archive]. This aligns the software development process with Kerckhoffs' principle ^[archive] - the basis of modern cipher ^[archive]-systems design. This principle asserts that systems must be secure, even if the adversary knows everything about how they work. Generally speaking, Freedom Software projects are much more open and respectful of the privacy rights of users. Freedom Software projects also encourage security bug reports, open discussion, public fixes and review.

Possible risks associated with using non-freedom software:

Vendor lock-in and abandonware: Your data is saved in obfuscated formats that depend on a closed software package. If the company goes out of business or they decide to change the format down the line, you are held hostage to these companies and need to pay up to access it. In contrast, FLOSS (Free/Libre and Open Source Software) uses open, documented file formats and popular abandoned software projects have a much higher chance of finding a new developer.
DRM: Publishing companies treat their customers like thieves and severely limit what they can do with media they purchased.
Malware: Potential advanced malware in the software itself that is not easily reversed or discovered.
Freedom Restrictions and Privacy Invasion: No ability to change or disable undesirable privacy violating features like telemetry because of licensing restrictions and absence of source code. It is extremely rare that anti-features are added by FLOSS developers because it is antithetical to the community culture and easily remedied if discovered by others who can fork the software and fix it.
Privacy Breaches: Proprietary software is notorious for harvesting user data and monetizing it with advertisement networks which themselves have been used as malware delivery networks by malicious customers.
Third Party Dependencies: Software that depends on third party servers could access identifying information for payments or logins linked to real identity.
More defects per line: While FLOSS software isn't automatically security bug free, it objectively has less defects per lines of code compared to proprietary software.^[2]

Even as a non-developer, a user's attention, suggestions and testing is a valuable public service and further strengthens the libre alternatives which will stay available to everyone indefinitely. It is in the user's interest to support FLOSS and decentralization to keep free computing alive and to curtail abusive monopolist practices and influence. Even if the FLOSS package's functionality is lacking in the short-term (this is very rare nowadays with FLOSS leaving proprietary in the dust), these can always be improved, but the drawbacks of proprietary software listed above are intrinsic to their mode of development and is not something that can change for the better.

For more information on installing third-party Libre software ^[archive] consult the Install Software page.

Table: Finding Backdoors in Freedom Software vs Non-Freedom Software

	Non-Freedom Software (precompiled binaries)	Freedom Software (source-available)
Original source code is reviewable	No	Yes
Compiled binary file can be decompiled into disassembly	Yes	Yes
Regular pre-compiled binaries	Depends ^[3]	Yes
Obfuscation ^[archive] (anti-disassembly, anti-debugging, anti-VM) ^[4] is usually not used	Depends ^[5]	Yes ^[6]
Price for security audit searching for backdoors	Very high ^[7]	Lower
Difference between precompiled version and self-compiled version	Unavailable ^[8]	Small or none ^[9]
Reverse-engineering ^[archive] is not required	No	Yes
Assembler language skills required	Much more	Less
Always legal to decompile / reverse-engineer	No ^[10] ^[11]	Yes ^[12]
Possibility of catching backdoors via observing incoming/outgoing Internet connections	Very difficult ^[13]	Very difficult ^[13]
Convenience of spotting backdoors	Lowest convenience ^[14]	Very high convenience ^[15]
Difficulty of spotting "direct" backdoors ^[16] ^[17] ^[18]	Much higher difficulty ^[19]	Much lower difficulty ^[20]
Difficulty of spotting a "bugdoor" ^[21]	Much higher difficulty ^[22]	Lower difficulty
Third parties can legally release a software fork ^[archive], a patched version without the backdoor	No ^[23]	Yes ^[24]
Third parties can potentially make (possibly illegal) modifications like disabling serial key checks ^[25]	Yes	Yes
Software is always modifiable	No ^[26]	Yes
Third parties can use static code analysis tools	No	Yes
Third parties can judge source code quality	No	Yes
Third parties can find logic bugs in the source code	No	Yes
Third parties can find logic bugs in the disassembly	Yes	Yes
Benefits from population-scale scrutiny	No	Yes
Third parties can benefit from debug symbols ^[archive] during analysis	Depends ^[27]	Yes
Display source code intermixed with disassembly	No	Yes ^[28]
Effort to audit subsequent releases	Almost same ^[29]	Usually lower ^[30]
Forum discussion: Finding Backdoors in Freedom Software vs Non-Freedom Software ^[archive]

Spotting backdoors is already very difficult in Freedom Software where the full source code is available to the general public. Spotting backdoors in non-freedom software composed of obfuscated binaries is exponentially more difficult. ^[31] ^[32] ^[33] ^[34] ^[35] ^[36] ^[37] ^[38]

To further improve the situation in the future, the Freedom Software community is working on the Reproducible Builds ^[archive] project. Quote:

Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code.

Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether they correspond.
This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence.
This is particularly a concern for developers collaborating on privacy or security software: attacking these typically result in compromising particularly politically-sensitive targets such as dissidents, journalists and whistleblowers, as well as anyone wishing to communicate securely under a repressive regime.
Whilst individual developers are a natural target, it additionally encourages attacks on build infrastructure as an successful attack would provide access to a large number of downstream computer systems. By modifying the generated binaries here instead of modifying the upstream source code, illicit changes are essentially invisible to its original authors and users alike.
The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny.
This ability to notice if a developer has been compromised then deters such threats or attacks occurring in the first place as any compromise would be quickly detected. This offers comfort to front-liners that they not only can be threatened, but they would not be coerced into exploiting or exposing their colleagues or end-users.

Several free software projects ^[archive] already, or will soon, provide reproducible builds.

Footnotes[edit]

↑ Changed "back door" to "backdoor".
↑ https://www.techrepublic.com/article/open-source-vs-proprietary/ ^[archive]
↑ Some use binary obfuscators.
↑ https://resources.infosecinstitute.com/topic/anti-disassembly-anti-debugging-and-anti-vm/ ^[archive]
↑ Some use obfuscation.
↑ An Open Source application binary could be obfuscated in theory. However, depending on the application and the context -- like not being an Open Source obfuscator -- that would be highly suspicious. An Open Source application using obfuscators would probably be criticized in public, get scrutinized, and lose user trust.
↑
This is because non-freedom software is usually only available as a pre-compiled, possibly obfuscated binary. Using an anti-decompiler:
- Auditors can only look at the disassembly and cannot compare a pre-compiled version from the software vendor with a self-compiled version from source code.
- There is no source code that is well-written, well-commented, and easily readable by design.
↑ Since there is no source code, one cannot self-build one's own binary.
↑
- small: for non-reproducible builds (or reproducible builds with bugs)
- none: for reproducible builds
↑ Decompilation is often expressly forbidden by license agreements of proprietary software.
↑ Skype used DMCA (Digital Millenium Copyright Act) to shut down reverse engineering of Skype ^[archive]
↑ Decompilation is always legal and permitted in the license agreements of Freedom Software.
↑ ^13.0 ^13.1 This is very difficult because most outgoing connections are encrypted by default. At some point the content must be available to the computer in an unencrypted (plain text) format, but accessing that is not trivial. When running a suspected malicious application, local traffic analyzers like Wireshark ^[archive] cannot be trusted. The reason is the malicious application might have compromised the host operating system and be hiding that information from the traffic analyzer or through a backdoor. One possible option might be running the application inside a virtual machine, but many malicious applications actively attempt to detect this configuration. If a virtual machine is identified, they avoid performing malicious activities to avoid being detected. Ultimately this might be possible, but it is still very difficult.
↑ It is necessary to decompile the binary and read "gibberish", or try to catch malicious traffic originating from the software under review. As an example, consider how few people would have decompiled Microsoft Office and kept doing that for every upgrade.
↑
It is possible to:
1. Audit the source code and confirm it is free of backdoors.
2. Compare the precompiled binary with a self-built binary and audit the difference. Ideally, and in future, there will be no difference (thanks to the Reproducible Builds project) or only a small difference (due to non-determinism introduced during compilation, such as timestamps).
↑ An example of a "direct" backdoor is a hardcoded username and password or login key only known by the software vendor. In this circumstance there is no plausible deniability for the software vendor.
↑ List of “direct” backdoors in wikipedia ^[archive].
↑
One interesting “direct” backdoor was this bitcoin copay wallet backdoor:
- If more than 100 BTC, steal it. Otherwise, don’t bother.
- https://www.synopsys.com/blogs/software-security/malicious-dependency-supply-chain/ ^[archive]
- https://github.com/dominictarr/event-stream/issues/116 ^[archive]
- https://github.com/dominictarr/event-stream/issues/116#issuecomment-441759047 ^[archive]
↑ Requires strong disassembly auditing skills.
↑ If for example hardcoded login credentials were in the published source code, that would be easy to spot. If the published source code is different from the actual source code used by the developer to compile the binary, that difference would stand out when comparing pre-compiled binaries from the software vendor with self-compiled binaries by an auditor.
↑ A "bugdoor" is a vulnerability that can be abused to gain unauthorized access. It also provides plausible deniability for the software vendor. See also: Obfuscated C Code Contest ^[archive].
↑ Such issues are hard to spot in the source code, but even harder to spot in the disassembly.
↑ This is forbidden in the license agreement. Due to lack of source code, no serious development is possible.
↑ Since source code is already available under a license that permits software forks and redistribution.
↑ This entry is to differentiate from the concept immediately above. Pre-compiled proprietary software is often modified by third parties for the purposes of privacy, game modifications, and exploitation.
↑ For example, Intel ME could not be disabled in Intel CPUs yet. At the time of writing, a Freedom Software re-implementation of Intel microcode is unavailable.
↑ Some may publish debug symbols.
↑
- objdump ^[archive] with parameter -S / --source
- How does objdump manage to display source code with the -S option? ^[archive]
↑ It is possible to review the disassembly, but that effort is duplicated for subsequent releases. The disassembly is not optimized to change as little as possible or to be easily understood by humans. If the compiled version added new optimizations or compilation flags changed, that creates a much bigger diff ^[archive] of the disassembly.
↑ After the initial audit of a source-available binary, it is possible to follow changes in the source code. To audit any newer releases, an auditor can compare the source code of the initially audited version with the new version. Unless there was a huge code refactoring or complete rewrite, the audit effort for subsequent versions is lower.
↑ The consensus is the assembler low level ^[archive] programming language is more difficult than other higher level abstraction ^[archive] programming languages. Example web search terms: assembler easy, assembler easier, assembler difficult.
↑
Source code written in higher level abstraction programming languages such as C and C++ are compiled to object code ^[archive] using a compiler. See this article ^[archive] for an introduction and this image ^[archive]. Source code written in lower level abstraction programming language assembler is converted to object code using an assembler. See the same article above and this image ^[archive]. Reverse engineering is very difficult for a reasonably complex program that is written in C or C++, where the source code is unavailable; that can be deduced from the high price for it. It is possible to decompile (meaning re-convert) the object code back to C with a decompiler like Boomerang ^[archive]. To put a price tag on it, consider this quote -- Boomerang: Help! I've lost my source code ^[archive]:
How much will it cost? You should expect to pay a significant amount of money for source recovery. The process is a long and intensive one. Depending on individual circumstances, the quality, quantity and size of artifacts, you can expect to pay upwards of US$15,000 per man-month.
- convert executable back to C source code ^[archive]
↑
The following resources try to solve the question of how to disassemble a binary (byte code) into assembly source code and re-assemble (convert) to binary.
1. Take a hello world assembler source code.
2. Assemble.
nasm -felf64 hello.asm
nasm -felf64 hello.asm
3. Link.
ld hello.o -o hello
ld hello.o -o hello
4. objdump (optional).
objdump -d hello
objdump -d hello
5. Exercise for the reader: disassemble hello and re-assemble.
↑
The GNU Hello ^[archive] program source file hello.c ^[archive] at the time of writing contains 170 lines. The objdump -d /usr/bin/hello on Debian buster has 2757 lines.
Install hello.
1. Update the package lists.
sudo apt update
sudo apt update
2. Upgrade the system.
sudo apt full-upgrade
sudo apt full-upgrade
3. Install the hello package.
Using apt command line parameter --no-install-recommends is in most cases optional.
sudo apt install --no-install-recommends hello
sudo apt install --no-install-recommends hello
4. Done.
The procedure of installing hello is complete.
```
objdump -d /usr/bin/hello
```
objdump -d /usr/bin/hello
```
2757
```

↑ For example, consider how difficult it was to reverse engineer Skype: Skype Reverse Engineering : The (long) journey ;).. ^[archive]

↑

Consider all the Debian package maintainer scripts. Clearly these are easier to review as is, since most of them are written in sh or bash. Review would be difficult if these were converted to a program written in C, and were closed source and precompiled.
Similarly, it is far preferable for OnionShare to stay Open Source and written in python, rather than the project being turned into a precompiled binary.

↑ Salary comparison ($K):