Originally posted by bobbie424242
View Post
There are many people with decades of programming experience and top positions at companies who don't fully understand these attacks. I have spoken to people with B.Sc. (Hons.) in CS that still do not understand the attacks despite their credentials. On the other side people with no formal education or at least not CS related and are providing workarounds to the problems or writing pen-tests. The point is: This problem requires years of specialization to understand how this impacts your systems.
In most cases obtaining this specialization is not productive and does not help your business or career so there's little incentive for someone to obtain it. There still are people that are passionate about these problems and enjoy it as a hobby who don't need a financial incentive, yet IMO it's a dying breed. From a philosophical perspective it's not very practical either as a hobby.
Given a (reasonably) safe environment is met, it is a bit wasteful to not use the full speed of your CPU
The best way IMO to prevent side-channel attacks on faulty hardware without software mitigations is to run trusted software[1] and to prevent or sandbox[2] remote code or even remote data. Meaning don't connect your computer to the internet or if you do make sure there are no vulnerabilities in software that send or receive network requests. In the past if you ran apache via the "www-data" user if someone found an apache exploit then they were limited to that user. That is no longer the case if the attacker is using side-channel attacks. The attacker cannot automatically read your entire FS or simply just copy your SSH keys, they need to wait for you or one of your services to access it before they can read it. This gives attackers much more vectors to infiltrate sensitive parts of a system. This is why side-channel attacks are such a big problem for cloud providers, attackers can skip the first exploit completely. You already have the ability to run code when they sign up and start a non-dedicated instance.
1. How does packages become trusted? Is it because there are no reports of problems, do you trust the individuals who evaluate the packages, or those that originally write the software of those packages?
2. Sandboxes are not impervious to attacks.
for vulnerabilities that have probably waaay less chance to be exploited that to win at the Euromillion lottery.
Again, people have different priorities. I need my Linux work PC to be fast and only install packages from my distro whose packagers I trust.
If someone doesn't care about leaking their information nor do they have information about other people or businesses, by all means turn off the mitigations.
If someone has other people's data or code on their machine, it's better to err on the side of caution. They just might win the lottery on the same day as a few others without knowing.
Sorry for the long reply. I think it's important to understand first and then to choose priorities. I hope it helped in some way.
PS: In theory security to me is about not taking chances. I know it's not always practical. Yet odd things happen... Last month my country's (South African) lottery ended with numbers: 5, 6, 7, 8, 9, and 10. The exact order was 8, 5, 9, 7, 6 and extra powerball 10, still people here lost their minds
Leave a comment: