[App_rpt-users] Intel CPU bug

[Bryan D. Boyle]

(Remember when the Pentium was discovered to have a bug that 
approximated the mathematical results of some computations? Yeah...that 
long ago)

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
    found below.

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
    <https://en.wikipedia.org/wiki/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 
hygiene.

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 
warranted.

Bryan

WB0YLE/W2FUV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20180105/fe2261ff/attachment.html>