View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006660||Kali Linux||General Bug||public||2020-08-17 17:16||2020-12-01 10:48|
|Summary||0006660: Updates prevented by apt hash mismatch (VirtualBox)|
In Kali 2020.2a, running in VirtualBox (installed via the official VB appliance, which was also verified by hash after download), running
It appears that the update server tells Kali to expect a
|Steps To Reproduce|
Install Kali Linux in VirtualBox (currently 2020.2a and 6.1.12 r139181, respectively) via the OVA file available from the official Kali download page.
Start the VM, log in, and run
Observe error message regarding hash mismatch.
apt error message:
Note that the weaker MD5 sums do indeed match, while both SHA-based sums do not.
You most likely have a IDS or IPS system in place which may be affecting the hash values after it intercepts the traffic if you try this:
sudo nano /etc/apt/sources.list
change this line:
Okay, now it looks different. After changing to the HTTPS protocol as @iiamloz suggested, none of the sums match (not even MD5, which did previously), and the error persists.
It's worth noting that I am currently on a university network, although this issue first appeared on private, secure home WiFi.
New error message:
Get:1 https://kali.download/kali kali-rolling InRelease [30.5 kB]
Note that HTTPS is now being used, as expected.
You can try this, it worked for me
Because apt use sha256 method from libgcrypto20, but optimized too much. We can deny this opt.
$ sudo bash
echo all >> /etc/gcrypt/hwf.deny
After the code just run apt-get update it should work
Thank you, that did indeed fix the issue.
However, since the hash problem occurs immediately with a default VirtualBox install, shouldn't this fix be implemented by default?
Oh it definetly should, took a while to find the solution.
All right, another update on the issue. After your modifications (and while still using HTTPS),
What is your host system? Is there any antivirus running?
The workaround above disables hardware optimizations in gcrypt, nothing else.
I'm on Windows 10, build 1909 (as up-to-date as I can be at the moment). I have Windows Defender enabled, and the free version of Malwarebytes installed. (Note that the latter cannot monitor proactively, however.)
As noted previously, I'm also on a university network for the moment, although this issue first appeared on a private, secure home network, with Kali 2020.1.
A friend of mine just installed Kali in VirtualBox on a Macbook, and was able to run
@Kunkaa Where/how did you find this solution?
It's either a bug if libgcrypt or (more likely) a bug in virtualbox badly virtualizing some hardware feature to compute checksums. It's nice to have a work around but this should really be fixed where it's broken, aka likely in virtualbox itself.
I have not found any related bug report in https://www.virtualbox.org/report/10
The closest I found is this one: https://www.virtualbox.org/ticket/19695
One of those who can reproduce the issue should file a bug report there... see https://www.virtualbox.org/wiki/Bugtracker
All right, I'll file a report with VirtualBox. Also, it would be nice to test another linux distro in a VM to verify this - I'll look around and see if I can find a Ubuntu appliance or something similar.
Relatedly, how does one close an issue here?
After a rather long lapse, I have another update. There was an existing VirtualBox ticket for this (https://www.virtualbox.org/ticket/19695), and it appears the issue will be fixed when a VirtualBox version above r140284 is released.
I don't see a way to mark this issue as closed, so I'll just leave it for now -- if a moderator (or someone else) with this ability sees this, feel free to close this ticket.
Also, thank you to everyone who contributed above! As this is my first Kali bug report, I'm grateful for the assistance.
We will keep this bug open until we import virtualbox 6.1.15 (once released).
I'm happy to announce that a post to a Kali Forum topic related to this issue has contributed to its resolution! (Original post https://forums.kali.org/showthread.php?48809-Kali-2020-2-OVA-(VirtualBox)-setup-errors&p=99519#post99519)
Solution (for Windows):
After rebooting my actual computer twice, VirtualBox no longer showed the turtle variant of its virtual CPU icon (which it did previously, and began doing so near the time when this issue appeared for me), and
Okay, yet another update. I just received an update to Windows 10 version 2004, which enables WSL 2. Unfortunately, WSL 2 requires that the "Virtual Machine Platform" Windows feature be enabled, which causes VirtualBox to return to its slow virtualization mode (with the turtle vCPU icon). For users who need both VirtualBox and WSL, I feel this issue would be best resolved with a VirtualBox setting to select the virtualization mode (if that's even possible).
virtualbox version 6.1.16 is now in kali-rolling
|2020-08-17 17:16||LRitzdorf||New Issue|
|2020-08-18 15:08||iiamloz||Note Added: 0013288|
|2020-08-18 19:48||LRitzdorf||Note Added: 0013290|
|2020-08-19 15:00||Kunkaa||Note Added: 0013291|
|2020-08-19 15:14||Kunkaa||Note Added: 0013292|
|2020-08-19 16:32||LRitzdorf||Note Added: 0013293|
|2020-08-19 16:58||Kunkaa||Note Added: 0013294|
|2020-08-19 17:37||LRitzdorf||Note Added: 0013295|
|2020-08-19 17:42||steev||Note Added: 0013296|
|2020-08-19 19:16||LRitzdorf||Note Added: 0013297|
|2020-08-21 04:04||LRitzdorf||Note Added: 0013300|
|2020-08-26 12:11||rhertzog||Note Added: 0013324|
|2020-08-27 04:43||LRitzdorf||Note Added: 0013331|
|2020-09-25 04:14||LRitzdorf||Note Added: 0013486|
|2020-09-25 06:26||rhertzog||Note Added: 0013487|
|2020-09-25 06:52||Kunkaa||Note Added: 0013488|
|2020-09-25 06:55||sbrun||Assigned To||=> sbrun|
|2020-09-25 06:55||sbrun||Status||new => assigned|
|2020-10-24 22:26||LRitzdorf||Note Added: 0013589|
|2020-10-28 06:43||LRitzdorf||Note Added: 0013596|
|2020-10-29 16:00||sbrun||Status||assigned => resolved|
|2020-10-29 16:00||sbrun||Resolution||open => fixed|
|2020-10-29 16:00||sbrun||Note Added: 0013601|
|2020-12-01 10:48||g0tmi1k||Priority||immediate => normal|