From bchandra at secpod.com Wed Apr 1 07:47:55 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 1 Apr 2009 11:17:55 +0530 Subject: [Openvas-plugins] [Openvas-discuss] Conficker worm detection -OpenVAS plugins In-Reply-To: <200903312146.19680.timb@nth-dimension.org.uk> References: <200903312146.19680.timb@nth-dimension.org.uk> Message-ID: > *snip* >> to detect patch condition of MS08-067. The plugin 900055 requires SMB >> credentials and verifies if the required hotfix is installed through >> Windows Registry and verifying the updated file versions. The plugin 900056 >> is a Proof of Concept exploit that tries to crash the server service >> (safe_checks has to be disabled). This can work on anonymous login >> credentials if the target system allows anonymous login (Windows 2000 by >> default allows anonymous login). The plugin checks the RPC response status >> of an un-patched system. > This is all true but it doesn't really go far enough since it only looks for > the original vulnerability and not Conficker. I started working on a check > for Conficker last night and got someway before I noticed a glaring problem > but nothing which at this stage is complete. I've attached the plugin in > rough form here if anyone wants to take it up. We'll try and test this on Win2K and XP systems. I think slight modifications to the request to ntrPathCanonicalize. Unless the target system allows, is there a means to check the system anonymously? Other scanners seem to claim that detection is anonymous. I couldn't think of a way. I was looking at writing a NASL to directly check for Conficker infected systems through registry or files etc., but there looks to be too much of randomness in the worm's behavior. > The problems I've had so far > is the lack of support for non-clear text authentication in the OpenVAS SMB > implementation which is limiting my ability to test here, as I only have > 2003/Vista systems to play with. I've diverted to start working on that and > will be sending another email shortly to openvas-devel regarding this. The current smb_nt.inc only provides clear text based authentication. nasl_crypto was removed from the Nessus and I think re-introduced in a different form. Hence the proposal to integrate Samba to get NTLM based auth. However, introducing the crypto code would be very useful as it is very difficult to achieve the SMB packet crafting facility through SAMBA exposed API's. The only issue introducing crypto functionality would be to keep it updated as the changes in the OS comes in. Another difficulty is when the target OS enforces SMB signing and encryption, need to support this as well. Thanks, Chandra. www.secpod.com From timb at nth-dimension.org.uk Thu Apr 2 02:05:41 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 2 Apr 2009 01:05:41 +0100 Subject: [Openvas-plugins] [Openvas-discuss] Conficker worm detection -OpenVAS plugins In-Reply-To: References: <200903312146.19680.timb@nth-dimension.org.uk> Message-ID: <200904020105.44488.timb@nth-dimension.org.uk> Chandra, Summarising my response to what you asked/stated yesterday on IRC (you'd already logged off for the day). The payload I submitted to you guys for MS08-067 is not the same as the one used by nmap for ms08-067, nmap actuaally uses a different payload developed later by one of my colleagues which is available from http://labs.portcullis.co.uk/. Moreover, neither are the same as the payload nmap uses for the Conficker check, since this validates whether Conficker's own custom patch for MS08-067 has been applied. Conficker's patch behaves differently from Microsoft's. The conficker NASL I sent round generates the nmap payload to test for Conficker but I was troubled by a) SMB authentication problems and b) as I note below I haven't had a chance to run it against a compromised system. We may be able to use my first payload to detect Conficker but for that... I/we need to run it against a Conficker infected box so that we see how it responds... I will ask around but as I have some good contacts in the AV / malware community. Indeed, we probably need to do that anyway so we can see how the SMB function in openvas decode the respond - smb_rev() in particular. Cheers, Tim -- Tim Brown From bchandra at secpod.com Thu Apr 2 06:56:49 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 2 Apr 2009 10:26:49 +0530 Subject: [Openvas-plugins] [Openvas-discuss] Conficker worm detection -OpenVAS plugins In-Reply-To: <200904020105.44488.timb@nth-dimension.org.uk> References: <200903312146.19680.timb@nth-dimension.org.uk> <200904020105.44488.timb@nth-dimension.org.uk> Message-ID: Hello Tim, -----Original Message----- From: Tim Brown [mailto:timb at nth-dimension.org.uk] Sent: Thursday, April 02, 2009 5:36 AM To: openvas-discuss at wald.intevation.org Cc: Chandrashekhar B; Openvas-plugins at wald.intevation.org Subject: Re: [Openvas-discuss] [Openvas-plugins] Conficker worm detection -OpenVAS plugins > The payload I submitted to you guys for MS08-067 is not the same as the one > used by nmap for ms08-067, nmap actuaally uses a different payload developed > later by one of my colleagues which is available from > http://labs.portcullis.co.uk/. I overlooked, just saw the reference in NMAP page to the above link and assumed so. > We may be able to use my first payload to detect Conficker but for that... > I/we need to run it against a Conficker infected box so that we see how it > responds... I will ask around but as I have some good contacts in the AV / > malware community. Indeed, we probably need to do that anyway so we can see > how the SMB function in openvas decode the respond - smb_rev() in > particular. That'll be useful. Thanks, Chandra. From bchandra at secpod.com Thu Apr 2 15:03:10 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 2 Apr 2009 18:33:10 +0530 Subject: [Openvas-plugins] Standardize Script Families for NVT - CR #23 Message-ID: I have updated the CR including new families that are used and also some family names which were missing. http://www.openvas.org/openvas-cr-23.html Also, I was thinking we should have a separate family for all Plugins that detect, basically inventory Plugins. I am looking at 'Service detection' as the family name. Any concerns with categorizing all Plugins into one family? Thanks, Chandra. From timb at nth-dimension.org.uk Thu Apr 2 15:33:25 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 2 Apr 2009 14:33:25 +0100 Subject: [Openvas-plugins] Standardize Script Families for NVT - CR #23 In-Reply-To: References: Message-ID: <200904021433.27142.timb@nth-dimension.org.uk> On Thursday 02 April 2009 14:03:10 Chandrashekhar B wrote: > I have updated the CR including new families that are used and also some > family names which were missing. > > http://www.openvas.org/openvas-cr-23.html > > Also, I was thinking we should have a separate family for all Plugins that > detect, basically inventory Plugins. I am looking at 'Service detection' as > the family name. Any concerns with categorizing all Plugins into one > family? Sounds good to me. Personally I don't consider them a vulnerability per se but from a asset management perspective it is probably useful to know what software each system is running. Tim -- Tim Brown From goran.licina at lss.hr Fri Apr 3 22:56:02 2009 From: goran.licina at lss.hr (Goran Licina) Date: Fri, 3 Apr 2009 22:56:02 +0200 Subject: [Openvas-plugins] New plugin development team Message-ID: <23A625424CB52E40AEBDEBB1C59C0B75FE2201@vlasta.lss-net.lss.hr> Hi, We decided to work on following plugins (for a start): os_fingerprint.nasl yahoo_msg_running.nasl Please let us know if someone else is working on these so we can pick some other plugins. Thanks, Goran Licina -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb ________________________________ From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Goran Licina Sent: Tuesday, March 31, 2009 3:22 PM To: Openvas-plugins at wald.intevation.org Subject: Re: [Openvas-plugins] New plugin development team Thank you for your suggestions. We will check these plugins and let you know on which plugins we will start working. Best regards, Goran Licina -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org on behalf of Chandrashekhar B Sent: Mon 3/30/2009 2:40 PM To: Goran Licina; Openvas-plugins at wald.intevation.org Subject: Re: [Openvas-plugins] New plugin development team Thanks for offering to help! We had started on this exercise of reworking the missing Plugins and completed some of them. As of now, the following Plugins are missing, apcnisd_detect.nasl cisco_ids_manager_detect.nasl e107_detect.nasl invision_power_board_detect.nasl ms_telnet_overflow.nasl msrpc_dcom2.nasl openca_html_injection.nasl os_fingerprint.nasl phorum_detect.nasl php_nuke_installed.nasl phpmyfaq_detect.nasl postnuke_detect.nasl rsync_modules.nasl serendipity_detect.nasl snmp_sysDesc.nasl sybase_detect.nasl sybase_easerver_detect.nasl webcalendar_detect.nasl webmirror.nasl www_too_long_url.nasl xoops_detect.nasl yahoo_msg_running.nasl You could take some of these for development. The way to go about would be, check the Plugins that are depending on the above and analyze what they expect. In general, some missing KB item setting has to be done in the way the dependent Plugins expect. Thanks, Chandra. ________________________________________ From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Goran Licina Sent: Monday, March 30, 2009 2:43 PM To: Openvas-plugins at wald.intevation.org Subject: [Openvas-plugins] New plugin development team Hi, in agreement with Mr. Jan-Oliver Wagner and Mr. Vlatko Kosturjak we gathered a team for developing new OpenVAS plugins. Since we would like to start with writing plugins as soon as possible, Mr. Wagner suggested that we could for a start develop missing plugins that cause other OpenVAS plugins not to work properly. So, can You please tell us on which plugin(s) we can start working on and what is the common procedure to do that? Best regards, Goran Licina -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090403/5669060b/attachment.htm From michael.wiegand at intevation.de Mon Apr 6 14:07:36 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 6 Apr 2009 14:07:36 +0200 Subject: [Openvas-plugins] New plugin development team In-Reply-To: <23A625424CB52E40AEBDEBB1C59C0B75FE2201@vlasta.lss-net.lss.hr> References: <23A625424CB52E40AEBDEBB1C59C0B75FE2201@vlasta.lss-net.lss.hr> Message-ID: <20090406120736.GB30808@intevation.de> * Goran Licina [ 3. Apr 2009]: > Hi, > > We decided to work on following plugins (for a start): > > os_fingerprint.nasl Just my two cents: I think OS fingerprinting is something we should use nmap for. nmap does an excellent job in that area and IMHO it would be a waste of time to reinvent the wheel here. Nmap adoption is currently hindered by the fact that we need to spawn a separate nmap for each host since there is currently no practical way to share information between host scans or on network level. This is something we would like to address, but I don't think we have the necessary resources for that in the short term. If we were to develop an NASL based OS detection in the meantime, we should at the very least make sure to use nmaps OS fingerprint DB (available at http://nmap.org/data/nmap-os-fingerprints, GPL). Any thoughts on this issue? Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090406/e9c457d9/attachment.pgp From timb at nth-dimension.org.uk Mon Apr 6 16:58:17 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 6 Apr 2009 15:58:17 +0100 Subject: [Openvas-plugins] Fwd: [Openvas-devel] Dropping NASL_LEVEL Message-ID: <200904061558.19180.timb@nth-dimension.org.uk> Cross posted to openvas-plugins as it makes more sense to ask the question here. My personal view is that we should start cleaning out the legacy code from the scripts where we can do so safely, this is a good example of something that can easily be retired. Cheers, Tim ---------- Forwarded Message ---------- Subject: [Openvas-devel] Dropping NASL_LEVEL Date: Monday 06 April 2009 From: "Jan-Oliver Wagner" To: openvas-devel at wald.intevation.org Hi, I wonder whether we should simply drop NASL_LEVEL entirely. Which in fact means that all the if-clauses used in .nasl-skripts can be resolved. OpenVAS started with a level 2300. Also we introduced OPENVAS_NASL_LEVEL because we do not want to mix up with Nessus. So, for OpenVAS users the NASL_LEVEL conditionals are always true anyway. I guess, this primarily concerns those who try to keep NASL-Skripts compatible with Nessus. Any opinion from your side on this idea to drop the NASL_LEVEL. Would it cause problems? Why not keep NASL_LEVEL? Well, it is confusing to new users, comsumes code lines and adds to complexity of some scripts. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel ------------------------------------------------------- -- Tim Brown From jan-oliver.wagner at intevation.de Tue Apr 7 11:59:43 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 7 Apr 2009 10:59:43 +0100 Subject: [Openvas-plugins] Fwd: [Openvas-devel] Dropping NASL_LEVEL In-Reply-To: <200904061558.19180.timb@nth-dimension.org.uk> References: <200904061558.19180.timb@nth-dimension.org.uk> Message-ID: <200904071159.45227.jan-oliver.wagner@intevation.de> On Montag, 6. April 2009, Tim Brown wrote: > Cross posted to openvas-plugins as it makes more sense to ask the question > here. true. > My personal view is that we should start cleaning out the legacy code from the > scripts where we can do so safely, this is a good example of something that > can easily be retired. :-) Below is the list of NASL_LEVEL use. Thomas: quite a number comes from your debian scripts. Should we simply remove the code lines or do you prefer to update yourself (via your automized processing) ? Anyone else out there interested to assist elimination? (I will start now) Best Jan $ find . -name "*.nasl" | xargs grep NASL_LEVEL ./scripts/deb_1018_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_779_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/firewall_detect.nasl:if ( NASL_LEVEL < 2205 ) exit(0); ./scripts/deb_1046_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_781_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200804_20.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200606_21.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_639_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/nmap.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/nmap.nasl: if (NASL_LEVEL > 2200) ./scripts/nmap.nasl: if (NASL_LEVEL > 2200) ./scripts/nmap.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) ./scripts/deb_1017_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200701_04.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_868_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1336_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1681_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/http_ids_evasion.nasl:if ( NASL_LEVEL >= 3000 ) exit(0); ./scripts/freebsd_firefox18.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1444_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/portscan-strobe.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/portscan-strobe.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) ./scripts/deb_1534_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200703_21.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200608_04.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200703_04.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200711_23.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1356_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/amap.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/amap.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) ./scripts/sambar_xss.nasl: if (NASL_LEVEL >= 2200) ./scripts/deb_1649_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200808_03.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1304_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_810_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_firefox25.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200703_08.nasl: if(NASL_LEVEL>=2191) { ./scripts/poptop_negative_read.nasl:pptp_vendor = mkword(NASL_LEVEL) + # Firmware revision ./scripts/glsa_200711_30.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1489_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1669_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_ethereal7.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1283_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1504_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1118_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200802_04.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1396_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1051_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1097_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200604_12.nasl: if(NASL_LEVEL>=2191) { ./scripts/hydra_options.nasl: if ( NASL_LEVEL < 2201 ) return logins; # fwrite broken ./scripts/deb_1570_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1184_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/portbunny.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/portbunny.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) ./scripts/freebsd_firefox22.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200503_30.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200606_12.nasl: if(NASL_LEVEL>=2191) { ./scripts/doublecheck_std_services.nasl:if (NASL_LEVEL < 2200 ) exit(0); ./scripts/http_w98_devname_dos.nasl: if (NASL_LEVEL >= 2200 ) script_cve_id("CVE-2001-0386", "CVE-2001-0493", "CVE-2001-0391", "CVE-2001-0558", "CVE-2002-0200", "CVE-2000-0168", "CVE-2003-0016", "CVE-2001-0602"); ./scripts/glsa_200705_19.nasl: if(NASL_LEVEL>=2191) { ./scripts/gather-package-list.nasl: if(NASL_LEVEL>=2300){ ./scripts/glsa_200811_01.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1103_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_firefox26.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200709_15.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1535_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1082_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_925_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200701_02.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200710_02.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200811_05.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1532_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_423_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1671_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1506_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1120_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_922_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200608_02.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1233_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200505_03.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1503_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_phpbb9.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1485_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200503_10.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1184_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1392_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200712_23.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1070_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_php51.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_ethereal5.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1044_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200604_17.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1134_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_936_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/snmpwalk_portscan.nasl:if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/snmpwalk_portscan.nasl:if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/deb_1018_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_779_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1067_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1607_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/scan_info.nasl: if ( ! defined_func("pread") && NASL_LEVEL >= 2202 ) ./scripts/scan_info.nasl: version = "Unknown (NASL_LEVEL=" + NASL_LEVEL + ")"; ./scripts/deb_1401_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ids_evasion.nasl:if ( NASL_LEVEL >= 3000 ) exit(0); ./scripts/deb_866_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/unknown_services.nasl: if (NASL_LEVEL >= 3000) ./scripts/glsa_200510_25.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_firefox34.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1506_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200805_18.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1444_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1534_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_linux-flashplugin2.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200608_03.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_358_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1503_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200605_09.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1485_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1621_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/pnscan.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run ./scripts/pnscan.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) ./scripts/deb_921_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/freebsd_firefox24.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_442_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1049_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1484_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1615_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200604_18.nasl: if(NASL_LEVEL>=2191) { ./scripts/smb_nt_ms02-005.nasl: if ( NASL_LEVEL >= 2191 ) script_bugtraq_id(10473, 8565, 9009, 9012, 9013, 9014, 9015, 9182, 9663, 9798, 12477, 12475, 12473, 12530, 13123, 13117, 13120); ./scripts/smb_nt_ms02-005.nasl: if ( NASL_LEVEL >= 2191 ) script_cve_id("CAN-2003-0814", "CAN-2003-0815", "CAN-2003-0816", "CAN-2003-0817", "CAN-2003-0823", "CAN-2004-0549", "CAN-2004-0566", "CAN-2003-1048", "CAN-2001-1325", "CAN-2001-0149", "CAN-2001-0727", "CAN-2001-0875", "CVE-2001-1325", "CVE-2001-0149", "CVE-2001-0727", "CVE-2001-0875", "CVE-2001-0339", "CVE-2001-0002", "CAN-2002-0190", "CVE-2002-0026", "CAN-2003-1326", "CVE-2002-0027", "CVE-2002-0022", "CAN-2003-1328", "CAN-2002-1262", "CAN-2002-0193", "CAN-1999-1016", "CVE-2003-0344", "CAN-2003-0233", "CAN-2003-0309", "CAN-2003-0113", "CAN-2003-0114", "CAN-2003-0115", "CAN-2003-0116", "CAN-2003-0531", "CAN-2003-0809", "CAN-2003-0530", "CAN-2003-1025", "CAN-2003-1026", "CAN-2003-1027", "CAN-2005-0554", "CAN-2005-0555"); ./scripts/deb_1687_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200812_17.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_698_2.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_697_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_699_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0002.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2008_0787.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0001.nasl: if(NASL_LEVEL>=2191) { ./scripts/ovcesa2009_0002.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sa_2009_001.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1697_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1696_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sa_2009_003.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_002.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_001a.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0015.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1707_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_001b.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0016.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sa_2009_002.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_001.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_708_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/mdksa_2009_023.nasl: if(NASL_LEVEL>=2191) { ./scripts/mdksa_2009_020.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_713_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_710_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_003.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_712_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_711_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ovcesa2009_0001_01.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_004.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sa_2009_010.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_005.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_726_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_727_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0313.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_731_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/glsa_200903_23.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_006.nasl: if(NASL_LEVEL>=2191) { ./scripts/ovcesa2009_0313.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_732_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_736_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0394.nasl: if(NASL_LEVEL>=2191) { ./scripts/suse_sr_2009_007.nasl: if(NASL_LEVEL>=2191) { ./scripts/deb_1749_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/ubuntu_742_1.nasl: if(NASL_LEVEL>=2191) { ./scripts/RHSA_2009_0392.nasl: if(NASL_LEVEL>=2191) { -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Tue Apr 7 13:41:34 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 7 Apr 2009 17:11:34 +0530 Subject: [Openvas-plugins] Current list of missing dependencies Message-ID: NASL: snmp_settings.nasl rexecd.nasl cvs_pserver_heap_overflow.nasl ping_host.nasl apcnisd_detect.nasl cisco_ids_manager_detect.nasl e107_detect.nasl macosx_SecUpd20041202.nasl mandrake_MDKSA-2004-065.nasl msrpc_dcom2.nasl ms_telnet_overflow.nasl openca_html_injection.nasl os_fingerprint.nasl php_nuke_installed.nasl postnuke_detect.nasl putty_version_check.nasl rsync_modules.nasl serendipity_detect.nasl smb_enum_services.nasl smb_nativelanman.nasl snmp_sysDesc.nasl sybase_detect.nasl webcalendar_detect.nasl webmirror.nasl www_too_long_url.nasl xoops_detect.nasl yahoo_msg_running.nasl INC's: smb_func.inc smb_file_funcs.inc byte_func.inc sunrpc_func.inc Thanks, Chandra. From goran.licina at lss.hr Tue Apr 7 15:58:04 2009 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Tue, 7 Apr 2009 15:58:04 +0200 Subject: [Openvas-plugins] New plugin development team References: <23A625424CB52E40AEBDEBB1C59C0B75FE2201@vlasta.lss-net.lss.hr> <20090406120736.GB30808@intevation.de> Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C04CC1A@vlasta.lss-net.lss.hr> Hi, We already started working on ICMP-based OS fingerpinting, so we would like to finish it, just to see if it will work fine (since we are still beginners in NASL :). We also considered using nmap so we could, after we finish this version, make an improved version that uses nmap. Regards, Goran Licina -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb -----Original Message----- From: Michael Wiegand [mailto:michael.wiegand at intevation.de] Sent: Monday, April 06, 2009 2:08 PM To: Goran Li?ina Cc: Openvas-plugins at wald.intevation.org Subject: Re: Re: [Openvas-plugins] New plugin development team * Goran Licina [ 3. Apr 2009]: > Hi, > > We decided to work on following plugins (for a start): > > os_fingerprint.nasl Just my two cents: I think OS fingerprinting is something we should use nmap for. nmap does an excellent job in that area and IMHO it would be a waste of time to reinvent the wheel here. Nmap adoption is currently hindered by the fact that we need to spawn a separate nmap for each host since there is currently no practical way to share information between host scans or on network level. This is something we would like to address, but I don't think we have the necessary resources for that in the short term. If we were to develop an NASL based OS detection in the meantime, we should at the very least make sure to use nmaps OS fingerprint DB (available at http://nmap.org/data/nmap-os-fingerprints, GPL). Any thoughts on this issue? Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Tue Apr 7 17:56:42 2009 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 07 Apr 2009 11:56:42 -0400 Subject: [Openvas-plugins] Fwd: [Openvas-devel] Dropping NASL_LEVEL In-Reply-To: <200904071159.45227.jan-oliver.wagner@intevation.de> References: <200904061558.19180.timb@nth-dimension.org.uk> <200904071159.45227.jan-oliver.wagner@intevation.de> Message-ID: <49DB77BA.8090008@securityspace.com> Jan-Oliver Wagner wrote: > Thomas: quite a number comes from your debian scripts. > Should we simply remove the code lines or do you prefer > to update yourself (via your automized processing) ? I've updated the debian scripts to remove the references I'd love it if it were all automated, but alas, it isn't. That being said, I think the local security checks we've provided make most sense if we update them, because I'd just as soon ensure that we are running the same versions as in OpenVAS whenever possible. The only scripts that _really_ need to be updated by us are the Centos ones (ovcesa*) because they are 100% automatically generated. Any change you make might get overwritten by us if an advisory update comes out, so they really ought to be updated at our end. > > Anyone else out there interested to assist elimination? > (I will start now) > If you can work on the non-local security checks, I'll arrange to have ours cleaned up. Thomas > Best > > Jan > > > $ find . -name "*.nasl" | xargs grep NASL_LEVEL > ./scripts/deb_1018_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_779_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/firewall_detect.nasl:if ( NASL_LEVEL < 2205 ) exit(0); > ./scripts/deb_1046_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_781_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200804_20.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200606_21.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_639_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/nmap.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/nmap.nasl: if (NASL_LEVEL > 2200) > ./scripts/nmap.nasl: if (NASL_LEVEL > 2200) > ./scripts/nmap.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) > ./scripts/deb_1017_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200701_04.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_868_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1336_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1681_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/http_ids_evasion.nasl:if ( NASL_LEVEL >= 3000 ) exit(0); > ./scripts/freebsd_firefox18.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1444_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/portscan-strobe.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/portscan-strobe.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) > ./scripts/deb_1534_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200703_21.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200608_04.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200703_04.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200711_23.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1356_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/amap.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/amap.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) > ./scripts/sambar_xss.nasl: if (NASL_LEVEL >= 2200) > ./scripts/deb_1649_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200808_03.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1304_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_810_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_firefox25.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200703_08.nasl: if(NASL_LEVEL>=2191) { > ./scripts/poptop_negative_read.nasl:pptp_vendor = mkword(NASL_LEVEL) + # Firmware revision > ./scripts/glsa_200711_30.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1489_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1669_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_ethereal7.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1283_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1504_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1118_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200802_04.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1396_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1051_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1097_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200604_12.nasl: if(NASL_LEVEL>=2191) { > ./scripts/hydra_options.nasl: if ( NASL_LEVEL < 2201 ) return logins; # fwrite broken > ./scripts/deb_1570_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1184_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/portbunny.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/portbunny.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) > ./scripts/freebsd_firefox22.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200503_30.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200606_12.nasl: if(NASL_LEVEL>=2191) { > ./scripts/doublecheck_std_services.nasl:if (NASL_LEVEL < 2200 ) exit(0); > ./scripts/http_w98_devname_dos.nasl: if (NASL_LEVEL >= 2200 ) script_cve_id("CVE-2001-0386", "CVE-2001-0493", "CVE-2001-0391", "CVE-2001-0558", "CVE-2002-0200", "CVE-2000-0168", "CVE-2003-0016", "CVE-2001-0602"); > ./scripts/glsa_200705_19.nasl: if(NASL_LEVEL>=2191) { > ./scripts/gather-package-list.nasl: if(NASL_LEVEL>=2300){ > ./scripts/glsa_200811_01.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1103_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_firefox26.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200709_15.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1535_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1082_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_925_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200701_02.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200710_02.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200811_05.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1532_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_423_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1671_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1506_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1120_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_922_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200608_02.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1233_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200505_03.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1503_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_phpbb9.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1485_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200503_10.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1184_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1392_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200712_23.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1070_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_php51.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_ethereal5.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1044_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200604_17.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1134_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_936_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/snmpwalk_portscan.nasl:if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/snmpwalk_portscan.nasl:if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/deb_1018_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_779_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1067_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1607_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/scan_info.nasl: if ( ! defined_func("pread") && NASL_LEVEL >= 2202 ) > ./scripts/scan_info.nasl: version = "Unknown (NASL_LEVEL=" + NASL_LEVEL + ")"; > ./scripts/deb_1401_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ids_evasion.nasl:if ( NASL_LEVEL >= 3000 ) exit(0); > ./scripts/deb_866_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/unknown_services.nasl: if (NASL_LEVEL >= 3000) > ./scripts/glsa_200510_25.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_firefox34.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1506_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200805_18.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1444_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1534_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_linux-flashplugin2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200608_03.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_358_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1503_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200605_09.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1485_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1621_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/pnscan.nasl: if (NASL_LEVEL < 2181) exit(0); # Cannot run > ./scripts/pnscan.nasl:if (NASL_LEVEL < 2181 || ! defined_func("pread") || ! defined_func("get_preference")) > ./scripts/deb_921_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/freebsd_firefox24.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_442_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1049_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1484_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1615_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200604_18.nasl: if(NASL_LEVEL>=2191) { > ./scripts/smb_nt_ms02-005.nasl: if ( NASL_LEVEL >= 2191 ) script_bugtraq_id(10473, 8565, 9009, 9012, 9013, 9014, 9015, 9182, 9663, 9798, 12477, 12475, 12473, 12530, 13123, 13117, 13120); > ./scripts/smb_nt_ms02-005.nasl: if ( NASL_LEVEL >= 2191 ) script_cve_id("CAN-2003-0814", "CAN-2003-0815", "CAN-2003-0816", "CAN-2003-0817", "CAN-2003-0823", "CAN-2004-0549", "CAN-2004-0566", "CAN-2003-1048", "CAN-2001-1325", "CAN-2001-0149", "CAN-2001-0727", "CAN-2001-0875", "CVE-2001-1325", "CVE-2001-0149", "CVE-2001-0727", "CVE-2001-0875", "CVE-2001-0339", "CVE-2001-0002", "CAN-2002-0190", "CVE-2002-0026", "CAN-2003-1326", "CVE-2002-0027", "CVE-2002-0022", "CAN-2003-1328", "CAN-2002-1262", "CAN-2002-0193", "CAN-1999-1016", "CVE-2003-0344", "CAN-2003-0233", "CAN-2003-0309", "CAN-2003-0113", "CAN-2003-0114", "CAN-2003-0115", "CAN-2003-0116", "CAN-2003-0531", "CAN-2003-0809", "CAN-2003-0530", "CAN-2003-1025", "CAN-2003-1026", "CAN-2003-1027", "CAN-2005-0554", "CAN-2005-0555"); > ./scripts/deb_1687_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200812_17.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_698_2.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_697_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_699_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0002.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2008_0787.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0001.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ovcesa2009_0002.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sa_2009_001.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1697_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1696_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sa_2009_003.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_002.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_001a.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0015.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1707_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_001b.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0016.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sa_2009_002.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_001.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_708_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/mdksa_2009_023.nasl: if(NASL_LEVEL>=2191) { > ./scripts/mdksa_2009_020.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_713_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_710_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_003.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_712_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_711_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ovcesa2009_0001_01.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_004.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sa_2009_010.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_005.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_726_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_727_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0313.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_731_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/glsa_200903_23.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_006.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ovcesa2009_0313.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_732_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_736_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0394.nasl: if(NASL_LEVEL>=2191) { > ./scripts/suse_sr_2009_007.nasl: if(NASL_LEVEL>=2191) { > ./scripts/deb_1749_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/ubuntu_742_1.nasl: if(NASL_LEVEL>=2191) { > ./scripts/RHSA_2009_0392.nasl: if(NASL_LEVEL>=2191) { > From eric at nixwizard.net Tue Apr 7 18:03:19 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Tue, 7 Apr 2009 09:03:19 -0700 Subject: [Openvas-plugins] New plugin development team In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C04CC1A@vlasta.lss-net.lss.hr> References: <23A625424CB52E40AEBDEBB1C59C0B75FE2201@vlasta.lss-net.lss.hr> <20090406120736.GB30808@intevation.de> <8A02A3DF683DEE42BE73187F4CA4444C04CC1A@vlasta.lss-net.lss.hr> Message-ID: <5792267e0904070903h6bd3e66fh748af67c816d7827@mail.gmail.com> 2009/4/7 Goran Li?ina : > Hi, > > We already started working on ICMP-based OS fingerpinting, so we would like to finish it, just to see if it will work fine (since we are still beginners in NASL :). We also considered using nmap so we could, after we finish this version, make an improved version that uses nmap. > > Regards, > > Goran Licina > I second the piggybacking off nmap approach... there's really no reason to reinvent the wheel here, right? Eric From timb at nth-dimension.org.uk Tue Apr 7 19:29:04 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 7 Apr 2009 18:29:04 +0100 Subject: [Openvas-plugins] New plugin development team In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C04CA58@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C04CA58@vlasta.lss-net.lss.hr> Message-ID: <200904071829.05708.timb@nth-dimension.org.uk> On Monday 30 March 2009 10:13:19 Goran Li?ina wrote: > in agreement with Mr. Jan-Oliver Wagner and Mr. Vlatko Kosturjak we > gathered a team for developing new OpenVAS plugins. Since we would like to > start with writing plugins as soon as possible, Mr. Wagner suggested that > we could for a start develop missing plugins that cause other OpenVAS > plugins not to work properly. Sounds great, welcome aboard! Hehe, I would love to see a working SMB implementation (maybe a port of Core's Impacket library) but perhaps that's a little harsh as a starting point for discovering NASL. > So, can You please tell us on which plugin(s) we can start working on and > what is the common procedure to do that? Well, I see the others have made some suggestions, but other than that take a look at the common security mailing lists and pick something that interests you. There are a lot of bugs reported in open source software so I'm sure you'll find some interesting things. Cheers, Tim -- Tim Brown From jan-oliver.wagner at intevation.de Wed Apr 8 14:00:25 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 8 Apr 2009 13:00:25 +0100 Subject: [Openvas-plugins] Fwd: [Openvas-devel] Dropping NASL_LEVEL In-Reply-To: <49DB77BA.8090008@securityspace.com> References: <200904061558.19180.timb@nth-dimension.org.uk> <200904071159.45227.jan-oliver.wagner@intevation.de> <49DB77BA.8090008@securityspace.com> Message-ID: <200904081400.28117.jan-oliver.wagner@intevation.de> Hello Thomas, all, On Dienstag, 7. April 2009, Thomas Reinke wrote: > If you can work on the non-local security checks, I'll > arrange to have ours cleaned up. thanks for doing so. I did take care of the rest. So, now we are free of NASL_LEVEL. I also marked NASL_LEVEL as deprecated in the openvas-libnasl module. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335083-0 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Thu Apr 9 12:40:51 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 9 Apr 2009 16:10:51 +0530 Subject: [Openvas-plugins] Current list of missing dependencies Message-ID: <045C0CEF487A4811AF5FF8C72D76468A@bchandra> We are currently working on, - php_nuke_installed.nasl - postnuke_detect.nasl - putty_version_check.nasl Thanks, Chandra. -----Original Message----- From: Chandrashekhar B [mailto:bchandra at secpod.com] Sent: Tuesday, April 07, 2009 5:12 PM To: 'openvas-plugins at wald.intevation.org' Subject: Current list of missing dependencies NASL: snmp_settings.nasl rexecd.nasl cvs_pserver_heap_overflow.nasl ping_host.nasl apcnisd_detect.nasl cisco_ids_manager_detect.nasl e107_detect.nasl macosx_SecUpd20041202.nasl mandrake_MDKSA-2004-065.nasl msrpc_dcom2.nasl ms_telnet_overflow.nasl openca_html_injection.nasl os_fingerprint.nasl php_nuke_installed.nasl postnuke_detect.nasl putty_version_check.nasl rsync_modules.nasl serendipity_detect.nasl smb_enum_services.nasl smb_nativelanman.nasl snmp_sysDesc.nasl sybase_detect.nasl webcalendar_detect.nasl webmirror.nasl www_too_long_url.nasl xoops_detect.nasl yahoo_msg_running.nasl INC's: smb_func.inc smb_file_funcs.inc byte_func.inc sunrpc_func.inc Thanks, Chandra. From mime at gmx.de Thu Apr 9 14:08:45 2009 From: mime at gmx.de (Michael Meyer) Date: Thu, 9 Apr 2009 14:08:45 +0200 Subject: [Openvas-plugins] Current list of missing dependencies In-Reply-To: <045C0CEF487A4811AF5FF8C72D76468A@bchandra> References: <045C0CEF487A4811AF5FF8C72D76468A@bchandra> Message-ID: <20090409120845.GA3551@m2.homelinux.org> Hello Chandra, *** Chandrashekhar B wrote: > We are currently working on, > > - php_nuke_installed.nasl > - postnuke_detect.nasl Postnuke was renamed to Zikula (http://zikula.org/). Will you also write a Plugin for it? If not, i put this as a item on my todo. Gretings Micha From bchandra at secpod.com Thu Apr 9 19:14:10 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 9 Apr 2009 22:44:10 +0530 Subject: [Openvas-plugins] Current list of missing dependencies In-Reply-To: <20090409120845.GA3551@m2.homelinux.org> References: <045C0CEF487A4811AF5FF8C72D76468A@bchandra> <20090409120845.GA3551@m2.homelinux.org> Message-ID: <0C2D42FAC57F48A2A477870A1CC5CD3A@bchandra> Micha, We'll update the same plugin to detect Zikula too. Chandra. -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Michael Meyer Sent: Thursday, April 09, 2009 5:39 PM To: openvas-plugins at wald.intevation.org Subject: Re: [Openvas-plugins] Current list of missing dependencies Hello Chandra, *** Chandrashekhar B wrote: > We are currently working on, > > - php_nuke_installed.nasl > - postnuke_detect.nasl Postnuke was renamed to Zikula (http://zikula.org/). Will you also write a Plugin for it? If not, i put this as a item on my todo. Gretings Micha _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From goran.licina at lss.hr Mon Apr 20 13:26:58 2009 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Mon, 20 Apr 2009 13:26:58 +0200 Subject: [Openvas-plugins] Yahoo Messenger Detection plugin Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr> Hi, we finished our first plugin - Yahoo Messenger Detection. Plugin is in attachment. We would like you to check it and notify us if everything is done ok or there are things that need to be corrected or improved. Plugin is tested and working on Yahoo Messenger versions 7 and 8. As of version 9 protocol was changed so you have to know user ID to detect messenger running. We put random number as script ID, as we weren't assigned any. Mr. Wagner instructed us to ask you here to assign us ID range that we will use in our plugins. Also, we would like you to suggest us the most suitable family fo this plugin. Any comments and suggestions are welcome :). Best Regards, Goran Licina -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/54ab51e1/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: yahoo_msg_running.nasl Type: application/octet-stream Size: 6024 bytes Desc: yahoo_msg_running.nasl Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/54ab51e1/yahoo_msg_running.obj From michael.wiegand at intevation.de Mon Apr 20 14:10:47 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 20 Apr 2009 14:10:47 +0200 Subject: [Openvas-plugins] Yahoo Messenger Detection plugin In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr> Message-ID: <20090420121047.GC12465@intevation.de> * Goran Li?ina [20. Apr 2009]: > We put random number as script ID, as we weren't assigned any. Mr. > Wagner instructed us to ask you here to assign us ID range that we > will use in our plugins. Thank you very much for your contribution! I have assigned you the ID range 102NNN. This means you may use the IDs from 102000 up to 102999 for your scripts. I have listed you on the Website (http://www.openvas.org/openvas-oids.html) as "Laboratory for Systems and Signals, University of Zagreb". Is this correct? Please let me know if you have any questions or suggestions. Regards, Michael Wiegand -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/839547fc/attachment.pgp From goran.licina at lss.hr Mon Apr 20 14:30:45 2009 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Mon, 20 Apr 2009 14:30:45 +0200 Subject: [Openvas-plugins] Yahoo Messenger Detection plugin References: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr> <20090420121047.GC12465@intevation.de> Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0858C7@vlasta.lss-net.lss.hr> > -----Original Message----- > From: Michael Wiegand [mailto:michael.wiegand at intevation.de] > Sent: Monday, April 20, 2009 2:11 PM > To: Goran Li?ina > Cc: Openvas-plugins at wald.intevation.org > Subject: Re: [Openvas-plugins] Yahoo Messenger Detection plugin > > * Goran Li?ina [20. Apr 2009]: > > We put random number as script ID, as we weren't assigned any. Mr. > > Wagner instructed us to ask you here to assign us ID range that we > > will use in our plugins. > > Thank you very much for your contribution! > > I have assigned you the ID range 102NNN. This means you may use the IDs > from 102000 up to 102999 for your scripts. > > I have listed you on the Website > (http://www.openvas.org/openvas-oids.html) as "Laboratory for Systems > and Signals, University of Zagreb". Is this correct? Title is ok. > > Please let me know if you have any questions or suggestions. Can you please help us choose plugin family so we can update plugin. What is the procedure for choosing one when making plugin? Goran Licina From bchandra at secpod.com Mon Apr 20 14:36:54 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 20 Apr 2009 18:06:54 +0530 Subject: [Openvas-plugins] Yahoo Messenger Detection plugin In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C0858C7@vlasta.lss-net.lss.hr> References: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr><20090420121047.GC12465@intevation.de> <8A02A3DF683DEE42BE73187F4CA4444C0858C7@vlasta.lss-net.lss.hr> Message-ID: Goram, Please refer to http://www.openvas.org/openvas-cr-23.html which describes different plugins family. All detection Plugins are marked into "Service detection". I'll review the plugin and commit to SVN if everything is alright. Thanks, Chandra. -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Goran Licina Sent: Monday, April 20, 2009 6:01 PM To: Michael Wiegand Cc: Openvas-plugins at wald.intevation.org Subject: Re: [Openvas-plugins] Yahoo Messenger Detection plugin > -----Original Message----- > From: Michael Wiegand [mailto:michael.wiegand at intevation.de] > Sent: Monday, April 20, 2009 2:11 PM > To: Goran Li?ina > Cc: Openvas-plugins at wald.intevation.org > Subject: Re: [Openvas-plugins] Yahoo Messenger Detection plugin > > * Goran Li?ina [20. Apr 2009]: > > We put random number as script ID, as we weren't assigned any. Mr. > > Wagner instructed us to ask you here to assign us ID range that we > > will use in our plugins. > > Thank you very much for your contribution! > > I have assigned you the ID range 102NNN. This means you may use the IDs > from 102000 up to 102999 for your scripts. > > I have listed you on the Website > (http://www.openvas.org/openvas-oids.html) as "Laboratory for Systems > and Signals, University of Zagreb". Is this correct? > Title is ok. > > Please let me know if you have any questions or suggestions. Can you please help us choose plugin family so we can update plugin. What is the procedure for choosing one when making plugin? Goran Licina _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From goran.licina at lss.hr Mon Apr 20 14:48:12 2009 From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=) Date: Mon, 20 Apr 2009 14:48:12 +0200 Subject: [Openvas-plugins] Yahoo Messenger Detection plugin References: <8A02A3DF683DEE42BE73187F4CA4444C0858C5@vlasta.lss-net.lss.hr><20090420121047.GC12465@intevation.de> <8A02A3DF683DEE42BE73187F4CA4444C0858C7@vlasta.lss-net.lss.hr> Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0858CA@vlasta.lss-net.lss.hr> > -----Original Message----- > From: Chandrashekhar B [mailto:bchandra at secpod.com] > Sent: Monday, April 20, 2009 2:37 PM > To: Goran Li?ina > Cc: Openvas-plugins at wald.intevation.org > Subject: RE: [Openvas-plugins] Yahoo Messenger Detection plugin > > Goram, > > Please refer to http://www.openvas.org/openvas-cr-23.html which > describes > different plugins family. All detection Plugins are marked into > "Service > detection". > > I'll review the plugin and commit to SVN if everything is alright. > > Thanks, > Chandra. Thanks, I updated the plugin with new ID and family. It's in attach. Please notify us if something needs to be fixed. Regards, Goran Licina -- Laboratory for Systems and Signals Department of Electronic Systems and Information Processing Faculty of Electrical Engineering and Computing University of Zagreb -------------- next part -------------- A non-text attachment was scrubbed... Name: yahoo_msg_running.nasl Type: application/octet-stream Size: 6026 bytes Desc: yahoo_msg_running.nasl Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/b44dafd9/yahoo_msg_running-0001.obj From christian.edjenguele at owasp.org Mon Apr 20 23:19:28 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Mon, 20 Apr 2009 23:19:28 +0200 Subject: [Openvas-plugins] html page truncated with nasl request Message-ID: <49ECE6E0.8090404@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I'm writing a script to grab the Apache OFBiz version, but when I launch the request, the html response page is truncated ( an so I can't reach the version number at the bottom of the page) because of a drop down list at the top-right of the page. but the same request in python both 2.5 (httplib) and 3.0 (http.client), I get the whole page and I can grab the version with a regex. please see the attached files. Thanks. - -- Christian Eric Edjenguele IT Security Software Engineer / IT Enterprise Software Architect Mobile (IT): +39 3408580513 PGP KeyID: 0xB1654498 Key Server: http://pgp.mit.edu - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (GNU/Linux) mQENBEmka7IBCAC5e8/9BlCZR/3XHMO4DWHYoewaODmQypHqPaCfKR+BLTAy8xLZ eVJ0wwNwaLheZeLPfBqu3r/lp58xJhgYHm9gzihfqPbmJh4Dibc/d2XL9UQ1eshs K0JkTlvZtdK5Zo5VmeOZCWlKEMXzlg6HjuYUV4qokqD3qIj6/rhubjtrjlw/XA8P 6pGOFhsDZFXbn+lj80XhRdkObMnmWU6wdgJvEPx1vxvhV9D1sJgZz6FVoXAfTOb3 EjYpluEKdDod46hhF45UJ4Avc8q4DaXxmci5Kdx9rzF2tbvB3Ua6O7l5RaMGNZR2 QtVY65xVxRfAYF+yE3n+YkFQxWGlqVIajry/ABEBAAG0WkNocmlzdGlhbiBFcmlj IEVESkVOR1VFTEUgKElUIFNlY3VyaXR5IFNvZnR3YXJlIEVuZ2luZWVyKSA8Y2hy aXN0aWFuLmVkamVuZ3VlbGVAb3dhc3Aub3JnPokBNgQTAQIAIAUCSaRrsgIbAwYL CQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJENETScWxZUSYS9QH+gOpYUPkon/D/eNm RLCbTaqJhSV6jRH9t+pomm6FiYgphCxDW96OpzA9BieiFEPHhVXAFcHkEBMlk/u0 wILqDNfBoZk3oCq0+/+Zc7z0zRZfgMHwB4czpqhUCrINEjLO0rb2Jff6Hh0C5S9w 8l+x9IiOG9hHNO8ftVr1sNHGDTAWNNZ+pcCt5ROhqiiqnZsvowO1TcDMKEGD9NTW BN+jLFGZRY9/MQsUkWoXBQ8K5S9AP1EPPbSTX68VTj0vINLTk2/XfsJlV9Vd9b7G NkhbAdrvujbqLHDSE3ALpx8sWKg2vPCUAxJJY6S6danpw/XPGKkpcSNfqn4k8sCV e+9MJSu5Ag0ESaRthQEQALEj8eO2WCRqhOHakHhpvGQ4tFEIDS6Z3mnBaNaMc9VM i89LNYvJOgOSnWvIu8EF6Ah+PnhOayb9E3wvH+0nfOwzp6XhDor7h8WLQNL+qzk3 cPxkxdfNDaQdyJclstUqa0nIaPOJgbIRs12N6bCxhAeOKffIkrIdDqjxshTI3S3z fq7choduX8tNHoFzIIl6T+4Q0QXMT8xu5MeBHr+vxlgqNUTWOQn6Q/B6QnrVzWDA gEq4Id45vN4j18iXGqMy8/xWQg3kRHaU563zx8u+7cjV81feMDbQiC6p6nqQHsD4 U07JIVDqjbJESLdeqju6HsNzYKohi/gxhsgouPXdFTrfgkWCklAGwqT7QE0ZnL/t SVC0xpmCLneXAxWGGo27zJKVJ1/iMUgi/i4R+u2K4eQbsBXXYwh0gSxwYReTyr+C 51ugKkvYjTy+U2Fedq3lXEVtnRV02zpO/LlpJR446jRAapVH+ZF9tGMoIHg5hATZ KEzGw9x19/wQSRumTvV0HAQ0lqWW9/0n2VuwI/Sh7YHQ2j/DhyF0blFrooGyIxd2 x5+Xu1PWlYwlUbu7ZsOw1V9cqL5yv5m+w4mL+h8ytHJHHL2Cg8/3qp/QxLT7CnfX fOHAjNxGkS/QfoxEhuSwigPi/Yd51wHcaOLyUdGceOZ79ciQtPgvCFdyrDrfDhSr ABEBAAGJAR8EGAECAAkFAkmkbYUCGwwACgkQ0RNJxbFlRJhbLAgAsCBA7KmGkTmQ mjPNA7Iig8tA5S9fYavbKydNQNxPpL47GLf9V3la4P2/LPLa3rH31Bt+ScfSqAKC 5/geB5BKwmQqRomsQpjhmrpBenPjYrUYG2dEB/BOMvOyvr3dTpWtAg5CwYYnHTNy yJn7dc7whiE94ZxqFdt58K0H5/H449/VHuCJue+uzy0ldrTK8VVpK6uGgrJc5kre 2bpdGVbALpC+yeNMyXCqgGigg9gu1iHXSSGgbQfW+AhsFpiN37fPq8zDNU2C8sp3 4Y45EYRmRCZ+0a9WSRnYALRZFdvjysKfRjP3o4Ax/d4cSi6v2pT93yfoA2TQMkLF E1MQObpE5A== =7VGF - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJ7ObYAAoJENETScWxZUSY5dMIAJpnP2PKOmBW7ky9V1Z9tgau l2TFsulEU206jrE8OL01m82+VSgbw/4b9/ljlhbFGCet4v8cyzEuwr07s99KXPzO Hom5TT1DVdPE/ZLp/CuVbffF5YeYS4XznN/zettHiF4D6lUoGGg8woGatX1/Qj4s f+xXiy8z6KlAZHko/b8hyl8u1/dizq4+jGY8KFxJJmVt1JtRnDWAx3tjAKesNfR0 V7dW1p40Ew2QaCVK7mNWyZ3IrvphVudqKsD5lAEI2pfp7ixslvTAw1IYDZfTPByU 3ROg360hJBWQJRUCPeKFnBzeCLd5N67+ZPJ4RFL2NAryjoiPZyq+KHihK6v6hjQ= =2i/D -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nasl.output Url: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/caa35035/nasl-0001.pot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090420/caa35035/python-0001.html From michael.wiegand at intevation.de Tue Apr 21 08:45:04 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 21 Apr 2009 08:45:04 +0200 Subject: [Openvas-plugins] openvas-plugins Debian Package In-Reply-To: <200904201711.41015.waja@cyconet.org> References: <20090420123229.GD12465@intevation.de> <200904201531.10736.waja@cyconet.org> <20090420134809.GF12465@intevation.de> <200904201711.41015.waja@cyconet.org> Message-ID: <20090421064503.GA18319@intevation.de> * Jan Wagner [20. Apr 2009]: > > What do I need to do to make the buildds love openvas-server again? > > I did all the needed steps. :) Thank you! :) > > > and openvas-plugins aren't in Debian et al. > > > > What would be your suggestion for getting it into Debian? Strip out all > > offending plugins or strip all non-C plugins? > > Hmm .... I would suggest to drop all non-dfsg plugins and then let the users > decide, if/what/when they update the plugins from your feed. I guess there is > fancy script, which can do that. :) Using Javier's audit script, there are only two non-free plugins remaining. Is this a complete list or are there other scripts Debian might object to? The two scripts are: apache_username.nasl smb_hotfixes.inc Both are (C) Tenable without any licensing information. apache_username.nasl is somewhat old (CVE-2001-1013) but should be trivial to rewrite from scratch if needed. It was included in the Nessus GPL Feed, so I will adjust the license to GPL if there are no objections. smb_hotfixes.inc is included by eight other plugins: smb_nt_ms04-026.nasl smb_nt_ms02-051.nasl smb_nt_ms02-025.nasl smb_nt_ms02-016.nasl spybot_detection.nasl patchlink_detection.nasl smb_virii.nasl smb_suspicious_files.nasl At least the last four are currently broken anyway, since they include the nonexistant smb_func.inc as well. AFAICT, smb_hotfixes.inc was not part of the Nessus GPL Feed, can anyone clarify where it came from? I'm not sure if the functionality provided by smb_hotfixes.inc is really needed and how much work this would be. I'm crossposting this to openvas-plugins in hope of some answers. I would not mind removing smb_hotfixes.inc and dependent plugins from the Debian package if the damage is (as it seems) minimal. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090421/48ae51f1/attachment.pgp From waja at cyconet.org Tue Apr 21 08:55:46 2009 From: waja at cyconet.org (Jan Wagner) Date: Tue, 21 Apr 2009 08:55:46 +0200 Subject: [Openvas-plugins] openvas-plugins Debian Package In-Reply-To: <20090421064503.GA18319@intevation.de> References: <20090420123229.GD12465@intevation.de> <200904201711.41015.waja@cyconet.org> <20090421064503.GA18319@intevation.de> Message-ID: <200904210855.50031.waja@cyconet.org> Hi Michael, On Tuesday 21 April 2009, Michael Wiegand wrote: > * Jan Wagner [20. Apr 2009]: > > > What do I need to do to make the buildds love openvas-server again? > > > > I did all the needed steps. :) > > Thank you! :) your're welcome. :) > > Hmm .... I would suggest to drop all non-dfsg plugins and then let the > > users decide, if/what/when they update the plugins from your feed. I > > guess there is fancy script, which can do that. :) > > Using Javier's audit script, there are only two non-free plugins > remaining. Is this a complete list or are there other scripts Debian > might object to? There are guidelines, which have all software needs to be conform to, called DFSG[1]. With kind regards, Jan. [1] http://www.debian.org/social_contract#guidelines -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090421/78769717/attachment.pgp From mime at gmx.de Tue Apr 21 09:34:45 2009 From: mime at gmx.de (Michael Meyer) Date: Tue, 21 Apr 2009 09:34:45 +0200 Subject: [Openvas-plugins] html page truncated with nasl request In-Reply-To: <49ECE6E0.8090404@owasp.org> References: <49ECE6E0.8090404@owasp.org> Message-ID: <20090421073445.GA2584@m2.homelinux.org> Hello Christian, *** Christian Eric Edjenguele wrote: > Hi guys, I'm writing a script to grab the Apache OFBiz version, > but when I launch the request, the html response page is truncated ( an > so I can't reach the version number at the bottom of the page) because > of a drop down list at the top-right of the page. Yes, this is reproduceable eg. with a large phpinfo.php. At first view, problem seems to be "function http_recv_body()" from http_func.inc. Im a little bit less on time at the moment, but will have a look on this later. Could you please try to use HTTP/1.1 instead of HTTP/1.0 in your plugin and tell me if that solves this issue for the moment? Micha From schandan at secpod.com Tue Apr 21 17:31:40 2009 From: schandan at secpod.com (chandan) Date: Tue, 21 Apr 2009 21:01:40 +0530 Subject: [Openvas-plugins] Openvas-plugins] openvas-plugins Debian Package In-Reply-To: References: Message-ID: <49EDE6DC.3000003@secpod.com> There is an alternative inc, secpod_reg.inc as a replacement to smb_hotfixes.inc. We will address the below plugins by adding secpod_reg.inc. smb_nt_ms04-026.nasl smb_nt_ms02-051.nasl smb_nt_ms02-025.nasl smb_nt_ms02-016.nasl smb_nt_ms02-018.nasl The rest of the plugins can be invalidated. Thanks!! Chandan S Message: 1 Date: Tue, 21 Apr 2009 08:45:04 +0200 From: Michael Wiegand Subject: [Openvas-plugins] openvas-plugins Debian Package To: Jan Wagner Cc: OpenVAS Debian Distribution List , OpenVAS Plugins List Message-ID: <20090421064503.GA18319 at intevation.de> Content-Type: text/plain; charset="iso-8859-15" * Jan Wagner [20. Apr 2009]: >> > > What do I need to do to make the buildds love openvas-server again? >> > > > > I did all the needed steps. :) > Thank you! :) >>> > > > and openvas-plugins aren't in Debian et al. >>> >> > > >> > > What would be your suggestion for getting it into Debian? Strip out all >> > > offending plugins or strip all non-C plugins? >> > > > > Hmm .... I would suggest to drop all non-dfsg plugins and then let the users > > decide, if/what/when they update the plugins from your feed. I guess there is > > fancy script, which can do that. :) > Using Javier's audit script, there are only two non-free plugins remaining. Is this a complete list or are there other scripts Debian might object to? The two scripts are: apache_username.nasl smb_hotfixes.inc Both are (C) Tenable without any licensing information. apache_username.nasl is somewhat old (CVE-2001-1013) but should be trivial to rewrite from scratch if needed. It was included in the Nessus GPL Feed, so I will adjust the license to GPL if there are no objections. smb_hotfixes.inc is included by eight other plugins: smb_nt_ms04-026.nasl smb_nt_ms02-051.nasl smb_nt_ms02-025.nasl smb_nt_ms02-016.nasl spybot_detection.nasl patchlink_detection.nasl smb_virii.nasl smb_suspicious_files.nasl At least the last four are currently broken anyway, since they include the nonexistant smb_func.inc as well. AFAICT, smb_hotfixes.inc was not part of the Nessus GPL Feed, can anyone clarify where it came from? I'm not sure if the functionality provided by smb_hotfixes.inc is really needed and how much work this would be. I'm crossposting this to openvas-plugins in hope of some answers. I would not mind removing smb_hotfixes.inc and dependent plugins from the Debian package if the damage is (as it seems) minimal. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090421/48ae51f1/attachment-0001.pgp ------------------------------ Message: 2 Date: Tue, 21 Apr 2009 08:55:46 +0200 From: Jan Wagner Subject: Re: [Openvas-plugins] openvas-plugins Debian Package To: OpenVAS Debian Distribution List Cc: OpenVAS Plugins List Message-ID: <200904210855.50031.waja at cyconet.org> Content-Type: text/plain; charset="iso-8859-15" Hi Michael, On Tuesday 21 April 2009, Michael Wiegand wrote: > > * Jan Wagner [20. Apr 2009]: > >>> > > > What do I need to do to make the buildds love openvas-server again? >>> >> > > >> > > I did all the needed steps. :) >> > > > > Thank you! :) > your're welcome. :) >> > > Hmm .... I would suggest to drop all non-dfsg plugins and then let the >> > > users decide, if/what/when they update the plugins from your feed. I >> > > guess there is fancy script, which can do that. :) >> > > > > Using Javier's audit script, there are only two non-free plugins > > remaining. Is this a complete list or are there other scripts Debian > > might object to? > There are guidelines, which have all software needs to be conform to, called DFSG[1]. With kind regards, Jan. [1] http://www.debian.org/social_contract#guidelines -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090421/78769717/attachment-0001.pgp ------------------------------ openvas-plugins-request at wald.intevation.org wrote: > Send Openvas-plugins mailing list submissions to > openvas-plugins at wald.intevation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > or, via email, send a message with subject or body 'help' to > openvas-plugins-request at wald.intevation.org > > You can reach the person managing the list at > openvas-plugins-owner at wald.intevation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openvas-plugins digest..." > > > Today's Topics: > > 1. openvas-plugins Debian Package (Michael Wiegand) > 2. Re: openvas-plugins Debian Package (Jan Wagner) > 3. Re: html page truncated with nasl request (Michael Meyer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Apr 2009 08:45:04 +0200 > From: Michael Wiegand > Subject: [Openvas-plugins] openvas-plugins Debian Package > To: Jan Wagner > Cc: OpenVAS Debian Distribution List > , OpenVAS Plugins List > > Message-ID: <20090421064503.GA18319 at intevation.de> > Content-Type: text/plain; charset="iso-8859-15" > > * Jan Wagner [20. Apr 2009]: > >>> What do I need to do to make the buildds love openvas-server again? >>> >> I did all the needed steps. :) >> > > Thank you! :) > > >>>> and openvas-plugins aren't in Debian et al. >>>> >>> What would be your suggestion for getting it into Debian? Strip out all >>> offending plugins or strip all non-C plugins? >>> >> Hmm .... I would suggest to drop all non-dfsg plugins and then let the users >> decide, if/what/when they update the plugins from your feed. I guess there is >> fancy script, which can do that. :) >> > > Using Javier's audit script, there are only two non-free plugins > remaining. Is this a complete list or are there other scripts Debian > might object to? > > The two scripts are: > apache_username.nasl > smb_hotfixes.inc > > Both are (C) Tenable without any licensing information. > > apache_username.nasl is somewhat old (CVE-2001-1013) but should be > trivial to rewrite from scratch if needed. It was included in the Nessus > GPL Feed, so I will adjust the license to GPL if there are no > objections. > > smb_hotfixes.inc is included by eight other plugins: > > smb_nt_ms04-026.nasl > smb_nt_ms02-051.nasl > smb_nt_ms02-025.nasl > smb_nt_ms02-016.nasl > spybot_detection.nasl > patchlink_detection.nasl > smb_virii.nasl > smb_suspicious_files.nasl > > At least the last four are currently broken anyway, since they include > the nonexistant smb_func.inc as well. > > AFAICT, smb_hotfixes.inc was not part of the Nessus GPL Feed, can anyone > clarify where it came from? I'm not sure if the functionality provided > by smb_hotfixes.inc is really needed and how much work this would be. > I'm crossposting this to openvas-plugins in hope of some answers. > > I would not mind removing smb_hotfixes.inc and dependent plugins from > the Debian package if the damage is (as it seems) minimal. > > Regards, > > Michael > > From lists at securityspace.com Tue Apr 21 18:30:40 2009 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 21 Apr 2009 12:30:40 -0400 Subject: [Openvas-plugins] Openvas-plugins] openvas-plugins Debian Package In-Reply-To: <49EDE6DC.3000003@secpod.com> References: <49EDE6DC.3000003@secpod.com> Message-ID: <49EDF4B0.3050600@securityspace.com> > The two scripts are: > apache_username.nasl > smb_hotfixes.inc > > Both are (C) Tenable without any licensing information. > > smb_hotfixes.inc is included by eight other plugins: > > smb_nt_ms04-026.nasl > smb_nt_ms02-051.nasl > smb_nt_ms02-025.nasl > smb_nt_ms02-016.nasl > spybot_detection.nasl > patchlink_detection.nasl > smb_virii.nasl > smb_suspicious_files.nasl > > At least the last four are currently broken anyway, since they include > the nonexistant smb_func.inc as well. > > AFAICT, smb_hotfixes.inc was not part of the Nessus GPL Feed, can anyone > clarify where it came from? I'm not sure if the functionality provided > by smb_hotfixes.inc is really needed and how much work this would be. > I'm crossposting this to openvas-plugins in hope of some answers. smb_hotfixes.inc is confirmed as having been distributed as part of the Nessus GPL feed on January 2nd, 2005, after Tenable had removed from the GPL feed components that they no longer wished to distribute under the terms of the GPL. It was, however, no longer present in the July 10th, 2006 version of the feed. Either rewrite or removal pending rewrite of the affected scripts would be my suggested course of action, given the small # of scripts involved. Thomas From michael.wiegand at intevation.de Wed Apr 22 08:20:23 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 22 Apr 2009 08:20:23 +0200 Subject: [Openvas-plugins] smb_hotfixes.inc In-Reply-To: <49EDF4B0.3050600@securityspace.com> References: <49EDE6DC.3000003@secpod.com> <49EDF4B0.3050600@securityspace.com> Message-ID: <20090422062023.GA12977@intevation.de> * Thomas Reinke [21. Apr 2009]: > smb_hotfixes.inc is confirmed as having been distributed > as part of the Nessus GPL feed on January 2nd, 2005, after Tenable > had removed from the GPL feed components that they no longer > wished to distribute under the terms of the GPL. > It was, however, no longer present in the July 10th, 2006 version > of the feed. That explains it, I only looked at the 2006 tarball. Do we consider those scripts GPL as well? > Either rewrite or removal pending rewrite of the affected scripts > would be my suggested course of action, given the small # of scripts > involved. If I understand Chandan correctly, the functionality can (more or less) easily be provided by secpod_reg.inc with a few adjustments. I'm in favor of removing smb_hotfixes.inc permanently once secpod_reg.inc is patched and the scripts including smb_hotfixes.inc have been switched to include secpod_reg.inc instead. Any objections? Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090422/6f6f17a3/attachment.pgp From michael.wiegand at intevation.de Thu Apr 23 08:11:56 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 23 Apr 2009 08:11:56 +0200 Subject: [Openvas-plugins] smb_hotfixes.inc In-Reply-To: <20090422062023.GA12977@intevation.de> References: <49EDE6DC.3000003@secpod.com> <49EDF4B0.3050600@securityspace.com> <20090422062023.GA12977@intevation.de> Message-ID: <20090423061156.GA11585@intevation.de> * Michael Wiegand [22. Apr 2009]: > > smb_hotfixes.inc is confirmed as having been distributed > > as part of the Nessus GPL feed on January 2nd, 2005, after Tenable > > had removed from the GPL feed components that they no longer > > wished to distribute under the terms of the GPL. > > It was, however, no longer present in the July 10th, 2006 version > > of the feed. > > That explains it, I only looked at the 2006 tarball. Do we consider > those scripts GPL as well? To answer my own question for the record: Yes, we do consider all scripts which were in the Nessus GPL Feed to be licensed under the GPL, regardless of whether they were part of the 20060710 tarball or not. Sorry for the confusion. Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090423/b5f62b3a/attachment.pgp From michael.wiegand at intevation.de Thu Apr 23 10:11:46 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 23 Apr 2009 10:11:46 +0200 Subject: [Openvas-plugins] Discontinuing openvas-plugins tarball? Message-ID: <20090423081146.GB11585@intevation.de> Hello, Jan and I have been thinking about discontinuing the release of openvas-plugins tarballs and distributing the plugins only through the existing Feed Services. The background is that using both the tarball and the openvas-nvt-sync script does under certain conditions lead to a race condition in the plugin cache which causes openvasd to use an outdated cached version of a plugin even though the plugin has changed in the feed. We have tried to compensate for this by making adjustments in the synchronization script, but this has the side effect of disproportionately increasing the time and bandwidth needed to synchronize with the feed. I would like your opinions regarding the following issues: - What would be the consequences of discontinuing the tarball release? There should not be installations which use only the tarball and never sync, should there? - What mechanisms should be available for users who cannot sync using rsync due to restrictions on firewall or proxy level? - Should openvasd force an initial sync during installation or just display a notice that a sync is need to use OpenVAS? - Any other issues you can think of. :) I'm looking forward to your opinions. Please do not hesitate to ask if my proposal does not make sense to you. I am crossposting this to openvas-discuss and openvas-plugins as well to reach all involved parties. Please keep crossposting to a minimum in your replies and try to reply in openvas-devel. Thank you! Regards, Michael -- Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090423/b993e5f6/attachment.pgp From danielcabezas at hotmail.com Thu Apr 23 11:11:15 2009 From: danielcabezas at hotmail.com (Daniel Cabezas) Date: Thu, 23 Apr 2009 11:11:15 +0200 Subject: [Openvas-plugins] [Openvas-devel] Discontinuing openvas-plugins tarball? In-Reply-To: <20090423081146.GB11585@intevation.de> References: <20090423081146.GB11585@intevation.de> Message-ID: Greetings, (First of all, sorry if the email appears duplicated, I am having some issues with my browser). In my humble opinion, discontinuing openvas-plugins tarball would derive some problems. Think of unattended install scripts, offline installations, or security assessments where the technician doesn't have Internet connection because of a black-box job approach. But that's just my opinion. Regards, Daniel > Date: Thu, 23 Apr 2009 10:11:46 +0200 > From: michael.wiegand at intevation.de > To: openvas-devel at wald.intevation.org > CC: openvas-discuss at wald.intevation.org; openvas-plugins at wald.intevation.org > Subject: [Openvas-devel] Discontinuing openvas-plugins tarball? > > Hello, > > Jan and I have been thinking about discontinuing the release of > openvas-plugins tarballs and distributing the plugins only through the > existing Feed Services. > > The background is that using both the tarball and the openvas-nvt-sync > script does under certain conditions lead to a race condition in the > plugin cache which causes openvasd to use an outdated cached version of > a plugin even though the plugin has changed in the feed. We have tried > to compensate for this by making adjustments in the synchronization > script, but this has the side effect of disproportionately increasing > the time and bandwidth needed to synchronize with the feed. > > I would like your opinions regarding the following issues: > > - What would be the consequences of discontinuing the tarball release? > There should not be installations which use only the tarball and never > sync, should there? > > - What mechanisms should be available for users who cannot sync using > rsync due to restrictions on firewall or proxy level? > > - Should openvasd force an initial sync during installation or just > display a notice that a sync is need to use OpenVAS? > > - Any other issues you can think of. :) > > I'm looking forward to your opinions. Please do not hesitate to ask if > my proposal does not make sense to you. > > I am crossposting this to openvas-discuss and openvas-plugins as well to > reach all involved parties. Please keep crossposting to a minimum in > your replies and try to reply in openvas-devel. Thank you! > > Regards, > > Michael > > -- > Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de > Neuer Graben 17, 49074 Osnabr?ck, Germany | AG Osnabr?ck, HR B 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _________________________________________________________________ El nuevo Windows Live te une a los que m?s quieres http://www.windowslive.es -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090423/26743b98/attachment.htm From hans.ullrich at loop.de Thu Apr 23 11:16:58 2009 From: hans.ullrich at loop.de (Ullrich-IT-Consult) Date: Thu, 23 Apr 2009 11:16:58 +0200 Subject: [Openvas-plugins] [Openvas-discuss] Discontinuing openvas-plugins tarball? In-Reply-To: <20090423081146.GB11585@intevation.de> References: <20090423081146.GB11585@intevation.de> Message-ID: <200904231116.59560.kontakt@ullrich-it.de> Am Donnerstag 23 April 2009 schrieb Michael Wiegand: > Hello, > Hi Michael and Jan, > Jan and I have been thinking about discontinuing the release of > openvas-plugins tarballs and distributing the plugins only through the > existing Feed Services. > > The background is that using both the tarball and the openvas-nvt-sync > script does under certain conditions lead to a race condition in the > plugin cache which causes openvasd to use an outdated cached version of > a plugin even though the plugin has changed in the feed. We have tried > to compensate for this by making adjustments in the synchronization > script, but this has the side effect of disproportionately increasing > the time and bandwidth needed to synchronize with the feed. > > I would like your opinions regarding the following issues: > > - What would be the consequences of discontinuing the tarball release? > There should not be installations which use only the tarball and never > sync, should there? > I think, there were be no consquences at all. The only thing, that copmes in my mind, would be a possibility to transport the tarball to factories, which might have (for waht reasons ever) , no access to the internet. In this case it would be nice, to have a possibility to add new plugins or add plugins at all. > - What mechanisms should be available for users who cannot sync using > rsync due to restrictions on firewall or proxy level? > I think, most users should have access to the internet with http, and as far as I know, rsync offers an option, to use http (if I remember correctly). In other case, there comes the word "tunneling" in my mind. Maybe to invent an easy way for users, to tunnel through http??? > - Should openvasd force an initial sync during installation or just > display a notice that a sync is need to use OpenVAS? > I suggest, not to force an initial sync, as some users or security analysts might want to test new plugins before they break things at their customners. It might be, they want to keep old plugins during tests. IMO the suggestion is the better way, so the security analyst can decide for himself, if to upgrade or not. > - Any other issues you can think of. :) None at the moment. :) > > I'm looking forward to your opinions. Please do not hesitate to ask if > my proposal does not make sense to you. > > I am crossposting this to openvas-discuss and openvas-plugins as well to > reach all involved parties. Please keep crossposting to a minimum in > your replies and try to reply in openvas-devel. Thank you! > > Regards, > > Michael Best regards Hans-J. Ullrich -- Firma Ullrich-IT-Consult Inh.: Hans-J. Ullrich M?nstedter Weg 10 31246 Oberg www: http://www.ullrich-it.de www2: http://www.ccpeine.de IT-Spezialist f?r die Bereiche IT-Sicherheit, Linux und Unix, EDV-Schulungen und -Workshops -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090423/54d27f66/attachment.html From jan-oliver.wagner at intevation.de Thu Apr 23 23:23:29 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 23 Apr 2009 23:23:29 +0200 Subject: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up In-Reply-To: <000325579e82ab986b04682bfdbe@google.com> References: <000325579e82ab986b04682bfdbe@google.com> Message-ID: <200904232323.29452.jan-oliver.wagner@intevation.de> Hello all, anyone feels like digging into this issue reported by Kevin? Best Jan On Thursday 23 April 2009 00:07:35 you wrote: > I found a response from you on the openvas-plugins mailing list archive > regarding this plugin and was hoping to work with you to find the answer. > > Here is a link to that message: > http://marc.info/?l=openvas-plugins&m=121084160209010&w=2 > > In your response you mentioned a possible explanation. The msrpc_dcom2.nasl > script had to be removed from openVAS and thus a dependency for the > msrpc_dcom.nasl script is missing. You then stated you might be able to > reproduce the problem but didn't have that service running on your XPSP2 > system. Here's where I can help. Just this morning while testing OpenVAS > for the first time it reported the existence of this vulnerability on a > computer I use. However I have verified the patch for the vulnerability and > tested that computer with another scanner which reported that the computer > is indeed not vulnerable. I can re-create the scenario as needed and offer > whatever help to debug or trace the issue. As this particular vulnerability > was associated with a widely known worm, I think it is very important for > OpenVAS to be accurate. I have an affinity for the efforts on this project > and may even lend my security and coding expertise in the future. -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Apr 24 12:40:11 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 24 Apr 2009 16:10:11 +0530 Subject: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up In-Reply-To: <200904232323.29452.jan-oliver.wagner@intevation.de> References: <000325579e82ab986b04682bfdbe@google.com> <200904232323.29452.jan-oliver.wagner@intevation.de> Message-ID: We saw the same issue reporting in one of our scan. We'll resolve this. Chandra. -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Friday, April 24, 2009 2:53 AM To: openvas-plugins at wald.intevation.org Cc: kjordan3 at gmail.com Subject: Re: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up Hello all, anyone feels like digging into this issue reported by Kevin? Best Jan On Thursday 23 April 2009 00:07:35 you wrote: > I found a response from you on the openvas-plugins mailing list archive > regarding this plugin and was hoping to work with you to find the answer. > > Here is a link to that message: > http://marc.info/?l=openvas-plugins&m=121084160209010&w=2 > > In your response you mentioned a possible explanation. The msrpc_dcom2.nasl > script had to be removed from openVAS and thus a dependency for the > msrpc_dcom.nasl script is missing. You then stated you might be able to > reproduce the problem but didn't have that service running on your XPSP2 > system. Here's where I can help. Just this morning while testing OpenVAS > for the first time it reported the existence of this vulnerability on a > computer I use. However I have verified the patch for the vulnerability and > tested that computer with another scanner which reported that the computer > is indeed not vulnerable. I can re-create the scenario as needed and offer > whatever help to debug or trace the issue. As this particular vulnerability > was associated with a widely known worm, I think it is very important for > OpenVAS to be accurate. I have an affinity for the efforts on this project > and may even lend my security and coding expertise in the future. -- Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From bchandra at secpod.com Fri Apr 24 16:24:33 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 24 Apr 2009 19:54:33 +0530 Subject: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up In-Reply-To: <00221532c8ac05dec304684cf0a5@google.com> References: <00221532c8ac05dec304684cf0a5@google.com> Message-ID: <4EE0B71626064E85BC2F8D9F18CA2414@bchandra> Committed now, please check it and let me know if you still find the issue. Chandra. ________________________________________ From: kjordan3 at gmail.com [mailto:kjordan3 at gmail.com] Sent: Friday, April 24, 2009 6:56 PM To: Chandrashekhar B; Jan-Oliver Wagner; openvas-plugins at wald.intevation.org; kjordan3 at gmail.com Subject: Re: RE: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up Fantastic! Keep me posted and let me know how/if I can lend a hand. -Kevin On Apr 24, 2009 5:40am, Chandrashekhar B wrote: > We saw the same issue reporting in one of our scan. We'll resolve this. > > > > Chandra. > > > > -----Original Message----- > > From: openvas-plugins-bounces at wald.intevation.org > > [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Jan-Oliver > > Wagner > > Sent: Friday, April 24, 2009 2:53 AM > > To: openvas-plugins at wald.intevation.org > > Cc: kjordan3 at gmail.com > > Subject: Re: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up > > > > Hello all, > > > > anyone feels like digging into this issue reported by Kevin? > > > > Best > > > > ? ? ? ?Jan > > > > On Thursday 23 April 2009 00:07:35 you wrote: > > > I found a response from you on the openvas-plugins mailing list archive > > > regarding this plugin and was hoping to work with you to find the answer. > > > > > > Here is a link to that message: > > > http://marc.info/?l=openvas-plugins&m=121084160209010&w=2 > > > > > > In your response you mentioned a possible explanation. The > > msrpc_dcom2.nasl > > > script had to be removed from openVAS and thus a dependency for the > > > msrpc_dcom.nasl script is missing. You then stated you might be able to > > > reproduce the problem but didn't have that service running on your XPSP2 > > > system. Here's where I can help. Just this morning while testing OpenVAS > > > for the first time it reported the existence of this vulnerability on a > > > computer I use. However I have verified the patch for the vulnerability > > and > > > tested that computer with another scanner which reported that the computer > > > is indeed not vulnerable. I can re-create the scenario as needed and offer > > > whatever help to debug or trace the issue. As this particular > > vulnerability > > > was associated with a widely known worm, I think it is very important for > > > OpenVAS to be accurate. I have an affinity for the efforts on this project > > > and may even lend my security and coding expertise in the future. > > > > -- > > Dr. Jan-Oliver Wagner | ++49-541-335 08 30 ?| ?http://www.intevation.de/ > > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 > > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > > _______________________________________________ > > Openvas-plugins mailing list > > Openvas-plugins at wald.intevation.org > > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > > From d.jagdmann at dn-systems.de Thu Apr 23 23:41:41 2009 From: d.jagdmann at dn-systems.de (Dirk Jagdmann) Date: Thu, 23 Apr 2009 14:41:41 -0700 Subject: [Openvas-plugins] [Openvas-discuss] Discontinuing openvas-plugins tarball? In-Reply-To: <20090423081146.GB11585@intevation.de> References: <20090423081146.GB11585@intevation.de> Message-ID: <49F0E095.2070800@dn-systems.de> effectively you have a directory on some server containing all the plugin files. To be 100% comfortable with whatever internet restrictions an OpenVAS user might have you should simply make this feed directory available with rsync, ftp and http. If you use a Apache with it's directory-index feature somebody could use a recursive wget, curl or BSD fetch to retrieve all plugins. If you configure your HTTP server to set the correct HTTP headers derived from the plugin files timestamp tools like wget etc. are intelligent enough to skip downloading all those files if they are started in mirror-mode. To be super comfortable, you should supply a sample call for wget, curl and fetch in mirror mode, along with a sample call to rsync. -- Dirk Jagdmann : Coder Tel. +49-5121-28989-15 -- DN-Systems Enterprise Internet Solutions GmbH Hornemannstr. 11 31137 Hildesheim, Germany Tel. +49-5121-28989-0 Fax. +49-5121-28989-11 Handelsregister HRB-3213 Amtsgericht Hildesheim Gesch?ftsf?hrer: Lukas Grunwald From kjordan3 at gmail.com Fri Apr 24 15:26:00 2009 From: kjordan3 at gmail.com (kjordan3@gmail.com) Date: Fri, 24 Apr 2009 13:26:00 +0000 Subject: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up In-Reply-To: Message-ID: <00221532c8ac05dec304684cf0a5@google.com> Fantastic! Keep me posted and let me know how/if I can lend a hand. -Kevin On Apr 24, 2009 5:40am, Chandrashekhar B wrote: > We saw the same issue reporting in one of our scan. We'll resolve this. > Chandra. > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org > [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of > Jan-Oliver > Wagner > Sent: Friday, April 24, 2009 2:53 AM > To: openvas-plugins at wald.intevation.org > Cc: kjordan3 at gmail.com > Subject: Re: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up > Hello all, > anyone feels like digging into this issue reported by Kevin? > Best > Jan > On Thursday 23 April 2009 00:07:35 you wrote: > > I found a response from you on the openvas-plugins mailing list archive > > regarding this plugin and was hoping to work with you to find the > answer. > > > > Here is a link to that message: > > http://marc.info/?l=openvas-plugins&m=121084160209010&w=2 > > > > In your response you mentioned a possible explanation. The > msrpc_dcom2.nasl > > script had to be removed from openVAS and thus a dependency for the > > msrpc_dcom.nasl script is missing. You then stated you might be able to > > reproduce the problem but didn't have that service running on your XPSP2 > > system. Here's where I can help. Just this morning while testing OpenVAS > > for the first time it reported the existence of this vulnerability on a > > computer I use. However I have verified the patch for the vulnerability > and > > tested that computer with another scanner which reported that the > computer > > is indeed not vulnerable. I can re-create the scenario as needed and > offer > > whatever help to debug or trace the issue. As this particular > vulnerability > > was associated with a widely known worm, I think it is very important > for > > OpenVAS to be accurate. I have an affinity for the efforts on this > project > > and may even lend my security and coding expertise in the future. > -- > Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B > 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090424/dfd345e3/attachment.htm From kjordan3 at gmail.com Fri Apr 24 17:22:39 2009 From: kjordan3 at gmail.com (kjordan3@gmail.com) Date: Fri, 24 Apr 2009 15:22:39 +0000 Subject: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up In-Reply-To: <4EE0B71626064E85BC2F8D9F18CA2414@bchandra> Message-ID: <000325574d2a2de83b04684e91f2@google.com> Ok, It will be later today or maybe Monday, but I will check it and respond. Do you have a specific version for me to check out? Or is it packaged? Kevin On Apr 24, 2009 9:24am, Chandrashekhar B wrote: > Committed now, please check it and let me know if you still find the > issue. > Chandra. > ________________________________________ > From: kjordan3 at gmail.com [mailto:kjordan3 at gmail.com] > Sent: Friday, April 24, 2009 6:56 PM > To: Chandrashekhar B; Jan-Oliver Wagner; > openvas-plugins at wald.intevation.org; kjordan3 at gmail.com > Subject: Re: RE: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up > Fantastic! Keep me posted and let me know how/if I can lend a hand. > -Kevin > On Apr 24, 2009 5:40am, Chandrashekhar B bchandra at secpod.com> wrote: > > We saw the same issue reporting in one of our scan. We'll resolve this. > > > > > > > > Chandra. > > > > > > > > -----Original Message----- > > > > From: openvas-plugins-bounces at wald.intevation.org > > > > [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of > Jan-Oliver > > > > Wagner > > > > Sent: Friday, April 24, 2009 2:53 AM > > > > To: openvas-plugins at wald.intevation.org > > > > Cc: kjordan3 at gmail.com > > > > Subject: Re: [Openvas-plugins] OpenVAS plugin 11808 Question Follow-up > > > > > > > > Hello all, > > > > > > > > anyone feels like digging into this issue reported by Kevin? > > > > > > > > Best > > > > > > > > Jan > > > > > > > > On Thursday 23 April 2009 00:07:35 you wrote: > > > > > I found a response from you on the openvas-plugins mailing list > archive > > > > > regarding this plugin and was hoping to work with you to find the > answer. > > > > > > > > > > Here is a link to that message: > > > > > http://marc.info/?l=openvas-plugins&m=121084160209010&w=2 > > > > > > > > > > In your response you mentioned a possible explanation. The > > > > msrpc_dcom2.nasl > > > > > script had to be removed from openVAS and thus a dependency for the > > > > > msrpc_dcom.nasl script is missing. You then stated you might be able > to > > > > > reproduce the problem but didn't have that service running on your > XPSP2 > > > > > system. Here's where I can help. Just this morning while testing > OpenVAS > > > > > for the first time it reported the existence of this vulnerability on > a > > > > > computer I use. However I have verified the patch for the > vulnerability > > > > and > > > > > tested that computer with another scanner which reported that the > computer > > > > > is indeed not vulnerable. I can re-create the scenario as needed and > offer > > > > > whatever help to debug or trace the issue. As this particular > > > > vulnerability > > > > > was associated with a widely known worm, I think it is very important > for > > > > > OpenVAS to be accurate. I have an affinity for the efforts on this > project > > > > > and may even lend my security and coding expertise in the future. > > > > > > > > -- > > > > Dr. Jan-Oliver Wagner | ++49-541-335 08 30 | http://www.intevation.de/ > > > > Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B > 18998 > > > > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > > > > _______________________________________________ > > > > Openvas-plugins mailing list > > > > Openvas-plugins at wald.intevation.org > > > > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090424/6f4fbba5/attachment.html