81 Commits
v0.32 ... v0.36

Author SHA1 Message Date
b6fd69a022 release: v0.36 2018-03-27 23:08:38 +02:00
7adb7661f3 enh: change colors and use red only to report vulnerability 2018-03-25 18:15:08 +02:00
c7892e3399 update README.md 2018-03-25 14:18:39 +02:00
aa74315df4 feat: speed up kernel version detection 2018-03-25 13:42:19 +02:00
0b8a09ec70 fix: mis adjustments for BSD compat 2018-03-25 13:26:00 +02:00
b42d8f2f27 fix(write_msr): use /dev/zero instead of manually echoing zeroes 2018-03-25 12:53:50 +02:00
f191ec7884 feat: add --hw-only to only show CPU microcode/cpuid/msr details 2018-03-25 12:48:37 +02:00
28da7a0103 misc: message clarifications 2018-03-25 12:48:03 +02:00
ece25b98a1 feat: implement support for NetBSD/FreeBSD/DragonFlyBSD 2018-03-25 12:28:02 +02:00
889172dbb1 feat: add special extract_vmlinux mode for old RHEL kernels 2018-03-25 11:55:44 +02:00
37ce032888 fix: bypass MSR/CPUID checks for non-x86 CPUs 2018-03-25 11:55:44 +02:00
701cf882ad feat: more robust validation of extracted kernel image 2018-03-25 11:55:44 +02:00
6a94c3f158 feat(extract_vmlinux): look for ELF magic in decompressed blob and cut at found offset 2018-03-25 11:55:42 +02:00
2d993812ab feat: add --prefix-arch for cross-arch kernel inspection 2018-03-25 11:55:10 +02:00
4961f8327f fix(ucode): fix blacklist detection for some ucode versions 2018-03-19 12:09:39 +01:00
ecdc448531 Check MSR in each CPU/Thread (#136) 2018-03-17 17:17:15 +01:00
12ea49fe0c fix(kvm): properly detect PVHVM mode (fixes #163) 2018-03-16 18:29:58 +01:00
053f1613de fix(doc): use https:// URLs in the script comment header 2018-03-16 18:24:59 +01:00
bda18d04a0 fix: pine64: re-add vmlinuz location and some error checks 2018-03-10 16:02:44 +01:00
2551295541 doc: use https URLs 2018-03-10 15:20:07 +01:00
d5832dc1dc feat: add ELF magic detection on kernel image blob for some arm64 systems 2018-03-10 14:57:25 +01:00
d2f46740e9 feat: enhance kernel image version detection for some old kernels 2018-03-10 14:57:25 +01:00
2f6a6554a2 Produce output for consumption by prometheus-node-exporter
A report of all vulnerable machines to be produced with a query such as:

    spexec_vuln_status{status!="OK"}
2018-02-27 11:08:39 +01:00
30842dd9c0 release: bump to v0.35 2018-02-16 10:35:49 +01:00
b4ac5fcbe3 feat(variant2): better explanation when kernel supports IBRS but CPU does not 2018-02-16 10:34:01 +01:00
fef380d66f feat(readme): add quick run section 2018-02-15 21:19:49 +01:00
55a6fd3911 feat(variant1): better detection for Red Hat/Ubuntu patch 2018-02-15 21:19:49 +01:00
35c8a63de6 Remove the color in the title 2018-02-15 20:21:00 +01:00
5f914e555e fix(xen): declare Xen's PTI patch as a valid mitigation for variant3 2018-02-14 14:24:55 +01:00
66dce2c158 fix(ucode): update blacklisted ucodes list from latest Intel info 2018-02-14 14:14:16 +01:00
155cac2102 Teach checker how to find kernels installed by systemd kernel-install 2018-02-10 20:51:33 +01:00
22cae605e1 fix(retpoline): remove the "retpoline enabled" test
This test worked for some early versions of the retpoline
implementation in vanilla kernels, but the corresponding
flag has been removed from /proc/cpuinfo in latest kernels.
The full information is available in /sys instead, which
was already implemented in the script.
2018-02-09 20:12:33 +01:00
eb75e51975 fix(ucode): update list of blacklisted ucodes from 2018-02-08 Intel document
Removed 2 ucodes and added 2 other ones
2018-02-09 19:56:27 +01:00
253e180807 Update spectre-meltdown-checker.sh
Dots better than colon for indicating waiting.
2018-02-06 19:02:56 +01:00
5d6102a00e enh: show kernel version in offline mode 2018-02-02 11:27:04 +01:00
a2dfca671e feat: detect disrepancy between found kernel image and running kernel 2018-02-02 11:13:54 +01:00
36bd80d75f enh: speedup by not decompressing kernel on --sysfs-only 2018-02-02 11:13:31 +01:00
1834dd6201 feat: add skylake era cpu detection routine 2018-02-02 11:12:10 +01:00
3d765bc703 enh: lazy loading of cpu informations 2018-02-02 11:11:51 +01:00
07afd95b63 feat: better cleanup routine on exit & interrupt 2018-02-02 11:09:36 +01:00
b7a10126d1 fix: ARM CPU display name & detection
Fix ARM CPU display name, and properly
detect known vulnerable ARM CPUs when
multiple different model cores are
present (mostly Android phones)
2018-02-02 11:00:23 +01:00
6346a0deaa fix: --no-color workaround for android's sed 2018-02-02 10:59:49 +01:00
8106f91981 release: bump to v0.34 2018-01-31 16:28:54 +01:00
b1fdf88f28 enh: display ucode info even when not blacklisted 2018-01-31 16:21:32 +01:00
4d29607630 cleanup: shellcheck pass 2018-01-31 16:15:20 +01:00
0267659adc cleanup: remove superseded atom detection code
This is now handled properly by checking the CPU
vendor, family, model instead of looking for the
commercial name of the CPU in /proc/cpuinfo
2018-01-31 16:15:20 +01:00
247b176882 feat: detect known speculative-execution free CPUs
Based on a kernel patch that has been merged to Linus' tree.
Some of the detections we did by grepping the model name
will probably no longer be needed.
2018-01-31 16:15:20 +01:00
bcae8824ec refacto: create a dedicated func to read cpuid bits 2018-01-31 16:15:20 +01:00
71e7109c22 refacto: move cpu discovery bits to a dedicated function 2018-01-31 16:15:20 +01:00
aa18b51e1c fix(variant1): smarter lfence check
Instead of just counting the number of LFENCE
instructions, now we're only counting the those
that directly follow a jump instruction.
2018-01-31 14:34:54 +01:00
b738ac4bd7 fix: regression introduced by previous commit
449: ./spectre-meltdown-checker.sh: 3: parameter not set
This happened only on blacklisted microcodes, fixed by
adding set +u before the return
2018-01-31 12:13:50 +01:00
799ce3eb30 update blacklisted ucode list from kernel source 2018-01-31 11:26:23 +01:00
f1e18c136f doc(disclaimer): Spectre affects all software
Add a paragraph in the disclaimer stating that this tool focuses
on the kernel side of things, and that for Spectre, any software
might be vulnerable.
2018-01-30 14:37:52 +01:00
e05ec5c85f feat(variant1): detect vanilla mitigation
Implement detection of mitigation for Variant 1 that is
being pushed on vanilla kernel.
Current name of the patch:
"spectre variant1 mitigations for tip/x86/pti" (v6)
Also detect some distros that already backported this
patch without modifying the vulnerabilities sysfs hierarchy.
This detection is more reliable than the LFENCE one, trust
it and skip the LFENCE heuristic if a match is found.
2018-01-30 12:55:34 +01:00
6e544d6055 fix(cpu): Pentium Exxxx are vulnerable to Meltdown 2018-01-29 11:18:15 +01:00
90a65965ff adjust: show how to enable IBRS/IBPB in -v only 2018-01-29 11:06:15 +01:00
9b53635eda refacto: fix shellcheck warnings for better compat
Now `shellcheck -s sh` no longer shows any warnings.
This should improve compatibility with exotic shells
as long as they're POSIX compliant.
2018-01-29 10:34:08 +01:00
7404929661 Fix printing of microcode to use cpuinfo values
The values used should be the ones that come from cpuinfo instead of
the test values. The following line will print the last tuple tested
instead of the actual values of the CPU.

Line 689: _debug "is_ucode_blacklisted: no ($model/$stepping/$ucode)"
2018-01-26 18:23:18 +01:00
bf46fd5d9b update: new screenshots for README.md 2018-01-26 15:15:24 +01:00
0798bd4c5b fix: report arch_capabilities as NO when no MSR
When the arch_capabilities MSR is not there, it means
that all the features it might advertise can be considered
as NO instead of UNKNOWN
2018-01-26 14:55:01 +01:00
42094c4f8b release: v0.33 2018-01-26 14:20:29 +01:00
03d2dfe008 feat: add blacklisted Intel ucode detection
Some Intel microcodes are known to cause instabilities
such as random reboots. Intel advises to revert to a
previous version if a newer one that fixes those issues
is not available. Detect such known bad microcodes.
2018-01-26 14:19:54 +01:00
9f00ffa5af fix: fallback to UNKNOWN when we get -EACCES
For detection of IBRS_ALL and RDCL_NO, fallback to
UNKNOWN when we were unable to read the CPUID or MSR.
2018-01-26 14:16:34 +01:00
7f0d80b305 xen: detect if the host is a Xen Dom0 or PV DomU (fixes #83) 2018-01-25 11:04:30 +01:00
d1c1f0f0f0 fix(batch): fix regression introduced by acf12a6
In batch mode, $echo_cmd was not initialized early
enough, and caused this error:
./spectre-meltdown-checker.sh: 899: ./spectre-meltdown-checker.sh: -ne: not found
Fix it by initing echo_cmd unconditionally at the start
2018-01-24 17:57:19 +01:00
acf12a6d2d feat(cpu) add STIBP, RDCL_NO, IBRS_ALL checks
Move all the CPU checks to their own section,
for clarity. We now check for IBRS, IBPB, STIBP,
RDCL_NO and IBRS_ALL. We also show whether the
system CPU is vulnerable to the three variants,
regardless of the fact that mitigations are in
place or not, which is determined in each vuln-
specific section.
2018-01-24 14:44:16 +01:00
b45e40bec8 feat(stibp): add STIBP cpuid feature check 2018-01-24 12:19:02 +01:00
3c1d452c99 fix(cpuid): fix off-by-one SPEC_CTRL bit check 2018-01-24 12:18:56 +01:00
53b9eda040 fix: don't make IBPB mandatory when it's not there
On some kernels there could be IBRS support but not
IBPB support, in that case, don't report VULN just
because IBPB is not enabled when IBRS is
2018-01-24 09:04:25 +01:00
3b0ec998b1 fix(cosmetic): tiny msg fixes 2018-01-24 09:04:25 +01:00
d55bafde19 fix(cpu): trust is_cpu_vulnerable even w/ debugfs
For variant3 under AMD, the debugfs vulnerabilities hierarchy
flags the system as Vulnerable, which is wrong. Trust our own
is_cpu_vulnerable() func in that case
2018-01-24 09:04:25 +01:00
147462c0ab fix(variant3): do our checks even if sysfs is here 2018-01-24 09:04:25 +01:00
ddc7197b86 fix(retpoline): retpoline-compiler detection
When kernel is not compiled with retpoline option, doesn't
have the sysfs vulnerability hierarchy and our heuristic to
detect a retpoline-aware compiler didn't match, change result
for retpoline-aware compiler detection from UNKNOWN to NO.
When CONFIG_RETPOLINE is not set, a retpoline-aware compiler
won't produce different asm than a standard one anyway.
2018-01-24 09:04:25 +01:00
e7aa3b9d16 feat(retpoline): check if retpoline is enabled
Before we would just check if retpoline was compiled
in, now we also check that it's enabled at runtime
(only in live mode)
2018-01-24 09:04:25 +01:00
ff5c92fa6f feat(sysfs): print details even with sysfs
Before, when the /sys kernel vulnerability interface
was available, we would bypass all our tests and just
print the output of the vulnerability interface. Now,
we still rely on it when available, but we run our
checks anyway, except for variant 1 where the current
method of mitigation detection doesn't add much value
to the bare /sys check
2018-01-24 09:04:25 +01:00
443d9a2ae9 feat(ibpb): now also check for IBPB on variant 2
In addition to IBRS (and microcode support), IBPB
must be used to mitigate variant 2, if retpoline
support is not available. The vulnerability status
of a system will be defined as "non vulnerable"
if IBRS and IBPB are both enabled, or if IBPB
is enabled with a value of 2 for RedHat kernels,
see https://access.redhat.com/articles/3311301
2018-01-24 09:04:25 +01:00
3e454f1817 fix(offline): report unknown when too few info
In offline mode, in the worst case where an invalid
config file is given, and we have no vmlinux image
nor System.map, the script was reporting Variant 2
and Variant 3 as vulnerable in the global status.
Replace this by a proper pair of UNKNOWNs
2018-01-23 22:20:34 +01:00
c8a25c5d97 feat: detect invalid kconfig files 2018-01-23 21:48:19 +01:00
40381349ab fix(dmesg): detect when dmesg is truncated
To avoid false negatives when looking for a message
in dmesg, we were previously also grepping in known
on-disk archives of dmesg (dmesg.log, kern.log).
This in turn caused false positives because we have no
guarantee that we're grepping the dmesg of the current
running kernel. Hence we now only look in the live
`dmesg`, detect if it has been truncated, and report
it to the user.
2018-01-21 16:26:08 +01:00
0aa5857a76 fix(cpu): Pentium Exxxx series are not vulnerable
Pentium E series are not in the vulnerable list from
Intel, and Spectre2 PoC reportedly doesn't work on
an E5200
2018-01-21 16:13:17 +01:00
b3b7f634e6 fix(display): use text-mode compatible colors
in text-mode 80-cols TERM=linux terminals, colors
were not displaying properly, one had to use
--no-color to be able to read some parts of the
text.
2018-01-21 12:32:22 +01:00
2 changed files with 1558 additions and 393 deletions

View File

@ -1,16 +1,53 @@
Spectre & Meltdown Checker
==========================
A simple shell script to tell if your Linux installation is vulnerable against the 3 "speculative execution" CVEs that were made public early 2018.
A shell script to tell if your system is vulnerable against the 3 "speculative execution" CVEs that were made public early 2018.
Without options, it'll inspect your currently running kernel.
You can also specify a kernel image on the command line, if you'd like to inspect a kernel you're not running.
Supported systems:
- Linux (all versions and flavors)
- FreeBSD
- NetBSD
- DragonFlyBSD
The script will do its best to detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number.
For Linux systems, the script will detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number and the distribution (such as Debian, Ubuntu, CentOS, RHEL, Fedora, openSUSE, Arch, ...), it also works if you've compiled your own kernel.
For BSD systems, the detection will work as long as the BSD you're using supports `cpuctl` and `linprocfs` (this is not the case of OpenBSD for example).
## Easy way to run the script
- Get the latest version of the script using `curl` *or* `wget`
```bash
curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
```
- Inspect the script. You never blindly run scripts you downloaded from the Internet, do you?
```bash
vim spectre-meltdown-checker.sh
```
- When you're ready, run the script as root
```bash
chmod +x spectre-meltdown-checker.sh
sudo ./spectre-meltdown-checker.sh
```
## Example of script output
![checker](https://framapic.org/6O4v4AAwMenv/M6J4CFWwsB3z.png)
- Intel Haswell CPU running under Ubuntu 16.04 LTS
![haswell](https://framapic.org/1kWmNwE6ll0p/ayTRX9JRlHJ7.png)
- AMD Ryzen running under OpenSUSE Tumbleweed
![ryzen](https://framapic.org/TkWbuh421YQR/6MAGUP3lL6Ne.png)
- Batch mode (JSON flavor)
![batch](https://framapic.org/HEcWFPrLewbs/om1LdufspWTJ.png)
## Quick summary of the CVEs
@ -38,8 +75,10 @@ The script will do its best to detect mitigations, including backported non-vani
This tool does its best to determine whether your system is immune (or has proper mitigations in place) for the collectively named "speculative execution" vulnerabilities. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying whether your system has the known correct mitigations in place.
However, some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels).
Your system exposure also depends on your CPU. As of now, AMD and ARM processors are marked as immune to some or all of these vulnerabilities (except some specific ARM models). All Intel processors manufactured since circa 1995 are thought to be vulnerable. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
Your system exposure also depends on your CPU. As of now, AMD and ARM processors are marked as immune to some or all of these vulnerabilities (except some specific ARM models). All Intel processors manufactured since circa 1995 are thought to be vulnerable, except some specific/old models, such as some early Atoms. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs.
The nature of the discovered vulnerabilities being quite new, the landscape of vulnerable processors can be expected to change over time, which is why this script makes the assumption that all CPUs are vulnerable, except if the manufacturer explicitly stated otherwise in a verifiable public announcement.
Please also note that for Spectre vulnerabilities, all software can possibly be exploited, this tool only verifies that the kernel (which is the core of the system) you're using has the proper protections in place. Verifying all the other software is out of the scope of this tool. As a general measure, ensure you always have the most up to date stable versions of all the softwares you use, especially for those who are exposed to the world, such as network daemons and browsers.
This tool has been released in the hope that it'll be useful, but don't use it to jump to conclusions about your security.

File diff suppressed because it is too large Load Diff