According to this there are compelling reasons for caution when installing obfuscated binaries. Knowing this, how can running binary blobs as a part of the Linux kernel be acceptable from a security point of view? There exists a blob-free version of the kernel. The motivations behind that project seem to be primarily ideological. But what kind of risks do users of non-free driver modules actually face? Can a binary blob contain a rootkit designed to take over or open a backdoor into the entire system? How could such a backdoor be detected?
3 Answers
- From a security, and even ideological, point of view; blobs are unacceptable.
whatever people say, they are trying to dissuade you from the importance of this issue. - the risks users of non-free software face, be it a firmware blob, driver blob, or Microsoft Windows, are vastly unmeasurable. and while it is safer using any Linux distro than Windows, it doesn't mean that any Linux distro is secure.
- blobs, depending on their size, can do just about anything, they are little programs after all.
- as for detecting backdoors and other security flaws, there is only one way, and it is quite simple;
publish the source code. the previous answer points out that:
"A binary will be much faster than other code." Liar, Liar, Pants on Fire.
a blob will only make the final compiling process of the program faster, not the program itself,
but regardless of program performance decisions,
there's no reason not to publish the source, and compiling instructions of that "blob"
and anyone telling you otherwise is either lying, of some kind of NSA, FBI agent.
if you are interested in a 100% FOSS (free and open source) operating systems,
that consciously maintain their code to be blob free, here is a link: Free GNU/Linux distributions
other relevant links:
What is free software?,
techrights.org/2013/11/25/freedo-and-nsa-code/
.
![](../../users/profiles/35041.webp)
- 112
- 1
- 2
-
-1 Blobs are not necessarily bad, depending on their purpose. For example to run firmware on an NIC, or more importantly, to insert microcode. Without microcode updates (which do count as "blobs", despite not _running_ in the kernel), you may be using a system with highly vulnerable hardware. You are also incorrect wrt #4, as you can do reverse engineering and black box analysis on various blobs to understand how they work. I do agree on the philosophical points though. – forest Dec 31 '17 at 02:02
-
2I re-read this and noticed that #3 is also incorrect. There are plenty of blobs which are _not_ executable, for example configuration blobs such as for GbE, or various ACPI tables which lack executable code (only DSDT and SSDT contain actual code). – forest Nov 01 '18 at 07:38
Binary blobs in the Linux kernel are primarily firmware for peripheral devices.
Many peripheral devices - e.g. Wi-Fi cards are notorious for this - have processors inside them. Those processors run code. The code has to come from somewhere. It comes from the driver.
Your Wi-Fi card simply will not work unless the Wi-Fi driver copies firmware into the Wi-Fi card's memory and starts it running.
Usually, the manufacturer of the Wi-Fi card gives out copies of the firmware and says "here is the firmware you need. Your driver should install it using these instructions."
The main risk is that we don't know what's in that firmware. It runs on the Wi-Fi card's processor, so there is usually no risk to the rest of the machine, except for DMA attacks. However, it could see all your Wi-Fi traffic and phone home, if it wanted. We can't tell since we don't have the source code.
Regarding DMA attacks: Many peripherals have the ability to directly write data into the computer's main memory. This is useful because the CPU doesn't have to waste time shuffling data around. But it also means that if the peripheral was malicious, it could overwrite something important, like kernel code, and then install a rootkit. Some computers have a facility called an IOMMU, which prevents this by limiting which addresses can be accessed by peripherals, the same way a regular MMU limits which addresses can be accessed by non-kernel programs.
![](../../users/profiles/40059.webp)
- 3,885
- 3
- 19
- 15
The main reason they incorporate binaries is for speed. A binary will be much faster than other code, so it's handy since it's so deeply built in to the kernel especially.
How can this be acceptable? Because it is assumed that they were not made with malicious intent. If you are truly worried about this, you can compile the kernel from scratch yourself so you can vet the code that goes into these binaries yourself. The second part is making sure that they havent changed to something thats unknown.
By non-free driver modules I assume you mean something purchased for use on the system. They are exactly the same amount of security as anything proprietary. Meaning that you don't know what's inside them and so if you trust the manufacturer of the software then great! let's hope they didn't feel malicious before they compiled down to binary.
Could a binary be designed to rootkit a system? Absolutely!! This is the same point I just made. Even a seemingly harmless binary could have a replica made that did the same thing and also was a rootkit.
How could such a backdoor be detected? Several ways. The best answer is file integrity monitoring. Even something that takes a simple MD5 or another simple one way hash of simple locations like /etc or just each of the binary files to make sure that someone hasn't changed them. And of course the usual suspects like antivirus, antispyware, and a good firewall.
![](../../users/profiles/27011.webp)
- 296
- 1
- 11
-
2There are firmware drivers included with most Linux distros, although Linus' doesn't like closed-source kernel modules[1] 1. http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html – Reed G. Law Jun 14 '13 at 06:00
-
Though there are firmware drivers. Is anything I said not accurate? they certainly dont leave everything in it's source code, why else can you compile a kernel? – PsychoData Jul 09 '13 at 06:30
-
2The source code for these drivers is not open source so you can't vet the code as you suggested above. These binary blobs are used to get things like wifi cards running. They are mysterious black boxes, but presumably unmodifyable and so equivalent to a circuit in some people's minds. – Reed G. Law Jul 09 '13 at 11:58
-
well thats something different. Lots of the binary blobs are going to be things that are part of the base operating system. and of course there are going to be binary drivers too. If you dont like it, go find one thats open source, write your own (good luck), or dont use the closed source hardware. It's not that linux is evil because not everyone released their source, you are just trusting the manufacturer (AMD, Intel, broadcom......blah blah blah) that they didnt put stuff in there. In fact IF they released open source code for those drivers someone could modify the driver to also rootkit. – PsychoData Jul 12 '13 at 17:45