4 ms·
These side-channel attacks -- which, as illustrated, are not new -- are becoming perceived as more acute because more so than before we're intermingling process
by niftich 9y ago
These side-channel attacks -- which, as illustrated, are not new -- are becoming perceived as more acute because more so than before we're intermingling processes with vastly different purposes, responsibilities, and origins, on the same hardware. When you do this, it's exceedingly difficult to cloak intrinsic attributes of execution, such as cache timing, or even execution timing, from other contexts of execution that have access to observe enough facets of the system.
This applies at all levels of reading, really. We're mixing the trafficking of sensitive authentication information in the same process as code that executes instantly upon clicking on hyperlinks. We're mixing business and pleasure on the same filesystem, in the same OS and memory space. We're mixing mutually untrusting entities' private data and code on timesharing systems that we're renting in someone else's datacenter.
Process boundaries, both in terms of physical reality and design choices on what constitutes a system boundary, are critical, and will need additional thought. At the same time, a boundary that's more robust to side-channel attacks than most is having all the hardware exclusive to yourself.
Also, this entire issue neatly demonstrates the problems with executing untrusted code. Solving the issue of vetting code and evaluating trust, especially by average users, is extremely difficult; but the current culture of the Web largely consists of running untrusted code immediately from a single user-entered string, or through automatic or manual navigation thenceforth. This is a frightening proposition, and yet entirely mainstream today.
- willtim 9y agoThis problem is made worse by technologies like JavaScript, which resemble system programming languages in the lack of restrictions placed on untrusted code. JS code can create threads, sockets, timers, perform I/O, loop or allocate forever. This is complete overkill for something that is mostly needed for interactive websites. Web Assembly doesn't fix this problem either. JavaScript has killed accessibility for the web and created numerous security problems. I don't want it and try to block it when I can.