Hacker News new | ask | show | jobs
by CodeWriter23 704 days ago
> an unprecedented example of the inherent dangers of kernel programming

I take issue with that. Kernel programming was not to blame; looking up addresses from a file and accessing those memory locations without any validation is. The same technique would yield the same result at any Ring.

3 comments

Obviously in userspace it would only crash the running program and not the entire operating system? It's a significant difference.

All of the service interruptions would have been just "computer temporarily not protected by crowdstrike agent". Not the same thing at all.

> Obviously in userspace it would only crash the running program and not the entire operating system? It's a significant difference.

Significant and often far worse. It would leave the machine running unprotected.

> It's a significant difference.

When various apps running the world are crashing, unable to execute because malware protection is failing, there is no difference.

_No_ difference oversells it, IMO -- the fact that the entire OS crashed is what made fixing the bug so arduous, since it required in-person intervention. To be sure, running the code in userspace would still cause unacceptable service interruptions, but the fix could be applied remotely.
At Ring 3 it would crash an app, not the entire OS.

Yes, the kernel is fine and is not to blame. But running basically a rootkit controlled by a third party indeed is to blame.

> At Ring 3 it would crash an app, not the entire OS.

That's still an outage for those key systems.

It is an outage for the monitoring system, not the system that it monitors.
I think a reasonable protocol is to stop using any apps when your cyber protection crashes. Why have that suite at all otherwise?
I agree for some systems. For others, stopping the system has bigger consequences than not having cyber protection for a few hours because of a bug that’ll get fixed. For example, hospitals, or possibly Delta Airlines.
FWIW their configuration files can't be holding addresses; those have been randomised in the kernel for at least a decade