Some background information
Three days ago, someone published the CVE-2016-4484, about, let's quote them:
A vulnerability in Cryptsetup, concretely in the scripts that unlock the system partition when the partition is ciphered using LUKS (Linux Unified Key Setup).
This vulnerability allows to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it doesn't depend on specific systems or configurations. Attackers can copy, modify or destroy the hard dis[k] as well as set up the network to exflitrate data. This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect[ed] (password in BIOS and GRUB) and we only have a keyboard or/and a mouse.
Let's take a few moments to analyze this information and those claims.
Vulnerability in Cryptsetup (?)
First and foremost,
cryptsetup(8) has nothing to do with the pretended
issue. While this is corrected in the rest of that sentence, The first four
words are completely and utterly wrong; they have strictly no use but spreading
lies and FUD on a
very respected and respectable FOSS project.
This even caused some online newspaper to write that there is a security flaw in cryptsetup. The same magazine even wrote that the exploit (emphasis mine):
[...] grants the hacker a shell with root privileges, which allows them to gain complete remote control over encrypted Linux machine.
More FUD. Of course this is (unless I'm proved wrong - but I honestly can't see how with the disclosed information) utterly incorrect. The only thing that this so called "exploit" is giving is a root shell, also known as rescue shell. It is not a bug, but an intended feature. More on that rescue shell later.
According to the report:
Attackers can copy, modify, destroy the hard dis[k] as well as setup the network to exfiltrate data.
Well, that is assuming they can reach the point that this article reports as reachable. But even if so, it is the same consequence as having an "attacker" boot their own bootable USB key and temper with the system. This is hardly news.
It can be a problem, however, if this is exploitable to bypass some intended restriction (BIOS password, GRUB password, etc.)
Which leads us to...
Again, according to the report:
This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect[ed] (password in BIOS and GRUB) and we only have a keyboard or/and a mouse.
Oh, really, now? To trigger the beavior described as harmful, a potential "attacker" needs to reach the point when the hard drive decryption happens, when the passphrase is prompted for. This happens exactly before the system starts booting (because it is technically needed to boot) and after any BIOS password prompt. I would guess that any security implemtented in the bootloader would be bootloader-implementation-dependent (in other words, unrelated - and shall be, if problematic, the subject of a separate bug report, or even a CVE if judged serious enough in terms of security implications).
What I can say is:
- If there is a BIOS password, this will trigger way before the initramfs kicks in.
- If there is a bootloader password (which is not really a security feature, as it is extremely trivial to bypass), it should trigger before the hard drive encryption passphrase is prompted for.
- There is no way I can think of for a potential attacker to bypass any of those restrictions via the behavior reported in the CVE I'm currently commenting on.
In other terms: the reported behavior is intended, is a feature, and is useful.
Now, a CVE of that kind wouldn't be complete without its fair share of buzzwords.
Here we go:
[...] in cloud environments it is also possible to remotely exploit this vulnerability without having "physical access."
True. That is, if you have access to the complete virutal machine management console, which includes various options, such as "destroying the machine", "destroying the drive", and so forth. If the attacker has access to that management console, you've got yourself other, much more worrisome issues.
But then, is there a real issue, at all?
Well, not one that you should be concerned of, no.
But there is a bug indeed; and those two persons who opened this CVE and spammed the infosec world so much with so little material should indeed have filed a bug report. Not a CVE, however. CVE are for security issues, not intended, secured rescue systems.
The real bug
The bug, for those who are interested, is that when the number of tries is equal
to the maximum number of tries (i.e.
$crypttries have the same
value), both check fail, resulting into an undefined behavior. What was
intended instead was for the rescue shell to drop.
The real fix
And all is required for that to be fixed is to change the
scripts/local-top/cryptroot line 355 to
$crypttries. As you can see, the change is trivial: it is about checking if
the count is greater or equal to the allowed number of tries rather than
Some more comments on the report
Their fix essentially fixes the problem in a much similar fashion as my fix above, but in a very inelegant way (introducing an unnecessary variable), and in addition, steps into an infinite loop that continuously sleep:
while true; do sleep 100 done
One can only wonder about the relevance of that code, since looping infinitely doesn't require a specific amount of time (one minute and fourty seconds is a very odd and unexpected amount of time to wait for, infinitely); or since the waiting will obviously be interrupted sooner than later by the user (AKA attacker) "forcing an unexpected reboot".
In the event of replacing that
return 1 by something else, why not wait and
ask for the passphrase again, infinitely? This is what is going to happen
anyway, if the user reboots.
Phrasing and spelling
I am not going to say much about the phrasing and spelling of that report, because it is of very little relevance to the problem; and also because it is more of an ad-hominem argument than an objective, technically valid one.
But I will say this: I expect CVE reports and other security reports to be proofread, or at the very minimum re-read by the person who submits them.
This root shell does drop whenever the bootloader fails to mount the root volume, to allow the user to try to manually mount the root volume as a last, desperate attempt to boot. It is not only wishable, but highly desired, and saved me from having to reformat my USB thumb with a rescue ISO more than a couple of times.
The report also states, ironically enough; that:
[There is a] panic function, which is the one that launches the shell, [that] can prevent console access if the kernel is booted with the "panic" parameter.
This shows that while they saw that the behavior they report is a feature, secure, configured adequately, trivial to restrict if so needed; while they saw that it is intended, they decided to ignore it, for what I can only assume to be wanting their fifteen minutes of fame...