| "but can anyone suggest how much risk is in these risks." Twenty years ago maybe this argument carried the day. Don't even consider using it today. The tooling, techniques, and skill are far higher than you could dream if you are not in this world. This is not quite the same thing we are talking about, but let me give you a different example. An obscure cross-site-scripting attack is no big deal, right? Well, courtesy of BeEF [1], if the XSS can be leveraged to get you to download a script, which is a low bar, BeEF can then be used to proxy web access in, allowing an attacker to lever up from "small XSS" to "crawling your intranet with the internal credentials of the compromised user". Yow! Do not ever count on difficulty of exploit as a defense anymore. In many cases the reason why these people aren't providing off-the-shelf exploits for this sort of thing isn't that it's too difficult to make practical, it is that in the security world it is now too trivial to be worth spelling out. Attacker capabilities (and pen testing capabilities) have skyrocketed in the past ten years, but the defense team still for the most part is operating like it's 1995 and the idea that a program might be used on a network is still like some sort of major revelation. (I'm on the defense side personally. It feels about like this: https://youtu.be/MPt7Kbj2YNM?t=2m11s In theory, I am powerful, in theory I control the field, in theory all the advantages should be mine, but....) [1]: http://beefproject.com/ |
I also wasn't making any comment about 'banking on difficulty of exploit', what I was asking for was relative risk. I think that all code is exploitable. The question I had was, is the exploitation of a particular UAF bug sufficiently easy that it outweighs the base risk of a new exploit being found. If I have finite resources, understanding where to apply them to improve risk is important.
The other responses have answered my question in some detail.