> 2) Once an exploit is added to the list of checks on Typhoon II and an > administrator or consultant determines his system to be vulnerable, he must > still wait for a patch. But you can provide work arounds or solutions that help mitigate the risk in the interim. Security is not just about patching holes. It's about taking the right steps to provide a holistic solution that prevents or negates risk. For example - those that followed best practices for IIS would not have been hit by Code Red - they would have removed the extension mapping. They'll also be invulnerable to Code Puce, Code Ochre and Rainbow when they hit the 'net. Or as another example some advice on how to configure a firewall properly will go a long way. If you have an Oracle TNS Listener vulnerable to overflow behind a firewall but allow incoming packets with a source port of 20 then we can hit it. Advice on prevneting this can be offered in the absence of a patch, and if followed, will prevent the risk not only to the Listener but also a whole slew of other issues lurking in the wings waiting to be discovered. > 3) The recent JRun advisory, I feel, gives up too much information. I'm > sure as I type this someone is working to figure the length of the host > header field needed to achieve the overflow. The JRun advisory was not a VNA. That was a normal full disclosure advisory something we will continue to do with or without the VNA. Cheers, David ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Thu May 30 2002 - 10:12:27 PDT