Closed dbosanzio closed 6 years ago
does the file /boot/vmlinuz-2.6.18-416.el5PAE actually exist?
If yes, what does file /boot/vmlinuz-2.6.18-416.el5PAE
say?
I'm guessing it might be because you're missing some binaries to extract the kernel, @Alkorin is working on a PR to display a proper error+hint if this is the case.
Can you retry with the latest version (v0.16) ?
I have got the same in /boot/vmlinuz simply gzipped kernel
Which version of the script did you used @pit65 ? Could you upload the kernel somewhere ?
Hi with the last version 0.17 i got now for variant 2 the following message:
Hardware (CPU microcode) support for mitigation: UNKNOWN (couldn't read /dev/cpu/0/msr, is msr support enabled in your kernel?)
./spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.17
Checking for vulnerabilities against live running kernel Linux 2.6.18-416.el5PAE #1 SMP Wed Oct 26 12:06:12 EDT 2016 i686 Will use vmlinux image /boot/vmlinuz-2.6.18-416.el5PAE Will use kconfig /boot/config-2.6.18-416.el5PAE Will use System.map file /boot/System.map-2.6.18-416.el5PAE
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
STATUS: VULNERABLE
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
So the couldn't extract your kernel from /boot/vmlinuz-2.6.18-416.el5PAE
error seems to be fixed, good!
Your kernel seems old so I'm expecting to see NO
on every check.
The UNKNOWN
you have about the MSR means the script can't access the available MSR list from your CPU.
A quick look at the v2.6.18 source code seems to indicate that the msr module didn't exist back then, this would be why!
As the originally reported problem (can't extract kernel) has been fixed, and the vulnerable status of referenced kernel seems to be correct, I'm closing this issue.
Feel free to reopen if needed.
Hi thanks for the first fix.
I think the smr is present in kernel 2.6,.18.X look at this:
https://github.com/lucyoa/kernel-exploits/tree/master/msr
https://www.exploit-db.com/exploits/27297/
Also in the source code of:
https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.gz
end in these files:
grep -rilw msr linux-2.6.18/*
Does not extract for me either. LZ4 compressed kernel.
@Meriipu I don't have an LZ4 compressed kernel at hand, would it be possible to upload your kernel image somewhere?
My decompression code is based on Linus' extract-vmlinux
script, but it hasn't been updated recently, so LZ4 probably didn't exist yet.
@speed47 [removed: was url to LZ4 kernel image]
@dbosanzio I used the LXR tool to quickly search for "msr" in 2.6.18 which returned no results, but it turns out there would have been, as per your message. I'll look into it, maybe the exposed "msr" file is in a different path under this version @Meriipu thanks, working on that
For now for LZ4 compressed kernel I'm making the following modifications:
diff -c spectre-meltdown-checker.sh spectre-meltdown-checker_lz4.sh
*** spectre-meltdown-checker.sh 2018-01-10 18:08:15.468346611 +0100
--- spectre-meltdown-checker_lz4.sh 2018-01-10 18:22:11.609732153 +0100
***************
*** 8,14 ****
#
# Stephane Lesimple
#
! VERSION=0.23
# Script configuration
show_usage()
--- 8,14 ----
#
# Stephane Lesimple
#
! VERSION=0.23 mod_lz4_arecki
# Script configuration
show_usage()
***************
*** 376,382 ****
# Try to find the header ($1) and decompress from here
for pos in `tr "$1\n$2" "\n$2=" < "$5" | grep -abo "^$2"`
do
! if ! which $3 >/dev/null 2>&1; then
vmlinux_err="missing '$3' tool, please install it, usually it's in the '$4' package"
return 0
fi
--- 376,382 ----
# Try to find the header ($1) and decompress from here
for pos in `tr "$1\n$2" "\n$2=" < "$5" | grep -abo "^$2"`
do
! if ! which $4 >/dev/null 2>&1; then
vmlinux_err="missing '$3' tool, please install it, usually it's in the '$4' package"
return 0
fi
***************
*** 403,412 ****
# That didn't work, so retry after decompression.
try_decompress '\037\213\010' xy gunzip gunzip "$1" && return 0
! try_decompress '\3757zXZ\000' abcde unxz xz-utils "$1" && return 0
try_decompress 'BZh' xy bunzip2 bzip2 "$1" && return 0
! try_decompress '\135\0\0\0' xxx unlzma xz-utils "$1" && return 0
try_decompress '\211\114\132' xy 'lzop -d' lzop "$1" && return 0
return 1
}
--- 403,413 ----
# That didn't work, so retry after decompression.
try_decompress '\037\213\010' xy gunzip gunzip "$1" && return 0
! try_decompress '\3757zXZ\000' abcde unxz unxz "$1" && return 0
try_decompress 'BZh' xy bunzip2 bzip2 "$1" && return 0
! try_decompress '\135\0\0\0' xxx unlzma unlzma "$1" && return 0
try_decompress '\211\114\132' xy 'lzop -d' lzop "$1" && return 0
+ try_decompress '\002\041\114\030' xyy 'lz4 -d -l' lz4 "$1" && return 0
return 1
}
I actually just pushed a new version supporting lz4! Can you try it ?
It's freezing for a while, like after my modifications, but it works. Tested on liquorix kernel.
if it seems to be freezing while checking variant 1, it's normal, that's the most expensive test : we need to disassemble the kernel image to get the count of lfence opcodes.
Yes, it's freezing on variant1. I do not notice such behavior on Debian kernels.
Seems to work now for me. Thanks.
Thank you too for modifying this cool script.
Good to know it works! :)
@dbosanzio I've booted a livecd of a CentOS 5 (which is more or less like your rhel5), and I can see that the /dev/cpu/0/msr
does exist there.
Did you run the script as root? If yes, can you check if the file is there ? By running find /dev/cpu
and pasting the results here?
find /dev/cpu find: /dev/cpu: No such file or directory find . | grep -i cpu ./cpu_dma_latency
find . | grep -i msr
Is not present.
Could you try the following command?
modprobe cpuid
dd if=/dev/cpu/0/cpuid bs=16 skip=7 iflag=skip_bytes count=1 2>/dev/null | od -x
This would be another way to detect the microcode update without needing to try to read the MSR
Could you run the current version of the script (v0.31 or newer) in verbose mode ? (with -v -v
)
Closing, as the script evolved a lot since this report. Feel free to reopen if the problematic behaviour can still be reproduced with the latest versions. Thanks!
Hi, could you help me in fix this "UNKNOWN" problem?
Thanks:
Checking vulnerabilities against Linux 2.6.18-416.el5PAE #1 SMP Wed Oct 26 12:06:12 EDT 2016 i686
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'