As far as the attack described in the paper itself goes, I alluded to how the Rust team addressed this in the comments to Jess' introductory post: manishearth.github.io/blog/2016/12... I assume that the GCC/Clang/etc teams have also incorporated this fix.
However, one problem that we weren't dealing with back then was the sheer amount of code that ends up folded into an application. Maybe we can try to compensate for this with tooling, but attackers love to find tools' blind spots!
One idea I kind of like is having permissions be more granular - even more granular than the application level. So you'd have an application that needs network access, but it calls a third party module that perhaps entirely trustworthy - let's say it's a checksum calculation library. The checksum calculation library would specify in its package metadata that it only needs compute power, so if it lied about that, the code would get SIGKILL'd/throw an exception/whatever. I think one could pull this off in native code with some memory segmentation/call gate magic, but it would need to be supported all the way down to the kernel level, and memory segmentation is passé, so I don't think this would ever get implemented as anything other than a toy. With the rise of WASM and the ability to call functions created from different contexts, however, maybe this could happen.
That being said, I don't think this would take off - it would undoubtedly introduce too much overhead, plus it would be very tedious to work with, and our industry seems to prefer sacrificing these kind of protections to avoid tedium.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As far as the attack described in the paper itself goes, I alluded to how the Rust team addressed this in the comments to Jess' introductory post: manishearth.github.io/blog/2016/12... I assume that the GCC/Clang/etc teams have also incorporated this fix.
However, one problem that we weren't dealing with back then was the sheer amount of code that ends up folded into an application. Maybe we can try to compensate for this with tooling, but attackers love to find tools' blind spots!
One idea I kind of like is having permissions be more granular - even more granular than the application level. So you'd have an application that needs network access, but it calls a third party module that perhaps entirely trustworthy - let's say it's a checksum calculation library. The checksum calculation library would specify in its package metadata that it only needs compute power, so if it lied about that, the code would get SIGKILL'd/throw an exception/whatever. I think one could pull this off in native code with some memory segmentation/call gate magic, but it would need to be supported all the way down to the kernel level, and memory segmentation is passé, so I don't think this would ever get implemented as anything other than a toy. With the rise of WASM and the ability to call functions created from different contexts, however, maybe this could happen.
That being said, I don't think this would take off - it would undoubtedly introduce too much overhead, plus it would be very tedious to work with, and our industry seems to prefer sacrificing these kind of protections to avoid tedium.