[App_rpt-users] Intel CPU bug
Bryan D. Boyle
bdboyle at bdboyle.com
Fri Jan 5 12:26:15 EST 2018
(Remember when the Pentium was discovered to have a bug that
approximated the mathematical results of some computations? Yeah...that
Anyway...did some digging, especially since more and more folks are
migrating to the Pi.
But first: in order to implant these malware exploits, you have to have
access to the system. IF you are not practicing good systems hygiene,
and not keeping up to date, have a wide range of ports open, etc...every
port open is one more potential exploit. Running web servers on the same
host as app_rpt, for instance. Having simple passwords for SSH login.
Allowing ROOT login via SSH. The list is long and ugly. But, but,
but...the flexibility of the event subsystem, macros, and dtmf functions
really don't require anything other than the IAX2 port be opened to do
98% of system maintenance. And if you really really need console
access, consider configuring a VPN with cryptographic id exchange.
Limit the attack surface...limit the possibility of exploit.
But, what about the Pi?
According to ARM <https://developer.arm.com/support/security-update>
themselves (https://developer.arm.com/support/security-update), the
Raspberry Pi's processor cores (for all versions) are *not* affected.
"The majority of Arm processors are not impacted by any variation of
this side-channel speculation mechanism. A definitive list of the
small subset of Arm-designed processors that are susceptible can be
The processor cores used by the Pis are:
Pi 1 and Zero (W): ARM11 <https://en.wikipedia.org/wiki/ARM11>
Pi 2 V1: ARM Cortex-A7 <https://en.wikipedia.org/wiki/ARM_Cortex-A7>
Pi 2 V1.2 and Pi 3: ARM Cortex-A53
None of the above cores are listed as vulnerable to any version of the
attack (they are not listed at all, in fact, because there is no known
vulnerability to these attacks).
Spectre and Meltdown both require out-of-order execution. The Cortex-A7
<https://en.wikipedia.org/wiki/ARM_Cortex-A7> used in the early Pi 2 and
the Cortex A53 <https://en.wikipedia.org/wiki/ARM_Cortex-A53> used in
the later Pi 2 and the Pi 3 is a strictly in-order architecture. The
ARM11 <https://en.wikipedia.org/wiki/ARM11> used in the Pi 1 is
partially out-of-order, but not in a way that permits Spectre or
Meltdown to work.
ARM confirms this <https://developer.arm.com/support/security-update>:
only a very limited subset of ARM processors have hardware that makes
them vulnerable to Spectre, an even more limited subset are vulnerable
to Meltdown, and it's believed that all of them permit mitigation of the
threat. Take that for what it's worth.
Bottom line, to me: should we worry about this? Not to the point of
loosing sleep, at least on the allstar side of the house. It's
something to be aware of, especially those running on Intel CPUs, since
the chance of it being exploited is greater than zero, but the risk, at
this point, of it happening is less than 100, especially if you've
locked down your ports on your ingress/egress routers, have firewalls in
place, etc., and generally practice good system management and security
I'm thinking that when the necessary patches for the underlying OS
(Debian) are published, a side effort to respin the release with the
patches, after testing for performance and reliability of the allstart
code, be done and released, and that the USERS implement the update. We
can't force anyone to do so...but, it's just doing the Right Thing to do so.
Your Windows/Mac/etc desktop and office systems? That's another story.
Keep a watch on the patch release cycles and fixes that are offered from
the software vendors. Apply them.
Because these exploits use an acceleration feature in the architecture
to help them work faster...I'm predicting that any software/OS patch to
minimize the exposure will have a performance hit, since it will
essentially turn off a major pipeline speedup function. So, wariness,
both to prevent infection, as well as implementing changes is certainly
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the App_rpt-users