"Vulnerability, Exploit, Consequences"
By davew on Mar 19, 2007
Recently my pal Gilles blogged about how there's no such thing as a "zero-day vulnerability". Strictly, he's right - unless you consider the "zero day" to be the day the vulnerability was inadvertantly incorporated into the as-shipped code.
His posting also reminded me of an interesting presentation I saw last month (at the same conference where Robin Wilton spoke on identity management in civil-contingency situations, which is a thought-provoking subject itself, but I digress...), where a chap from Microsoft discussed "the evolution of the exploit".
He expounded at great length on how Windows, Office, etc exploits are found in the wild, how they are (and their degree of propagation is) analysed back at Microsoft, and what happens in the production and testing of a Microft patch to plug the hole. However, he missed a trick.
Exploits are naturally qualified by their severity - ie, the consequences of what can happen if they are successfully executed. However, in environments which support a fine-grained privilege model, the consequences can vary widely depending on how the environment in which the application runs is set up.
Consider a couple of concrete examples. In Solaris 10, the NFS daemon has precisely one privilege, which was tailor-made for it; sys_nfsd. Therefore, if a vulnerability - say, a buffer overflow - was found in the nfsd code such that an attacker could use it to push some code to a buffer which would then fork a shell with the uid at which nfsd usually runs (this commonly being root), they would have trouble using such an exploit on a Solaris 10 system, as nfsd doesn't have the privilege to call fork(). Thus, the consequences for exploit use are different between Solaris 10 and other platforms.
Similarly, consider Apache. We have a Blueprint which gives details of how to set Apache up such that it only has the privileges it needs to run, read its code and config files, write its logfiles and bind listeners to low-numbered ports such as 80/tcp and 443/tcp; further, it could be set up with an SMF monitor which would effectively spot incorrect operation and restart the service. Being able to grant the net_priv_addr privilege to the owner of the Apache process means that Apache never has to even start up as root in order to bind its listeners.
So, an attacker finding an exploit against Apache might be able to overflow a buffer and fork a shell (since Apache's operation requires it to be able to spawn more copies of itself using fork() in order to handle varying load) as the user running Apache, but he wouldn't be able to see what other processes were running on the system, for example. Also, once the exploited Apache instance ceases to behave in ways expected of it, SMF could restart it and thus throw the attacker off the system.
Granted, the attacker would still be able to re-use his exploit against the restarted Apache service to get his rather unprivileged shell back; but SMF could not only re-start the service again but also determine that Apache was misbehaving too frequently, and put the service into maintenance state. AN SNMP agent might then alert an admin.
Thus, the worst thing that a Bad Guy with a successful exploit up his sleeve would be able to do, against a well-configured system, would be to instigate a DoS attack - and even that is if the nature of the service's operation model and its SMF profile will let him.
While the likes of CVE already include some details of what the consequences of a successful attack are, these details need to be extended to differentiate not only by platform, but also by privilege profile and monitoring / restarting system. Over to you, Mitre et al - while NIST's CVSS has the ability to manipulate vulnerability scores based on admin-perceived risk, there's always room for improvement :-)