Vendors fear disclosing vulnerability details. I’m not entirely sure why that is. I believe the general idea is that if they disclose too much information attackers will quickly develop an exploit. This chain of thought doesn’t make all too much sense. Some organizations claim they can produce an exploit in as little as 2 hours by patch diffing. Personally, I’m not sure how they do it in 2 hours (depending on how they measure). I think 1-2 days is certainly enough time to triage, reverse, target, and successfully DoS a vuln in an average complexity bundled series of updates on a MS Patch Tuesday. The exploit can then be developed somewhere between 5 minutes and 6 months after that. So by holding out on critical details the vendors are only gaining a day or two.
Not gaining much isn’t a problem unless they’re losing something, and I think they are. Foremost, by not disclosing vuln details we’re lowering the dialog. Rather than articulating a concise problem in software the discussion becomes about nebulous memory corruption and an almost arbitrary severity rating. For security professionals, the discussion needs to be more than a Cliff Note summary. Until that happens software developers are going to continue to misundertand code defects and organizations will misinterpret risk.
Second, signature based IDS/IPS is crap. I don’t think it has to be crap but the basic process is flawed. Signature writers far too often use a particular exploit as a basis for their signature. Since the signature identifies a particular exploit, it doesn’t (in general) accurately identify variant exploits for the same vulnerability. Some heuristic systems strive to identify the truly generic exploit by things like NOP sleds, shellcode, or obscenely large data fields but they’re plagued by problems. In my opinion, if the discussion transitions from exploits to vulnerability signature based IDS will do much better. All exploits for the same bug have to share some level of similarity. That similarity is the thing that makes the exploit. If we look at a recent vulnerability (MS09-013) we see the Snort Rule:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”WEB-CLIENT WinHTTP integer wrap buffer overflow attempt”; sid:15462; gid:3; rev:1; classtype:misc-attack; reference:cve,2009-0086; reference:url,www.microsoft.com/technet/security/bulletin/MS09-013.mspx; metadata: engine shared, soid 3|15462, service http, policy balanced-ips drop, policy security-ips drop;)
As you can see, the rule has little to do with the actual vulnerability — a hex encoded integer less than 0 in as the chunk size in an HTTP message. There are numerous possibily difficulties with detecting the actual vulnerability. At the very least, it requires a basic regular expression and at worst you’re moving toward deep packet inspection. To me though, it makes much more sense to start talking about the difficulties of properly detecting the vulnerability rather than doing complex log analysis in hopes of tieing poorly contructed rules into something useful.
While the IDS industry is writing the signatures I don’t think the problem currently rests with them. No single organization can be expected to reasonably maintain expertise around the entire security field. The IDS orgs are given poor vulnerability descriptions so they write poor signatures. Because we have poor signatures, one off exploits are missed or (more likely in the above case) the rule is so generic it’s disabled or ignored. This results in failed security monitoring and possibly successful attacks.