When is a cybersecurity hole not a hole? Never


In cybersecurity, one of the more challenging issues is deciding when a security hole is a big deal, requiring an immediate fix or workaround, and when it’s trivial enough to ignore or at least deprioritize. The tricky part is that much of this involves the dreaded security by obscurity, where a vulnerability is left in place and those in the know hope no one finds it. (Classic example: leaving a sensitive web page unprotected, but hoping that its very long and non-intuitive URL isn’t accidentally found.)

And then there’s the real problem: in the hands of a creative and well-resourced bad guy, almost any hole can be leveraged in non-traditional ways. But — there is always a but in cybersecurity — IT and security pros can’t pragmatically fix every single hole anywhere in the environment.

As I said, it’s tricky.

What brings this to mind is an intriguing M1 CPU hole found by developer Hector Martin, who dubbed the hole M1racles and posted detailed thoughts on it.

Martin describes it as “a flaw in the design of the Apple Silicon M1 chip [that] allows any two applications running under an OS to covertly exchange data between them, without using memory, sockets, files, or any other normal operating system features. This works between processes running as different users and under different privilege levels, creating a covert channel for surreptitious data exchange. The vulnerability is baked into Apple Silicon chips and cannot be fixed without a new silicon revision.”

Martin added: “The only mitigation available to users is to run your entire OS as a VM. Yes, running your entire OS as a VM has a performance impact” and then suggested that users not do this because of the performance hit.

Copyright © 2021 IDG Communications, Inc.



Source link