Microsoft is absolutely at fault for WannaCry

edA‑qa mort‑ora‑y - May 17 '17 - - Dev Community

Microsoft has played a significant role in the damage of the WannaCry ransomware. Certainly the proximate cause lies with the malware's authors, and they should be held accountable. The complacent NSA is also culpable in their role in creating or discovering, yet failing to report the exploit. We can even say that users must share part of the blame for not keeping their system up-to-date. But in no uncertain terms, it is the design of Microsoft's Windows operating system allowed the attack to happen.

Remote code execution

WannaCry uses an exploit in the SMB (file server) subsystem of Windows. It executes arbitrary code and takes control of the machine. This raises a vital question:

Why is a component that is responsible for file sharing capable of taking over the machine?

If we look at how Window's architecture it's not a problem explaining why this is possible. These subsystems are treated as privileged users and given extensive access to the computer. This is the core of the problem. There is a lack of privilege separation and an assumption that components are well-behaved.

If we had no alternative to this design we could cut Microsoft some slack. But we do have ways to mitigate such attacks, and it appears Microsoft has chosen not to implement them. Thus they must bear a significant part of the responsibility for the WannaCry ransomware.

Windows 10 does not appear to have been hit by the malware. If this is due to actual architectural changes, as I describe here, then great! That's a solid reason to upgrade. But it's not clear if that is the case; the security bulletin indicates they patched remote code execution on Windows 10 as well.

Injecting code

Let's assume for a moment that all software has defects, ones that would allow an attacker to compromise security. Given our known history this isn't a bad assumption to make. Yet we continue to ignore this while writing software. We are still coding as though the system is impenetrable, which is a terrible practice.

We need to be defensive. Obviously the first line of defense is safer coding and execution: buffer protection, safe types, address randomization, etc. There's lots of work in this direction, but it isn't perfect, so we have to assume we'll continue to fail here.

The second line of defense is not allowing an attacker to run arbitrary code. It sounds so obvious, so why isn't it done? The WannaCry attacker injected their own code via the SMB system.

CPUs have no-execute and read-only flags for memory. An OS can separate executable code and data memory from each other. Had this been done the attack vector would not have worked. The attacker would still be able to corrupt the data memory, but there would be no way for them to jump into that code.

CPUs didn't always have the no-execute ability, but it's been around for over 15 years now. Is Windows not using this feature? And if it is, how exactly was the code injected? (It's kind of understandable if WinXP didn't support this feature, as it wasn't widely available when that OS was released.)

Privilege escalation

Let's extend our assumption to distrusting software entirely. A typical downloaded application cannot take over the system on its own, so why can the SMB component?

Consider some of the features of file sharing: we need access to a particular set of files, not the entire filesystem; we need some way to authenticate users; we need a way to access the internet. These are all well definable interfaces that an operating system can provide. By partitioning privileges the OS can limit what an application is capable of doing.

Yet it seems the WannaCry malware has gained full control of the system. This is only possible if the SMB component is not segregated. We know from Samba that this protocol can run as isolated software. There are also numerous technologies on other OSs that further segregate and isolate components. Were none of those employed in Windows SMB?

I understand changing the structure of an OS is a phenomenal amount of work, but I have to assume Microsoft has the resources. Maybe they are doing this and it just isn't working. Why did the exploit gain so much access to the system?

And on and on

Assume the worst, that all our protections have failed. Surely we can still protect the user's data somebody. Isn't the sudden change of many files something Windows Defender could detect? Even if it didn't, why isn't there a rollback mechanism?

In fairness, Windows has options for making versioned backups. It is a user error for not enabling this, but there's obviously something preventing people from doing so. I'm also not sure if these backup files would be protected from WannaCry.

We need to stop assuming our computers are safe and instead design assuming they will be compromised. This is a core tenet of secure server design, so why isn't it applied to desktop systems?

Microsoft puts a lot of effort into security, but this doesn't absolve them of blame in the WannaCry affair. Their system design has allowed this attack to happen, despite there being known techniques that could have prevented it, or at least mitigated the severity.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player