Hacker News new | past | comments | ask | show | jobs | submit login

I'm going with the herd immunity for my personal stuff.

The calculation is basically:

their_waste = likelihood enough people have the mitigations enabled (not tech enough to disable them) so that "bad people" will not waste time developing exploits for the tiny number of unprotected people like me (herd protecting me)

my_risk = likelihood of "bad people" actually finding me and being able to run their code

their_reward = likelihood of them actually finding something meaningful and valuable in the memory they can manage to dump

oops = (my_risk * their_reward) / their_waste

I am assuming my_risk and their_reward to be low and their_waste to be high, so oops will be acceptably low (hopefully :p)

Wish me luck!




Server logs are full of scripts and people trying to penetrate services with old, known bugs that have been widely neutralized for years.... it doesn't cost much to try one exploit.


So far there haven't any mass exploits for these CPU bugs targeting personal systems like mine in the wild.

The most risk comes from web browsers as you can execute (constrained) attack code in those. That's why browser vendors were busy disabling SharedArrayBuffer real quick and developed further mitigations that hinder exploiting CPU bugs like these.

I may reconsider when browser-based exploits become a real thing that is in widespread use.

People probing my ports and exposed services running on my machines is far less of an issue since I don't run any service designed to run attacker supplied (but sandboxed) code like a browser does. If somebody managed to run code anyway (RCE) then I probably would have other problems than just worrying about somebody running spectre exploit code ;)

As it stands right now, the prime targets are shared execution environments running untrusted sandboxed code, aka cloud providers needing to worry that customer A's VM doesn't dump the memory of customer B's VM running on the same hardware.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: