Thinking Security: WannaCry? Not on ClearPath Forward™

 Author(s): , Posted on July 26th, 2017

This is the 28th blog in a series about security and how security is about how you think.

Many thanks to Dr. Glen Newton and Chuck Caldarale for help with the ClearPath® OS 2200 architecture sections of this blog and to Tony Matyok for help with the MCP architecture sections.

The recent WannaCry (also known as WannaCrypt) vulnerability and subsequent announcement of a related vulnerability in Samba (the software which provides SMB functionality in Linux) had many organizations in panic mode trying to make sure that they had all of their patches installed so that they weren’t vulnerable. ClearPath® MCP and OS2200 clients weren’t in a panic mode, however, because they knew (and we reinforced this via Customer Technical Bulletins) that they weren’t vulnerable. But why? Let’s look at that ransomware and show why ClearPath isn’t vulnerable.

The core of the ransomware is leveraging an issue in the Microsoft SMB service. By sending the SMB service a “crafted” packet, a malefactor could infect the target system and allow it to install a service and run code on their behalf (what is known as a Remote Code Execution). Other vulnerabilities have used this same approach – if the attacker can find a service that doesn’t check its data correctly or is on an architecture that doesn’t provide protection for these types of attacks, the target systems are at risk.

The basic approach is to send a network packet to the system, corrupt the stack so that rather than returning to the code that is part of the operating system’s service, execution returns to the code that is part of the packet that was sent over. Once that can be done, the malware can do many things – look for other hosts to infect, or call back to one of its malware servers and download other software to further infect the service. The malware may also install itself into the target machine so that every time that system reboots, the malware comes back and assumes control.

So, let’s look at how ClearPath Forward™ defended this attack. In the MCP environment, Client Access Services provide SMB functionality, while the CIFS product does so on OS 2200. These ClearPath Forward implementations listen on port 445. They would have received the crafted packet and put it into a data buffer. The bad packet would be in an off-stack buffer. Processing the contents of the packet would be subject to normal bounds checking, so it could not access or affect memory outside of the buffer. Stack corruption could not happen, for three reasons: One, the code that was attached to the attack was targeted at other architectures, not MCP or OS 2200, so it was benign. Two, it targeted a vulnerability in Microsoft’s implementation (the MCP and OS 2200 implementations don’t have that same problem). And three, and most importantly, stack corruption can’t occur. The activation records of the MCP operating system and the corresponding data structures in OS 2200 prevent stack corruption, so if a process tried to corrupt the stack, it would be stopped. Both architectures also have additional protections in their networking stack: the data received from the network is presented to the service in data buffers (not on the stack or heap). The architecture of the ClearPath environments precludes the overflow of these buffers, so even the potential for stack manipulation does not exist.

Okay, the attack is stopped, but let’s go further – even if it did corrupt the stack, it would try to return control to a data buffer. Again, the ClearPath MCP environment would stop that, because data buffers are not executable – only segments marked as code are (and a program cannot change the type of a buffer). In the ClearPath OS 2200 environment, returning control to a data buffer is impossible because data and return control are separate stacks.

Let’s assume that the attack even got past that (which is impossible), and assumed control. Even in that case, the malware would be restricted because all services of the operating system run in “user” mode, so no escalation of privilege or control of the kernel is possible. You can think of the ClearPath MCP and ClearPath OS 2200 environments as microkernels, which only have the very core operating-system services. All other parts of the ClearPath MCP environment run as system libraries outside this microkernel. Other parts of the ClearPath OS 2200 environment run in protected subsystems and less privileged architecturally defined rings. This means that the attack wouldn’t be able to take over the system and install itself so that subsequent reboots would re-enable the malware. MCP services and OS 2200 CIFS use separate processes to handle each individual request, and at worst, the attack would cause the separate process to terminate, leaving the service ready to handle the next request.

These ClearPath Forward architectures are a result of many years and many developers who naturally THINK security – and it shows. So, if you WannaCry after that ransomware hit, maybe a ClearPath Forward system would help your IT infrastructure be more secure.

Tags: , , , , , ,


About the Author

Mike Kain is a consulting engineer and security architect for the ClearPath MCP environment and has held various technical leadership positions during his 30 years of experience at Unisys. Read all Posts





«Getting the Most from Your Windows 10 Migration Through Unisys’ Automation and End-User Self-Service

Revolutionising the Passenger Journey with Data »






We use cookies on this site. By using this site, you agree to our use of cookies. To change or learn more, see our Privacy Notice.