[dvt]

> We gotta get off memory-unsafe languages.

You read this whole post and that's what you got? Just the fact that this includes a heap grooming step should be pretty telling that it's not very reliable and that it can easily be broken (it probably won't work if you try it after the next Win10 update).

I mean, yeah, sure, buffer overflows are bad, but this is an extremely sophisticated attack that relies on like a zillion moving pieces, of which "memory-unsafe languages" are basically a footnote. Props to the dedication and expertise of the security researchers.

[staticassertion]

Just because there's heap grooming involved doesn't mean it's unreliable. Exploits that use heap grooming can often be ~100% reliable.

Our POC for Sigred required lots of heap grooming but it was extremely reliable. https://www.graplsecurity.com/post/anatomy-of-an-exploit-rce...

The overflow was hardly a footnote either, it's the primary bug being exploited here.

[staticassertion]

FWIW, and this is not a 'dis' at the researchers, I would also not say this is "extremely sophisticated". Most attacks these days involve chaining lots of bugs like this and using grooming techniques. It's extremely impressive work and I have great respect for people who can do that, but I would reserve "extremely sophisticated" for cases where novel techniques are used, which isn't really the case here.

[asdfasgasdgasdg]

Would the exploit have been possible without this, though? Possibly but it would have been that much harder to accomplish. I think it's a fair if overdone observation that C is a bad language to use if you want to minimize the incidence of RCEs.

[feanaro]

Why does it matter how reliable it is? What matters is that it's possible. If it breaks with an update, the technique can be pretty easily adapted to work again.