arch-audit reporting high and critical risk vulnerabilities

[Ente]

This must be a stupid question, since no-one else seems to be worried (the search for "arch-audit" doesn't show any postings), but I am starting to get a little bit worried. Since arch-audit became available for Arch Linux ARM, I am using it to check my installation for known vulnerabilities. During the last month, it always shows a number of high-risk vulnerabilities, even for very important packages like binutils. Do I need to worry, or are these vulnerabilities specific to Intel hardware, and harmless on an ARM device?

To be more precise, here is what I am getting today:

$this->bbcode_second_pass_code('', 'Package binutils is affected by ["CVE-2017-9044", "CVE-2017-9043", "CVE-2017-9042", "CVE-2017-9041", "CVE-2017-9040", "CVE-2017-9039", "CVE-2017-9038", "CVE-2017-7210", "CVE-2017-7209", "CVE-2017-6969", "CVE-2017-6966", "CVE-2017-6965"]. High risk!
Package libffi is affected by ["CVE-2017-1000376"]. High risk!
Package libtiff is affected by ["CVE-2016-10095", "CVE-2015-7554"]. Critical risk!
Package pcre is affected by ["CVE-2017-7246", "CVE-2017-7245", "CVE-2017-7244", "CVE-2017-7186"]. High risk!
Package systemd is affected by ["CVE-2017-9445"]. High risk! Update to 233-6 from testing repos!')

For the high-risk systemd vulnerability CVE-2017-9445, there is a simple workaround in stopping systemd-resolved.service - this will make systemd safe for the time being, but of course this doesn't apply to all the other CVEs I was not yet able to check in detail.

Thank you in advance,
Christian

[WarheadsSE]

Let me point a few things out in regards to that particular CVE: CVE-2017-9445

"High risk! Update to 233-6 from testing repos!" .. um no.


`systemctl status systemd-resolved` shows that `/usr/lib/systemd/system/systemd-resolved.service` is the file being used, and examining that file, I see the following points.

* It drops most capabilities off the bat (CapabilityBoundingSet)
* It is using as many lock-downs as possible (PrivateTmp, PrivateDevices, ProtectSystem, MemoryDenyWriteExecute ...)

This is highly locked down to that application itself, and then highly restricted with namespacing and capabilities bring stripped.