Red Hat has developed a free scanner for the infamous SPECTRE vulnerability. The toolkit was created for internal use but is being made available in source form, with the caveat that it is not a supported Red Hat product.
The tool was made public last week. It can scan Intel’s x86_64 and Arm’s AArch64 architectures, with the ability to scan more architectures planned.
Red Hat developers have made it available in source form as it would be “unwise to offer a security analysis tool as a pre-compiled binary.”
Spectre: Still Among Us
The tool, which scans for so-called variant one (CVE-2017-5753) SPECTRE vulnerabilities, was published on a Red Hat blog by Nick Clifton, who develops custom software engineering solutions for GCC.
Spectre is one of the most widespread vulnerabilities ever identified and affects nearly everyone: it can’t be spotted by an antivirus programme and its exploitation does not leave any traces in traditional log files.
See also: Microsoft and Google find New Meltdown-Spectre Security Chip Vulnerability
The release comes as Spectre – a widespread class of vulnerability that allows hackers to manipulate a common efficiency technique used to speed data processing – rears its head anew, with fresh exploits reported.
(As highlighted by the Register, earlier this month researchers Vladimir Kiriansky and Carl Waldspurger disclosed new data-stealing exploits, dubbed Spectre 1.1 and 1.2. Another new exploit called SpectreRSB meanwhile uses the return stack buffer, a system in modern CPUs used to help predict return addresses, to gain access to a system.)
Content from our partners
Ghostbusting
The Red Hat scanner can be simply invoked with the path to a binary to scan and a starting address inside the binary:
x86_64-scanner vmlinux --start-address=0xffffffff81700001
As Nick Clifton notes: “The start address will presumably be a syscall entry point, and the binary a kernel image. (Uncompressed; the scanner does not yet know how to decompress compressed kernels).”
“Alternatively the binary could be a library and the address an external function entry point into that library. In fact, the scanner will handle any kind of binary, including user programs, libraries, modules, plugins and so on.”
He adds: “A start address is needed in order to keep things simple and to avoid extraneous output. In theory, the scanner could examine every possible code path through a binary, including ones not normally accessible to an attacker. But this would produce too much output. Instead, a single start address is used in order to restrict the search to a smaller region. Naturally the scanner can be run multiple times with different starting addresses each time, so that all valid points of attack can be scanned.”
It can be found here (tar.xz download) with guide (and a healthy smattering of caveats) here.
