Content, Channel partners, Channel, IT management, MSP, Channel technologies

Processor Memory-Access Vulnerability: Datto’s Perspective for MSPs

Ryan Weeks, CISO, Datto
Author: Datto CISO Ryan Weeks

As a leading vendor in the channel, Datto is always on the lookout for security issues that might affect our business as well as the business of our Partners and their SMB clients. Of particular interest, there has been a lot of chatter over the week about a potential memory-access bug, which seems to affect computers running modern processors, that would allow user programs on those computers to access memory reserved for the operating system.

It is unclear whether the bug is limited to certain manufacturers. On the one hand, Intel seems to suggest that the bug is not limited to certain manufacturers. On the other hand, a comment by an AMD engineer on the Linux Distribution List suggests AMD chips may not be affected).

Background

The memory-access vulnerability exists due to a flaw in how modern operating systems and processors work together. Modern operating systems have to walk a careful balance between improving system performance and ensuring system reliability and security. One of the important things that operating systems do to support this balance is to create virtual memory for user programs. Each process may only access its own virtual memory and cannot access memory reserved for the operating system or for other programs.  

When the operating system executes a program, it provides the processor with a translation table that the processor uses in order to convert the virtual memory addresses that the program uses into physical locations in memory, this enables the program to access data that it needs to perform its operations, but does not allow the program to access the instructions or data, associated with other programs. This protects the system against poorly written or malicious processes that might otherwise access or damage contents of another processes’ memory.

In order to speed up performance, modern operating systems also place themselves in the virtual memory of all programs. This makes it so that when the program calls the operating system or when the operating system interrupts the program, the processor can access the virtual addresses associated with the operating system, many of which are typically available in a cache on the CPU. The processor, though, maintains a careful segregation between virtual memory associated with the operating system and virtual memory associated with user processes and does not allow user processes to access virtual memory associated with the operating system.

How might the vulnerability work?

However, it appears that many modern chips may not maintain this distinction between the portion of user process’ virtual memory that the user process is allowed to access and the portion that the operating system is allowed to access when optimizing user program instructions. Some processors will attempt to improve performance by predicting the next instruction that a program will need to execute, preloading that instruction and then executing it. This optimizes the performance of the running program by parallelizing multiple workloads for the same process.

If the predicted instruction is loaded and executed without being subject to memory address privilege access checks, designed to ensure that each process only has access to its own memory, the processor may allow a malicious actor to read memory locations that should otherwise be off limits to the executing program.

As it appears many modern processors may be unable to maintain this segregation of memory addresses, they may not always be able to guarantee a segregation between user program memory and operating system virtual memory. This undermines one of the guarantees of security and reliability offered by modern operating systems and may create a vulnerability for systems using those processors.

What is changing?

In order to address the memory-access vulnerability, Windows, Linux and MacOS appear to be rushing out patches. The details have not entirely been released yet for all three operating systems, but Windows and Linux are both separating operating system kernel memory pages from the virtual memory pages of user programs, such that the two operating systems will no longer be placing themselves in the virtual memory of user programs.

This will mean that the operating system kernel memory will no longer be accessible from executing user programs, even if the processor can no longer maintain a strong segregation between a user program’s portion of its virtual memory and the operating system’s portion of a process’ virtual memory.

Will there be a performance slowdown?

Right now, it is unclear whether the patch will lead to a significant performance slowdown for ordinary business users. While Intel's public announcement today suggests that the performance impact of the upcoming patches should not significantly impact normal users, there has been an ongoing debate in online technology circles about whether this will actually be the case with some tests pointing towards a more substantial performance impact.

The potential for performance degradation occurs because of the separation of the user program and kernel memory pages into two distinct locations. It appears that this may undermine the ability of the processor to cache the operating system’s memory address locations, making context switches between user programs and the operating system more expensive.

Until the patches are released and technical specialists have time to observe the real life impact of these changes on production systems, it is hard to predict the full extent of how they will affect system performance for ordinary business users. MSPs will want to thoroughly test patches prior to deploying in order to assure continued availability of key customer services.

What is the security impact?

As discussed, Intel’s public announcement suggests that this vulnerability could allow unauthorized processes to read the contents of operating system virtual memory locations. Although, it is not clear how difficult the attack would be to leverage, for unpatched systems, it is possible this could potentially be exploited by malicious actors to access data stored in the operating system virtual memory space. This might include the contents of cached files, authentication credentials, or other sensitive information.

How may this affect MSPs?

MSPs and IT professionals should be monitoring for the vulnerability and patch release details that will be made available next week according to Intel.

MSPs should look to understand the scope and nature of the vulnerability and should also perform careful testing of the patches to determine if they cause any significant performance impact to their clients’ actual operating environments. This will help them to better advise their clients and help them to make a sound data security decision that balances any data confidentiality concerns that their clients may face with any potential system performance and availability impact that the patches may create.

In addition to helping to patch their clients’ systems, MSPs are going to receive questions from their clients on how they may be affected by the memory-access vulnerability. This will be especially true in the event that the vulnerability continues to get substantial media coverage and MSPs will have an important role to play in educating their clients about these issues.

Last, we expect MSPs will have a key role to play in continuing to monitor their clients’ systems to ensure that they have sufficient resources to continue to perform their workloads after patches are deployed.


Author Ryan Weeks is chief information security officer (CISO) at Datto. Read more Datto blogs, views and perspectives here.