Hello Kost, > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Vlatko Kosturjak > Sent: Monday, March 08, 2010 4:54 PM > To: Jan-Oliver Wagner > Cc: [email protected] > Subject: Re: [Openvas-plugins] MS-RPC for GSoC > > Jan-Oliver Wagner wrote: > > On Samstag, 27. Februar 2010, Vlatko Kosturjak wrote: > >> OpenVAS was focusing too much on local checks recently. > > > > I disagree with this statement. > > > > Incresing the number of local security checks developed of course > > increases the fraction of local security checks based on the total > > number of NVTs. But this does not mean there are less remote checks. > > Not less remote checks, but not too much more as well. As you > said you disagree, I've made quick test just to check if > something is changed in the meantime that I wasn't aware of. > For example, tried to scan with latest plugin feed Windows > 2003 box without SP and Debian Etch (4.0r0). It did not find > following important vulnerabilities (amongst many others): > > http://www.microsoft.com/technet/security/Bulletin/MS03-026.mspx
This is a very old issue as you see, might have been lost from the set we inherited from Nessus for license reason. The focus now is on developing checks for the latest vulnerabilities. Probably, we should find time to get back and develop NASL's for some of the very old and important vulnerabilities. > http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx We already have remote check for this, for both MS08-067 and conficker. If you think there's a better different technique for doing this, please provide us more details. Openvas-plugins is the place for such comments. > http://www.microsoft.com/technet/security/Bulletin/MS09-001.mspx We'll look into this. > > http://wiki.debian.org/SSLkeys > http://lists.debian.org/debian-security-announce/2007/msg00047.html > > These all are quite old distros and well known (and old) > vulnerabilities. Currently, OpenVAS *remote* checks cannot > detect that. > And ALL of them are possible to implement remotely and anonymously. > > > In fact, we try the maximum possible and if you know of > missing remote > > checks, please forward details to this list! > > I think paper at: > http://www.openvas.org/articles-studies.html > goes much more deeper and also proves my point and I guess > you read it already. The paper I think mostly pointed out the old remote checks that are missing. Because of the license concerns, number of those checks were probably removed. > > Also, refer to IRC archive at: > http://www.linux.hr/openvas/archive/index.php?d=2010-02-10#msg38889 > > > Of course we can't easily develop security checks for > products where > > the vendors refuse to cooperate. Greenbone is currently working on > > partnerships so that we get respective support. > > This is not easy because vendor's requirements conflict > with our wish > > to publish the tests under GNU GPL. > > I don't believe that Debian doesn't let you do it? :) > > I understand that some feature is developed where commercial > interest is present. And that is good. I think it's also good > to have such features and OpenVAS should continue that, but I > think OpenVAS should also focus more on it's core feature > which is vulnerability identification. > > I think everyone would agree, all those bells and whistles > added to OpenVAS are losing its value without realiable > vulnerability identification. As soon as we accept the > problem (or better to say challenge?), it will be the first > step in fixing it. I think OpenVAS has come a long way in terms of vulnerability detection too, in recent times. Of course improvement is always needed. It is a community effort after all, if there are missing checks, please post them to openvas-plugins, including any research findings if some effort has already gone in that direction. We can have a kind of track sheet where all these requests are logged and tracked. We'll put in our best efforts to take them for implementation. Thanks, Chandra. _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
