From bchandra at secpod.com Wed Apr 1 11:44:00 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 1 Apr 2009 15:14:00 +0530 Subject: [Openvas-devel] SMB authentication problems... In-Reply-To: <200903312200.04382.timb@nth-dimension.org.uk> References: <200903312200.04382.timb@nth-dimension.org.uk> Message-ID: I tested this patch and it seems to partially work. It works when I try anonymous SMB login but, says "SMB ERROR: ACCESS DENIED" when I supply credentials. I think the hash computation logic might not be working appropriately. So, if we include this patch, it'll break the existing Plugins that work based on credentials. I suggest, we write new functions in smb_nt.inc to separately call NTLM functions, at least till the time we fix the credentials based check. With this patch included, both ms08-067-conficker.nasl and secpod_ms08-067_900056.nasl work anonymously. Thanks, Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Tim Brown Sent: Wednesday, April 01, 2009 2:30 AM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] SMB authentication problems... All, Attached is a patch which essentially provides a forward port of Nessus's old LM/NTLM et al routines for SMB (with some minor changes to use GNU TLS where possible). These were taken from a Nessus 2.0.9 tar ball I had to hand. They seem broken but if we merge this patch at least we'll have a starting point to fix whatever bugs may exist. I'll take a further look when I get a chance but in the meantime if anyone wants to have a play, feel free. Cheers, Tim -- Tim Brown From bchandra at secpod.com Thu Apr 2 07:28:56 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 2 Apr 2009 10:58:56 +0530 Subject: [Openvas-devel] SMB authentication problems... In-Reply-To: <200904020108.35909.timb@nth-dimension.org.uk> References: <200903312200.04382.timb@nth-dimension.org.uk> <200904020108.35909.timb@nth-dimension.org.uk> Message-ID: <9EABA11335A141FBB5AD59B53B21CBED@bchandra> -----Original Message----- From: Tim Brown [mailto:timb at nth-dimension.org.uk] Sent: Thursday, April 02, 2009 5:39 AM To: Chandrashekhar B Cc: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] SMB authentication problems... On Wednesday 01 April 2009 10:44:00 Chandrashekhar B wrote: >> I tested this patch and it seems to partially work. It works when I try >> anonymous SMB login but, says "SMB ERROR: ACCESS DENIED" when I supply >> credentials. I think the hash computation logic might not be working >> appropriately. >> >> So, if we include this patch, it'll break the existing Plugins that work >> based on credentials. I suggest, we write new functions in smb_nt.inc to >> separately call NTLM functions, at least till the time we fix the >> credentials based check. >> >> With this patch included, both ms08-067-conficker.nasl and >> secpod_ms08-067_900056.nasl work anonymously. > I think SMB is a similar case to SSH where we need the first class > protocol support that using a major projects code (Samba I suppose) would > give us. As such I fully support any work in this direction. (Another > possibility would > be to port Core's impacket to NASL with NASL functions for any crypto > specific elements?) I would think they can co-exist, Samba/WMI methods for all high level functionality like access to registry, file, process etc., and for all low level functionality (SMB, DCERPC) we need an alternative to smb_nt.inc. This is where I think Impacket could help. If we could fix the current crypto patch you provided, it'll be very useful for now. Thanks, Chandra. From timb at nth-dimension.org.uk Thu Apr 2 02:08:34 2009 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 2 Apr 2009 01:08:34 +0100 Subject: [Openvas-devel] SMB authentication problems... In-Reply-To: References: <200903312200.04382.timb@nth-dimension.org.uk> Message-ID: <200904020108.35909.timb@nth-dimension.org.uk> On Wednesday 01 April 2009 10:44:00 Chandrashekhar B wrote: > I tested this patch and it seems to partially work. It works when I try > anonymous SMB login but, says "SMB ERROR: ACCESS DENIED" when I supply > credentials. I think the hash computation logic might not be working > appropriately. > > So, if we include this patch, it'll break the existing Plugins that work > based on credentials. I suggest, we write new functions in smb_nt.inc to > separately call NTLM functions, at least till the time we fix the > credentials based check. > > With this patch included, both ms08-067-conficker.nasl and > secpod_ms08-067_900056.nasl work anonymously. I think SMB is a similar case to SSH where we need the first class protocol support that using a major projects code (Samba I suppose) would give us. As such I fully support any work in this direction. (Another possibility would be to port Core's impacket to NASL with NASL functions for any crypto specific elements?) Tim -- Tim Brown From jan-oliver.wagner at intevation.de Thu Apr 2 09:05:01 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 2 Apr 2009 08:05:01 +0100 Subject: [Openvas-devel] SMB authentication problems... In-Reply-To: References: <200903312200.04382.timb@nth-dimension.org.uk> Message-ID: <200904020905.03081.jan-oliver.wagner@intevation.de> On Mittwoch, 1. April 2009, Chandrashekhar B wrote: > I tested this patch and it seems to partially work. It works when I try > anonymous SMB login but, says "SMB ERROR: ACCESS DENIED" when I supply > credentials. I think the hash computation logic might not be working > appropriately. hm. Anyone wants to dig into this? > So, if we include this patch, it'll break the existing Plugins that work > based on credentials. I suggest, we write new functions in smb_nt.inc to > separately call NTLM functions, at least till the time we fix the > credentials based check. Beaking is not an option. New functions are a better idea. 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 openvas-bugs at wald.intevation.org Fri Apr 3 20:26:17 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 3 Apr 2009 20:26:17 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B940=5D_openvas-cli?= =?utf-8?q?ent_2=2E0=2E3_doesn=27t_compile_cause_of_faulty_po/de=2E?= =?utf-8?q?po?= Message-ID: <20090403182617.7967940828@pyrosoma.intevation.org> Bugs item #940, was opened at 2009-04-03 18:26 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: openvas-client 2.0.3 doesn't compile cause of faulty po/de.po Resolution: None Severity: None Version: None Component: openvas-client Operating System: None Product: OpenVAS Hardware: None URL: Initial Comment: There's an error in the german translations which breaks the build. The attached patch fixes this. Please review & apply to trunk. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=940&group_id=29 From openvas-bugs at wald.intevation.org Fri Apr 3 20:32:08 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 3 Apr 2009 20:32:08 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B941=5D_Multithread?= =?utf-8?q?ed_compilation_doesn=27t_work=2E?= Message-ID: <20090403183208.10B0640828@pyrosoma.intevation.org> Bugs item #941, was opened at 2009-04-03 18:32 Status: Open Priority: 3 Submitted By: Stephan Kleine (bitshuffler) Assigned to: Nobody (None) Summary: Multithreaded compilation doesn't work. Resolution: None Severity: None Version: None Component: openvas-client Operating System: None Product: None Hardware: None URL: Initial Comment: If one tries to compile openvas-client with multiple threads ("make -jX" with X>1) it fails on Mandriva 2009 x86_64 SLE 10 x86_64 openSUSE 10.2 x86_64 openSUSE 11.1 i586 openSUSE Factory i586 with the following error: gcc -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall `sh ./cflags` -c pdf_output.c pdf_output.c: In function 'arglist_to_pdf': pdf_output.c:276: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result pdf_output.c:318: warning: ignoring return value of 'chdir', declared with attribute warn_unused_result gcc -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall `sh ./cflags` -c prefs_dialog/readonly.c /usr/bin/make -C ../src/util make[2]: Entering directory `/usr/src/packages/BUILD/openvas-client-2.0.3/src/util' gcc -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall `sh ./cflags` -c openvas_ssh_key_create.c sh: ./cflags: No such file or directory openvas_ssh_key_create.c:37:31: error: openvas_ssh_login.h: No such file or directory In file included from openvas_ssh_key_create.c:38: openvas_ssh_key_create.h:39:18: error: glib.h: No such file or directory In file included from openvas_ssh_key_create.c:38: openvas_ssh_key_create.h:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'openvas_ssh_key_create' openvas_ssh_key_create.h:43: error: expected ')' before '*' token openvas_ssh_key_create.h:44: error: expected ')' before '*' token openvas_ssh_key_create.h:45: error: expected ')' before '*' token openvas_ssh_key_create.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ensure_dir' openvas_ssh_key_create.c:39:25: error: nessus_i18n.h: No such file or directory openvas_ssh_key_create.c:40:23: error: error_dlg.h: No such file or directory openvas_ssh_key_create.c:41:25: error: glib/gstdio.h: No such file or directory openvas_ssh_key_create.c:42:21: error: context.h: No such file or directory openvas_ssh_key_create.c:55: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ensure_single_dir' openvas_ssh_key_create.c:79: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ensure_dir' openvas_ssh_key_create.c:124: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'openvas_ssh_privkey_create' openvas_ssh_key_create.c:204: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'openvas_ssh_pubkey_create' openvas_ssh_key_create.c:274: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'openvas_ssh_key_create' openvas_ssh_key_create.c:299: error: expected ')' before '*' token openvas_ssh_key_create.c:335: error: expected ')' before '*' token openvas_ssh_key_create.c:352: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token make[2]: *** [openvas_ssh_key_create.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/usr/src/packages/BUILD/openvas-client-2.0.3/src/util' make[1]: *** [util] Error 2 make[1]: Leaving directory `/usr/src/packages/BUILD/openvas-client-2.0.3/nessus' make: *** [client] Error It would be great if that could be fixed because multithreaded compilation speeds up the compilation process quite noticeable. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=941&group_id=29 From felix.wolfsteller at intevation.de Mon Apr 6 12:40:02 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Mon, 6 Apr 2009 12:40:02 +0200 Subject: [Openvas-devel] Don't miss the OpenVAS DevCon #2 Message-ID: <200904061240.02702.felix.wolfsteller@intevation.de> Hi The OpenVAs DevCon #2 (9th - 12th July in Osnabr?ck, Germany) is getting closer and closer. I booked the first couple of hotel- rooms today and would like anyone who does not wish to miss it to send me a mail as soon as possible (even if you are not 100% sure). The conference will be exciting and fun. A user workshop is planned as well and everything and everybody is open for new ideas. We will be productive and ready for the future. Even the weather will be nice. For preliminary details see http://openvas.org/openvas-devcon2.html . To register, send an email to openvas-devcon at intevation.de . Enjoy, Felix -- Felix Wolfsteller | ?++49-541-335 08 3451 ?| ?http://www.intevation.de/ PGP Key: 39DE0100 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 jan-oliver.wagner at intevation.de Mon Apr 6 16:52:21 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 6 Apr 2009 15:52:21 +0100 Subject: [Openvas-devel] Dropping NASL_LEVEL Message-ID: <200904061652.24195.jan-oliver.wagner@intevation.de> 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 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-devel] Fwd: 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 lists at securityspace.com Mon Apr 6 20:10:49 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 06 Apr 2009 14:10:49 -0400 Subject: [Openvas-devel] [Openvas-commits] r3025 - in trunk/openvas-plugins: . scripts In-Reply-To: <20090404222941.E59C3407F0@pyrosoma.intevation.org> References: <20090404222941.E59C3407F0@pyrosoma.intevation.org> Message-ID: <49DA45A9.3080704@securityspace.com> scm-commit at wald.intevation.org wrote: > trunk/openvas-plugins/scripts/remote-MS07-040.nasl Please test your submissions before submitting them. There are syntax and logic errors in this script. Thomas From lists at securityspace.com Mon Apr 6 21:12:00 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 06 Apr 2009 15:12:00 -0400 Subject: [Openvas-devel] Dropping NASL_LEVEL In-Reply-To: <200904061652.24195.jan-oliver.wagner@intevation.de> References: <200904061652.24195.jan-oliver.wagner@intevation.de> Message-ID: <49DA5400.7050009@securityspace.com> Further to my previous email, we have updated our build procedures so that NASL_LEVEL is no longer being introduced in any new scripts we submit. Thomas Thomas Reinke wrote: > Jan-Oliver Wagner wrote: >> 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 >> > > The only reason we are using it today is that it is still part > of our script build process. No script that we produce that > I am aware of is running on any daemon with a low enough script > level to warrant the conditional lines. > > We'll update our build process to stop producing scripts with > these levels in them. > > Thomas > From jan-oliver.wagner at intevation.de Tue Apr 7 09:02:44 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 7 Apr 2009 08:02:44 +0100 Subject: [Openvas-devel] Dropping NASL_LEVEL In-Reply-To: <49DA5400.7050009@securityspace.com> References: <200904061652.24195.jan-oliver.wagner@intevation.de> <49DA5400.7050009@securityspace.com> Message-ID: <200904070902.46889.jan-oliver.wagner@intevation.de> On Montag, 6. April 2009, Thomas Reinke wrote: > Further to my previous email, we have updated our build procedures so > that NASL_LEVEL is no longer being introduced in any new scripts we > submit. cool. Thanks! 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 openvas-bugs at wald.intevation.org Tue Apr 7 09:21:30 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 7 Apr 2009 09:21:30 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B944=5D_OpenVAS-Cli?= =?utf-8?q?ent_doesnt_restore_choices_in_View-Menu_correctly=2E?= Message-ID: <20090407072130.6F83640788@pyrosoma.intevation.org> Bugs item #944, was opened at 2009-04-07 07:21 Status: Open Priority: 1 Submitted By: Felix Wolfsteller (felix) Assigned to: Nobody (None) Summary: OpenVAS-Client doesnt restore choices in View-Menu correctly. Resolution: None Severity: enhancement Version: None Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: The client behaves weird regarding optional view of message log and toolbar. 1) Start client. In view enable both toolbar and message log. 2) Close and restart client. toolbar is there, message log isnt. (incorrect) 3) Switch toolbar off, message log on. 4) Restart. Neither toolbar nor message log is there (correct). 5) Switch toolbar off, message log off. 6) Restart. toolbar is not there message log is there (incorrect). Client shall restore these options correctly. Other options (size of window, relative size of option vs scopetree- area) could be restored as well. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=944&group_id=29 From geoff at galitz.org Tue Apr 7 11:17:25 2009 From: geoff at galitz.org (Geoff Galitz) Date: Tue, 7 Apr 2009 11:17:25 +0200 Subject: [Openvas-devel] hyperlatex processor Message-ID: Can anyone point me to a recommended hyperlatex processor for the Windows platform (needed for openvas documentation)? --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090407/29722304/attachment.htm From felix.wolfsteller at intevation.de Tue Apr 7 11:40:26 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 7 Apr 2009 11:40:26 +0200 Subject: [Openvas-devel] hyperlatex processor In-Reply-To: References: Message-ID: <200904071140.27196.felix.wolfsteller@intevation.de> Hi Geoff I know there is Lyx for windows (http://www.lyx.org/Download). Not sure how easy it is to install, and whether it imports out tex-files smoothly (I remember it was hairy to work with long time ago). hth felix On Tuesday 07 April 2009 11:17:25 Geoff Galitz wrote: > Can anyone point me to a recommended hyperlatex processor for the Windows > platform (needed for openvas documentation)? > > > > > > > > --------------------------------- > Geoff Galitz > Blankenheim NRW, Germany > http://www.galitz.org/ > http://german-way.com/blog/ -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 felix.wolfsteller at intevation.de Tue Apr 7 12:32:17 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 7 Apr 2009 12:32:17 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug Message-ID: <200904071232.17754.felix.wolfsteller@intevation.de> Time has come to get rid of the concurrent checks problem. Some bug prevents checks to result in a deterministic report if "Checks to perform concurrently" is set != 1. The proposed solution (set "Checks to perform concurrently" != 1) is a workaround at best. Therefore it is now time to find and eliminate this bug. I am calling for help. The main bug report is http://bugs.openvas/779 but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might be connected to it. It seems that the bug appears only when local checks are employed. Any help (logs, openvasrcs, tons of lines of code, words of encouragement, insights) would be greatly appreciated. felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 felix.wolfsteller at intevation.de Tue Apr 7 12:34:36 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 7 Apr 2009 12:34:36 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904071232.17754.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> Message-ID: <200904071234.36133.felix.wolfsteller@intevation.de> Sorry, the references are obviously http://bugs.openvas.com/779 and eventually http://bugs.openvas.com/788 and http://bugs.openvas.com/886 --felix On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > The main bug report is > http://bugs.openvas/779 > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > be connected to it. -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 openvas-bugs at wald.intevation.org Tue Apr 7 13:03:32 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 7 Apr 2009 13:03:32 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B945=5D_Multiple_im?= =?utf-8?q?ports_causes_warnings_in_dump_and_Namespace_collission_a?= =?utf-8?q?cross_different_files?= Message-ID: <20090407110332.05005407A1@pyrosoma.intevation.org> Bugs item #945, was opened at 2009-04-07 16:33 Status: Open Priority: 3 Submitted By: Chandrashekhar B (chandra) Assigned to: Nobody (None) Summary: Multiple imports causes warnings in dump and Namespace collission across different files Resolution: None Severity: None Version: None Component: openvas-libnasl Operating System: None Product: None Hardware: None URL: Initial Comment: If plugin X imports an inc file A which in turn depends on another inc file B. If X tries to import B, openvas complains saying "already defined function". This indicates that the same inc cannot be imported multiple times, in a plugin launch scope. This causes another issue: Two inc's cannot have the same function definition. When these two inc's are imported in a single plugin, namespace collision occurs. Even the variables collide if they aren't specified explicitly as local. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=945&group_id=29 From geoff at galitz.org Wed Apr 8 23:12:43 2009 From: geoff at galitz.org (Geoff Galitz) Date: Wed, 08 Apr 2009 14:12:43 -0700 Subject: [Openvas-devel] EN doc patches Message-ID: <9517.1239225163@sonic.net> I have included two patches for the English language version of the compendium. The first is simple editing for grammar and flow for the "About this Compendium" section. The changes in flow center around shortening applicable statements. The second patch documents changes in the ChangeLog. I plan on going through subsequent sections for grammar and flow and then going back to make fill in new content where it is needed. ----------------------------------------- Geoff Galitz Blankenheim, Germany http://www.galitz.org http://german-way.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog-about.diff Type: application/octet-stream Size: 22099 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090408/76e6829d/ChangeLog-about-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: compendium_about.diff Type: application/octet-stream Size: 206705 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090408/76e6829d/compendium_about-0001.obj From michael.wiegand at intevation.de Thu Apr 9 08:42:38 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 9 Apr 2009 08:42:38 +0200 Subject: [Openvas-devel] EN doc patches In-Reply-To: <9517.1239225163@sonic.net> References: <9517.1239225163@sonic.net> Message-ID: <20090409064237.GA26070@intevation.de> * Geoff Galitz [ 9. Apr 2009]: > I have included two patches for the English language version of the > compendium. > > The first is simple editing for grammar and flow for the "About this > Compendium" section. The changes in flow center around shortening > applicable statements. The second patch documents changes in the > ChangeLog. > > I plan on going through subsequent sections for grammar and flow and > then going back to make fill in new content where it is needed. Thanks a lot, I'll take a look at your submission and integrate it into the SVN repository. If you are working on an SVN checkout, you can use SVN to automatically create patches for you, if you want to keep the attachment size small. Simply change into the openvas-compendium directory and use the command svn diff > compendium-edits.patch and attach the resulting file. SVN will create an unified diff which makes it easy for other to directly see your changes and to apply them to the trunk. If there is anything I can help you with, let me know. 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-devel/attachments/20090409/e17be471/attachment.pgp From geoff at galitz.org Thu Apr 9 10:51:11 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 9 Apr 2009 10:51:11 +0200 Subject: [Openvas-devel] EN doc patches In-Reply-To: <20090409064237.GA26070@intevation.de> References: <9517.1239225163@sonic.net> <20090409064237.GA26070@intevation.de> Message-ID: <9DFA1925A5774761A7BFC976171B4A69@geoffPC> Thanks. I'm using Tortoise SVN for the first time to manage my changes to the compendium so there is a little learning curve there for me (I've used the standard command line Linux SVN in the past for other projects). I'll make sure further patches are in the unified diff format rather than the one I sent along initially. If you haven't started on integration of the patch, yet, I can resubmit the one I did yesterday. -geoff --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ From michael.wiegand at intevation.de Thu Apr 9 10:59:31 2009 From: michael.wiegand at intevation.de ('Michael Wiegand') Date: Thu, 9 Apr 2009 10:59:31 +0200 Subject: [Openvas-devel] EN doc patches In-Reply-To: <9DFA1925A5774761A7BFC976171B4A69@geoffPC> References: <9517.1239225163@sonic.net> <20090409064237.GA26070@intevation.de> <9DFA1925A5774761A7BFC976171B4A69@geoffPC> Message-ID: <20090409085931.GC26070@intevation.de> * Geoff Galitz [ 9. Apr 2009]: > If you haven't started on integration of the patch, yet, I can resubmit the > one I did yesterday. Don't worry, I've already reviewed it and added your changes to the repository. Thanks for you efforts! 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-devel/attachments/20090409/10def2f5/attachment.pgp From labeneator at gmail.com Thu Apr 9 11:28:18 2009 From: labeneator at gmail.com (Lmwangi) Date: Thu, 9 Apr 2009 12:28:18 +0300 Subject: [Openvas-devel] Standardize Logging for OpenVAS - CR #29 Message-ID: <1e6e35b60904090228n750efd5bm1fd1ef1974f08ec6@mail.gmail.com> I have created a CR ( which is a bit sparse at the moment ) to handle logging for the OpenVAS project in http://www.openvas.org/openvas-cr-29.html (yet to be published) trunk/doc/website/openvas-cr-29.htm (subversion) I was thinking of using glib's debug & messaging functions for this. Anyone with suggestions/improvements? Regards, Laban. From openvas-bugs at wald.intevation.org Thu Apr 9 10:19:03 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 9 Apr 2009 10:19:03 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B950=5D_Client-serv?= =?utf-8?q?ing_children_do_not_notice_openvasd_death?= Message-ID: <20090409081903.5B49740820@pyrosoma.intevation.org> Bugs item #950, was opened at 2009-04-09 08:19 Status: Open Priority: 3 Submitted By: Felix Wolfsteller (felix) Assigned to: Nobody (None) Summary: Client-serving children do not notice openvasd death Resolution: None Severity: None Version: None Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: When openvasd is killed its children that are connected to clients do not send a message to client (and quit), but just keep on going. Scenario: Start openvasd. Connect with a client, do a scan and stay connected. Kill openvasd. Delete the log files ($PREFIX/var/log/openvas/openvasd*). Keep on scanning with the client, you will not be able to find out what the server machine was doing (logs files stay untouched). Proposed behaviour: When 'father' is killed, sill connected children write a log entry, send byebye to the client, close the connection and die too. This should be handled differently in the upcoming OMP protocol (I think no need to take care of anything, because we are stateless. Otherwise reserve a response code for it). ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=950&group_id=29 From felix.wolfsteller at intevation.de Thu Apr 9 14:04:18 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Thu, 9 Apr 2009 14:04:18 +0200 Subject: [Openvas-devel] No eggs found - Need help with Concurrent Checks Bug In-Reply-To: <200904071232.17754.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> Message-ID: <200904091404.18699.felix.wolfsteller@intevation.de> Status update: My search so far was frustrating and fruitless. A couple of insights: - With recent versions of OpenVAS, timeout setting from client-side works. - My hypothesis, that timeout checking was faulty and nvts were incorrectly timed out seems to be false, as long as i can trust the logs. - The problem arises with the latest 1.0x versions, too (did not check the earlier ones, might be worth it), running with recent plugins. At least on the surface one can observe the same effects (reports differ between subsequent scans with number of concurrent checks 1/1+ ). - The number of concurrent checks/processes is changeable at many places in source, config and from client-side. However, in reality I never got it beyond 10. Technical mini wrap-up: - openvasd forks at incoming connection. The child has an array of processes that talk to the child through sockets (openvasd/pluginlaunch.c). Chandra populated nasl scripts with reporting functions (log_message etc) and found out that sometimes a script stops reporting in the middle of nowhere. Now, does the process really stop or do the message not arrive? E.g. when for some reason the inter-process communication in pluginlaunch breaks together, the script does its job but nobody notices. I hope we find (much) more, help me searching and Happy Easter felix On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > Time has come to get rid of the concurrent checks problem. > > Some bug prevents checks to result in a deterministic report if "Checks to > perform concurrently" is set != 1. > > The proposed solution (set "Checks to perform concurrently" != 1) is a > workaround at best. > > Therefore it is now time to find and eliminate this bug. I am calling for > help. > > The main bug report is > http://bugs.openvas/779 > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > be connected to it. > > It seems that the bug appears only when local checks are employed. > > Any help (logs, openvasrcs, tons of lines of code, words of encouragement, > insights) would be greatly appreciated. > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 jan-oliver.wagner at intevation.de Thu Apr 9 14:19:14 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 9 Apr 2009 13:19:14 +0100 Subject: [Openvas-devel] Standardize Logging for OpenVAS - CR #29 In-Reply-To: <1e6e35b60904090228n750efd5bm1fd1ef1974f08ec6@mail.gmail.com> References: <1e6e35b60904090228n750efd5bm1fd1ef1974f08ec6@mail.gmail.com> Message-ID: <200904091419.17024.jan-oliver.wagner@intevation.de> On Donnerstag, 9. April 2009, Lmwangi wrote: > I have created a CR ( which is a bit sparse at the moment ) to handle > logging for the OpenVAS project in > > http://www.openvas.org/openvas-cr-29.html (yet to be published) > > trunk/doc/website/openvas-cr-29.htm (subversion) > > I was thinking of using glib's debug & messaging functions for this. > Anyone with suggestions/improvements? it might be worth looking into http://library.gnome.org/devel/glib/stable/glib-Message-Logging.html thats pretty much what we need, isn't it? It seems to be introduced with GLib 2.6. Thats good as we require 2.6.0 for OpenVAS 2.0 since ever. Maybe a sample implementation helps to evaulate whether this is the way to go. 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 openvas-bugs at wald.intevation.org Thu Apr 9 21:21:25 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 9 Apr 2009 21:21:25 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B951=5D_Newlines_in?= =?utf-8?q?_script=5Fname=28=29_cause_serious_problems?= Message-ID: <20090409192125.97F614083A@pyrosoma.intevation.org> Bugs item #951, was opened at 2009-04-09 21:21 Status: Open Priority: 4 Submitted By: Jan-Oliver Wagner (jan) Assigned to: Nobody (None) Summary: Newlines in script_name() cause serious problems Resolution: None Severity: major Version: v2.0 Component: None Operating System: All Product: OpenVAS Hardware: None URL: Initial Comment: In case a script_name() has a string with a newline, eg: script_name(english:"Xplode 'module_wrapper.asp' SQL Injection and Cross Site Scripting Vulnerabilities "); then the client, when connecting will issue error like this: Could not parse 1.3.6.1.4.1.25623.1.0.100113 <|> Xplode 'module_wrapper.asp' SQL Injection and Cross Site Scripting Vulnerabilities Could not parse <|> infos <|> This script is Copyright (C) 2009 Mi; Risk factor : Medium <|> Determine if Xplode is prone to XSS and SQL-injection vulnerabilities <|> Web application abuses <|> 1.0 <|> NOCVE <|> 34419 <|> NOXREF <|> NOSIGNKEYS <|> NOTAG add_md5sum_to_plugin: Unknown plugin 1.3.6.1.4.1.25623.1.0.100113 Probably it is best to practice input sanitizing in script_name, so that newlines are turned into spaces or so. I am not sure though where the actual problem turns into effect. Maybe OTP protocol and later on the client. But there also seem to occur some problems on the server side. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=951&group_id=29 From jan-oliver.wagner at intevation.de Thu Apr 9 21:29:33 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 9 Apr 2009 21:29:33 +0200 Subject: [Openvas-devel] [openvas-Bugs][951] Newlines in script_name() cause serious problems In-Reply-To: <20090409192125.97F614083A@pyrosoma.intevation.org> References: <20090409192125.97F614083A@pyrosoma.intevation.org> Message-ID: <200904092129.33462.jan-oliver.wagner@intevation.de> Hi, this affects the 1.0.6 release of openvas-plugins for one script. I removed the script quickly from the feed. Does this problem justify a new release of openvas-plugins? Alternatively we could recommed to use a improved server so this problem can not happen anymore. On Thursday 09 April 2009 21:21:25 openvas-bugs at wald.intevation.org wrote: > Bugs item #951, was opened at 2009-04-09 21:21 > Status: Open > Priority: 4 > Submitted By: Jan-Oliver Wagner (jan) > Assigned to: Nobody (None) > Summary: Newlines in script_name() cause serious problems > Resolution: None > Severity: major > Version: v2.0 > Component: None > Operating System: All > Product: OpenVAS > Hardware: None > URL: > > > Initial Comment: > In case a script_name() has a string with a newline, eg: > > script_name(english:"Xplode 'module_wrapper.asp' SQL Injection and Cross > Site Scripting Vulnerabilities "); > > then the client, when connecting will issue error like this: > > Could not parse 1.3.6.1.4.1.25623.1.0.100113 <|> Xplode > 'module_wrapper.asp' SQL Injection and Cross Site Scripting Vulnerabilities > > Could not parse <|> infos <|> This script is Copyright (C) > 2009 Mi; Risk factor : Medium <|> Determine if Xplode is prone to XSS and > SQL-injection vulnerabilities <|> Web application abuses <|> 1.0 <|> NOCVE > <|> 34419 <|> NOXREF <|> NOSIGNKEYS <|> NOTAG > > add_md5sum_to_plugin: Unknown plugin 1.3.6.1.4.1.25623.1.0.100113 > > > > Probably it is best to practice input sanitizing in script_name, so that > newlines are turned into spaces or so. > > I am not sure though where the actual problem turns into effect. > Maybe OTP protocol and later on the client. > But there also seem to occur some problems on the > server side. -- 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 geoff at galitz.org Fri Apr 10 00:08:14 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 09 Apr 2009 15:08:14 -0700 Subject: [Openvas-devel] EN doc patches Message-ID: <21006.1239314894@sonic.net> The following patches are for the "About the OpenVAS Project" section. Changes were mostly grammatical. Enjoy. -geoff ----------------------------------------- Geoff Galitz Blankenheim, Germany http://www.galitz.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090409/e04db320/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: about_project.diff Type: application/octet-stream Size: 1915 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090409/e04db320/about_project.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog.diff Type: application/octet-stream Size: 549 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090409/e04db320/ChangeLog.obj From openvas-bugs at wald.intevation.org Mon Apr 13 04:40:16 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 13 Apr 2009 04:40:16 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B954=5D_Empty_repor?= =?utf-8?q?ts_in_Ubuntu_8=2E10?= Message-ID: <20090413024016.6E8B74078B@pyrosoma.intevation.org> Bugs item #954, was opened at 2009-04-13 02:40 Status: Open Priority: 3 Submitted By: Andrew S (andrew9) Assigned to: Nobody (None) Summary: Empty reports in Ubuntu 8.10 Resolution: None Severity: blocker Version: v2.0.1 Component: None Operating System: Linux Product: OpenVAS Hardware: Other URL: Initial Comment: Symptom: Reports are empty in Ubuntu 8.10. Packages installed: server 2.0.1, plugins 1.0.6, libraries 2.0.1, libnasl 2.0.1, client 2.0.3. All packages were installed from source on Ubuntu 8.10 desktop edition, with server and client on the same machine. All dependencies were satisfied during compilation. A certificate was generated using openvas-mkcert, and a user with no testing restrictions was created using openvas-adduser. To replicate: 1. Start the server from the command line by typing "sudo openvasd". Wait for plugins to load. 2. Start the client from the main menu. 3. Connect to the server using your username and key password. 4. Set the number of concurrent tests (I tried 1 and 4 with the same result). Check the boxes indicating to load dependencies automatically and to do so silently. 5. Select the NVTs to be conducted. 6. Open the assistant from the File menu. Enter the required information, including the IP address of the remote machine, and begin the test. 7. At the prompt, enter your key password again to connect. The test will begin, and the progress-bar popup will appear. At this point, Wireshark will confirm that the OpenVAS server is indeed probing the remote machine. The progress-bar popup will then disappear, and an entry for the report will appear in the lefthand pane. 8. Click on the entry for the report, which will be empty. If you look at openvasd.messages, the log entries will indicate "user starts a new scan... user testing... finished testing... test complete." openvasd.dump may (1) show that you didn't SSH-authenticate for local tests on the remote machine (but I wasn't doing local tests) and (2) list a bunch of irrelevant plugin dependencies that weren't satisfied. Please let me know if I can provide any more information. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=954&group_id=29 From jan-oliver.wagner at intevation.de Tue Apr 14 00:22:39 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 14 Apr 2009 00:22:39 +0200 Subject: [Openvas-devel] Remove "report_verbosity" and "log_verbosity" ? Message-ID: <200904140022.39756.jan-oliver.wagner@intevation.de> Hello, I wonder what the NASL variables and Global settings "report_verbosity" and "log_vebosity" are good for. (They are defined in openvas-plugins/scripts/global_settings.inc and used in various NASL scripts) Apparently they are meant to reduce the report volume. To me this looks like a broken concept, because any NASL script has to add consideration in a correct way instead of solving this in a central place. IMHO we should find more legant ways to reduce report volume (if necessary at all) rather than continue this inherited concept. Any opinions, comments? Best Jan -- 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 jan-oliver.wagner at intevation.de Tue Apr 14 00:27:44 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 14 Apr 2009 00:27:44 +0200 Subject: [Openvas-devel] Idea: Detector for silent exit's Message-ID: <200904140027.44894.jan-oliver.wagner@intevation.de> Hi, we have several scripts that do a silent exit() due to some reason. This makes user believe the NVT ran without identifying a vulnerability, though it simply ran across an internal problem and not even tried to identify anything. In such cases, at least a log_message() should be applied. However, wouldn't it make sense to extend the exit command with a check whether any report message has been created and issue a log_message() on its own in case the counter was 0? (The counter can be increased with any report message command). Comments? Best Jan -- 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 mime at gmx.de Tue Apr 14 11:09:13 2009 From: mime at gmx.de (Michael Meyer) Date: Tue, 14 Apr 2009 11:09:13 +0200 Subject: [Openvas-devel] Remove "report_verbosity" and "log_verbosity" ? In-Reply-To: <200904140022.39756.jan-oliver.wagner@intevation.de> References: <200904140022.39756.jan-oliver.wagner@intevation.de> Message-ID: <20090414090913.GA2765@m2.homelinux.org> Hello, *** Jan-Oliver Wagner wrote: > Apparently they are meant to reduce the report volume. > To me this looks like a broken concept, because any NASL script > has to add consideration in a correct way instead of solving > this in a central place. I use "report_verbosity" in a lot off my '*_detect.nasl' Plugins since some time. If the user checked "Quiet" in the Client under "Prefs->Global variable settings->Report verbosity", my '*_detect.nasl' Plugins will not report about a found Software, only store something in KB. So, IMHO, it could make sense to have a global Option "report_verbosity" for such Plugins. Micha From felix.wolfsteller at intevation.de Tue Apr 14 13:06:59 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 14 Apr 2009 13:06:59 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904071232.17754.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> Message-ID: <200904141306.59857.felix.wolfsteller@intevation.de> I found a rather small setup that might allow inspections: Setup: openvas-server on debian, target is a win xp machine (w/sp2 i think). Dependency at runtime enabled, plus following checks (Family, Name, OID): * Microsoft Bulletins, SMB Could Allow Remote Code Execution Vulnerability (957097), 900057 * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could Enable DOS Attacks (Q3298349), 11178 * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231 * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code Execution (956802), 900059 * Microsoft Bulletins, Windows Kernel Elevation of Privilege Vulnerability (954211), 900051 * Windows, Microsoft Windows NSlookup.exe Remote Code Execution Vulnerability, 900108 * . Windows, .NET JIT Compiler Vulnerability, 90010 * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024 On this setup reports from scans with concurrent checks == 1 and ==2 differ quite consequently. hth felix On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > Time has come to get rid of the concurrent checks problem. > > Some bug prevents checks to result in a deterministic report if "Checks to > perform concurrently" is set != 1. > > The proposed solution (set "Checks to perform concurrently" != 1) is a > workaround at best. > > Therefore it is now time to find and eliminate this bug. I am calling for > help. > > The main bug report is > http://bugs.openvas/779 > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > be connected to it. > > It seems that the bug appears only when local checks are employed. > > Any help (logs, openvasrcs, tons of lines of code, words of encouragement, > insights) would be greatly appreciated. > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 matt at mundell.ukfsn.org Tue Apr 14 13:20:36 2009 From: matt at mundell.ukfsn.org (Matthew Mundell) Date: 14 Apr 2009 11:19:36 -0001 Subject: [Openvas-devel] No eggs found - Need help with Concurrent Checks Bug In-Reply-To: Message of Thu, 9 Apr 2009 14:04:18 +0200. <200904091404.18699.felix.wolfsteller@intevation.de> Message-ID: <20090414111947.2A37CDEBD5@mail.ukfsn.org> > Status update: > > My search so far was frustrating and fruitless. > > > A couple of insights: > > - With recent versions of OpenVAS, timeout setting from client-side works. > > - My hypothesis, that timeout checking was faulty and nvts were incorrectly > timed out seems to be false, as long as i can trust the logs. > > - The problem arises with the latest 1.0x versions, too (did not check the > earlier ones, might be worth it), running with recent plugins. At least on > the surface one can observe the same effects (reports differ between > subsequent scans with number of concurrent checks 1/1+ ). > > - The number of concurrent checks/processes is changeable at many places in > source, config and from client-side. However, in reality I never got it > beyond 10. > > > Technical mini wrap-up: > > - openvasd forks at incoming connection. The child has an array of processes > that talk to the child through sockets (openvasd/pluginlaunch.c). Chandra > populated nasl scripts with reporting functions (log_message etc) and found > out that sometimes a script stops reporting in the middle of nowhere. Now, > does the process really stop or do the message not arrive? E.g. when for some > reason the inter-process communication in pluginlaunch breaks together, the > script does its job but nobody notices. > > I hope we find (much) more, help me searching > and > Happy Easter > felix > > On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > > Time has come to get rid of the concurrent checks problem. > > > > Some bug prevents checks to result in a deterministic report if "Checks to > > perform concurrently" is set != 1. > > > > The proposed solution (set "Checks to perform concurrently" != 1) is a > > workaround at best. > > > > Therefore it is now time to find and eliminate this bug. I am calling for > > help. > > > > The main bug report is > > http://bugs.openvas/779 > > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > > be connected to it. > > > > It seems that the bug appears only when local checks are employed. > > > > Any help (logs, openvasrcs, tons of lines of code, words of encouragement, > > insights) would be greatly appreciated. > > > > felix > > > -- > Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ > PGP Key: 39DE0100 > 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 From felix.wolfsteller at intevation.de Tue Apr 14 13:26:17 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 14 Apr 2009 13:26:17 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904141306.59857.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> <200904141306.59857.felix.wolfsteller@intevation.de> Message-ID: <200904141326.17333.felix.wolfsteller@intevation.de> Some evidence for chandras guess that it might have something to do with variable naming: make tests as described below, than apply the attached patch against secpod_ms08-071.nasl in servers plugin dir, restart the server and redrive the tests. -- felix On Tuesday 14 April 2009 13:06:59 Felix Wolfsteller wrote: > I found a rather small setup that might allow inspections: > > Setup: openvas-server on debian, target is a win xp machine (w/sp2 i > think). > > Dependency at runtime enabled, plus following checks (Family, Name, OID): > * Microsoft Bulletins, SMB Could Allow Remote Code Execution Vulnerability > (957097), 900057 > * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could Enable > DOS Attacks (Q3298349), 11178 > * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231 > * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code > Execution (956802), 900059 > * Microsoft Bulletins, Windows Kernel Elevation of Privilege Vulnerability > (954211), 900051 > * Windows, Microsoft Windows NSlookup.exe Remote Code Execution > Vulnerability, 900108 > * . Windows, .NET JIT Compiler Vulnerability, 90010 > * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024 > > On this setup reports from scans with concurrent checks == 1 and ==2 differ > quite consequently. > > hth > felix > > On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > > Time has come to get rid of the concurrent checks problem. > > > > Some bug prevents checks to result in a deterministic report if "Checks > > to perform concurrently" is set != 1. > > > > The proposed solution (set "Checks to perform concurrently" != 1) is a > > workaround at best. > > > > Therefore it is now time to find and eliminate this bug. I am calling for > > help. > > > > The main bug report is > > http://bugs.openvas/779 > > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > > be connected to it. > > > > It seems that the bug appears only when local checks are employed. > > > > Any help (logs, openvasrcs, tons of lines of code, words of > > encouragement, insights) would be greatly appreciated. > > > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: secpod_ms08-071.patch Type: text/x-diff Size: 658 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090414/86abd1d3/secpod_ms08-071.bin From openvas-bugs at wald.intevation.org Tue Apr 14 12:51:27 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 14 Apr 2009 12:51:27 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B957=5D_NVT_List_fi?= =?utf-8?q?ltering_sometimes_causes_segfault?= Message-ID: <20090414105127.3A726407ED@pyrosoma.intevation.org> Bugs item #957, was opened at 2009-04-14 10:51 Status: Open Priority: 3 Submitted By: Felix Wolfsteller (felix) Assigned to: Nobody (None) Summary: NVT List filtering sometimes causes segfault Resolution: None Severity: minor Version: v2.0.3 Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: All URL: Initial Comment: Occurs from time to time (so far never on the first try) under various conditions. Setup: Activate and deactivate (= empty) Filter on NVT-list. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=957&group_id=29 From bchandra at secpod.com Wed Apr 15 07:58:46 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 15 Apr 2009 11:28:46 +0530 Subject: [Openvas-devel] Idea: Detector for silent exit's In-Reply-To: <200904140027.44894.jan-oliver.wagner@intevation.de> References: <200904140027.44894.jan-oliver.wagner@intevation.de> Message-ID: <620AD577BD1942719F5E700EB9F06A33@bchandra> -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner Sent: Tuesday, April 14, 2009 3:58 AM To: openvas-devel at wald.intevation.org Subject: [Openvas-devel] Idea: Detector for silent exit's > Hi, > we have several scripts that do a silent exit() due to some reason. > This makes user believe the NVT ran without identifying a vulnerability, > though it simply ran across an internal problem and not even tried > to identify anything. > In such cases, at least a log_message() should be applied. > However, wouldn't it make sense to extend the exit command > with a check whether any report message has been created and > issue a log_message() on its own in case the counter was 0? > (The counter can be increased with any report message command). Nice idea! We could do this or instead of a counter, we can extend exit() to accept a optional log string and internally issue a log_message()? Thanks, Chandra. From jan-oliver.wagner at intevation.de Wed Apr 15 08:28:24 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 15 Apr 2009 08:28:24 +0200 Subject: [Openvas-devel] Idea: Detector for silent exit's In-Reply-To: <620AD577BD1942719F5E700EB9F06A33@bchandra> References: <200904140027.44894.jan-oliver.wagner@intevation.de> <620AD577BD1942719F5E700EB9F06A33@bchandra> Message-ID: <200904150828.26304.jan-oliver.wagner@intevation.de> On Mittwoch, 15. April 2009, Chandrashekhar B wrote: > > we have several scripts that do a silent exit() due to some reason. > > This makes user believe the NVT ran without identifying a vulnerability, > > though it simply ran across an internal problem and not even tried > > to identify anything. > > In such cases, at least a log_message() should be applied. > > > However, wouldn't it make sense to extend the exit command > > with a check whether any report message has been created and > > issue a log_message() on its own in case the counter was 0? > > (The counter can be increased with any report message command). > > Nice idea! We could do this or instead of a counter, we can extend exit() to > accept a optional log string and internally issue a log_message()? I was more having in mind to catch all the "exit()'s without telling why". If we extend the syntax of exit, then we need to touch all the 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 From bchandra at secpod.com Wed Apr 15 08:49:01 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 15 Apr 2009 12:19:01 +0530 Subject: [Openvas-devel] Idea: Detector for silent exit's In-Reply-To: <200904150828.26304.jan-oliver.wagner@intevation.de> References: <200904140027.44894.jan-oliver.wagner@intevation.de> <620AD577BD1942719F5E700EB9F06A33@bchandra> <200904150828.26304.jan-oliver.wagner@intevation.de> Message-ID: -----Original Message----- From: Jan-Oliver Wagner [mailto:jan-oliver.wagner at intevation.de] Sent: Wednesday, April 15, 2009 11:58 AM To: Chandrashekhar B Cc: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Idea: Detector for silent exit's On Mittwoch, 15. April 2009, Chandrashekhar B wrote: > > > we have several scripts that do a silent exit() due to some reason. > > > This makes user believe the NVT ran without identifying a vulnerability, > > > though it simply ran across an internal problem and not even tried > > > to identify anything. > > > In such cases, at least a log_message() should be applied. > > > > > However, wouldn't it make sense to extend the exit command > > > with a check whether any report message has been created and > > > issue a log_message() on its own in case the counter was 0? > > > (The counter can be increased with any report message command). > > >> Nice idea! We could do this or instead of a counter, we can extend exit() to >> accept a optional log string and internally issue a log_message()? > I was more having in mind to catch all the "exit()'s without telling why". > If we extend the syntax of exit, then we need to touch all the scripts. Function arguments can be implemented as optional, so we don't need to touch the existing scripts. Chandra. From jan-oliver.wagner at intevation.de Wed Apr 15 09:31:04 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 15 Apr 2009 09:31:04 +0200 Subject: [Openvas-devel] Idea: Detector for silent exit's In-Reply-To: References: <200904140027.44894.jan-oliver.wagner@intevation.de> <200904150828.26304.jan-oliver.wagner@intevation.de> Message-ID: <200904150931.06198.jan-oliver.wagner@intevation.de> On Mittwoch, 15. April 2009, Chandrashekhar B wrote: > > I was more having in mind to catch all the "exit()'s without telling why". > > If we extend the syntax of exit, then we need to touch all the scripts. > > Function arguments can be implemented as optional, so we don't need to touch > the existing scripts. I know, but it adds a redundant method to write some sort of log info and it is not clear to NASL developers what the meaning is. I prefer to stay with log_message() and then exit(). However, issueing the log_warning in case no message has been issued before exiting is a helful step in either case. BTW: we need to take care the case when the scripts are called for description. 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 felix.wolfsteller at intevation.de Wed Apr 15 09:55:57 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 15 Apr 2009 09:55:57 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904141326.17333.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> <200904141306.59857.felix.wolfsteller@intevation.de> <200904141326.17333.felix.wolfsteller@intevation.de> Message-ID: <200904150955.57483.felix.wolfsteller@intevation.de> Wrap-up of yesterdays hypothesis for which there is strong evidence. * Surface Problem: When "concurrent checks" is set >=2, scans lead to different reports (compared to "concurrent checks" == 1). This is observed for local checks only. * Hypothized Deep Problem: In NASL, variables are assumed to be global unless declared local. Local checks often employ variables with the same name (which in unfortunate condition makes them the variable actually). At some point NVTs seem to access variables declared by other NVTs or variables of commonly included 'nasl libraries' (e.g. .inc s). * Solution: I do not yet see an easy solution to that problem. For new scripts, authors should be careful with variable naming. I fear that any solution will be tedious and long work, eventually changing a great portion of the (10K!) NVTs and/or changing the NASL-Syntax or semantics (e.g. variables are implicit local). Any suggestions welcome, I will open a CR once a practicable idea surfaced. I recommend hard-setting the number of concurrent checks to 1 until its fixed. Eventually the limit could be conditioned on existance of a local check. -- felix On Tuesday 14 April 2009 13:26:17 Felix Wolfsteller wrote: > Some evidence for chandras guess that it might have something to do with > variable naming: > make tests as described below, than apply the attached patch against > secpod_ms08-071.nasl in servers plugin dir, restart the server and redrive > the tests. > > -- felix > > On Tuesday 14 April 2009 13:06:59 Felix Wolfsteller wrote: > > I found a rather small setup that might allow inspections: > > > > Setup: openvas-server on debian, target is a win xp machine (w/sp2 i > > think). > > > > Dependency at runtime enabled, plus following checks (Family, Name, OID): > > * Microsoft Bulletins, SMB Could Allow Remote Code Execution > > Vulnerability (957097), 900057 > > * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could > > Enable DOS Attacks (Q3298349), 11178 > > * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231 > > * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code > > Execution (956802), 900059 > > * Microsoft Bulletins, Windows Kernel Elevation of Privilege > > Vulnerability (954211), 900051 > > * Windows, Microsoft Windows NSlookup.exe Remote Code Execution > > Vulnerability, 900108 > > * . Windows, .NET JIT Compiler Vulnerability, 90010 > > * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024 > > > > On this setup reports from scans with concurrent checks == 1 and ==2 > > differ quite consequently. > > > > hth > > felix > > > > On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > > > Time has come to get rid of the concurrent checks problem. > > > > > > Some bug prevents checks to result in a deterministic report if "Checks > > > to perform concurrently" is set != 1. > > > > > > The proposed solution (set "Checks to perform concurrently" != 1) is a > > > workaround at best. > > > > > > Therefore it is now time to find and eliminate this bug. I am calling > > > for help. > > > > > > The main bug report is > > > http://bugs.openvas/779 > > > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 > > > might be connected to it. > > > > > > It seems that the bug appears only when local checks are employed. > > > > > > Any help (logs, openvasrcs, tons of lines of code, words of > > > encouragement, insights) would be greatly appreciated. > > > > > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 felix.wolfsteller at intevation.de Wed Apr 15 10:06:44 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 15 Apr 2009 10:06:44 +0200 Subject: [Openvas-devel] Idea: Detector for silent exit's In-Reply-To: <200904150931.06198.jan-oliver.wagner@intevation.de> References: <200904140027.44894.jan-oliver.wagner@intevation.de> <200904150931.06198.jan-oliver.wagner@intevation.de> Message-ID: <200904151006.44986.felix.wolfsteller@intevation.de> I would be happy with the result but unhappy with the proposed process. The check should not be linked directly to the exit command (it is suggested to have an exit() at the end of a nasl script but I doubt that it is consistently done) but rather be picked up when the server/pluginlauncher notices that a script has finished. In that case the log messages would cover a broader range of suspicious situations. Also, conencting it to the exit() command is somewhat breaking out of the nasl syntax. Suddenly there are counters outside of the nasl-script itself and to understand why certain scripts send a seemingly senseless log message before exiting a nasl developer has to know something about the interpreter ("It will do a s/exit()/log_message(12,"...","...")/g when the counters in the interpreter are still 0"). -- felix On Wednesday 15 April 2009 09:31:04 Jan-Oliver Wagner wrote: > On Mittwoch, 15. April 2009, Chandrashekhar B wrote: > > > I was more having in mind to catch all the "exit()'s without telling > > > why". If we extend the syntax of exit, then we need to touch all the > > > scripts. > > > > Function arguments can be implemented as optional, so we don't need to > > touch the existing scripts. > > I know, but it adds a redundant method to write some sort of log info and > it is not clear to NASL developers what the meaning is. I prefer to stay > with log_message() and then exit(). > > However, issueing the log_warning in case no message has been issued before > exiting is a helful step in either case. > BTW: we need to take care the case when the scripts are called for > description. > > Best > > Jan -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 Wed Apr 15 10:08:55 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 15 Apr 2009 13:38:55 +0530 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904150955.57483.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de><200904141306.59857.felix.wolfsteller@intevation.de><200904141326.17333.felix.wolfsteller@intevation.de> <200904150955.57483.felix.wolfsteller@intevation.de> Message-ID: <0F1CD2C3761C4543B6E2344497E3703E@bchandra> Felix, We did more testing here. The problem doesn't seem to be with variable names alone. It is with the returning of same socket descriptor when you call open_sock_tcp(). If you set concurrent checks to more than 1 and run, both plugins get the same value for open_sock_tcp(). And that's why it abruptly ends while they are running depending on the status of the socket. Whoever who gets the handle first will run successfully and the rest are time dependent. We got to debug open_sock_tcp(). The variables name conflict is also an issue, have filed a bug (#945) on that and we need to take care of this while coding NASL's. Thanks, Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Felix Wolfsteller Sent: Wednesday, April 15, 2009 1:26 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] Need help with Concurrent Checks Bug Wrap-up of yesterdays hypothesis for which there is strong evidence. * Surface Problem: When "concurrent checks" is set >=2, scans lead to different reports (compared to "concurrent checks" == 1). This is observed for local checks only. * Hypothized Deep Problem: In NASL, variables are assumed to be global unless declared local. Local checks often employ variables with the same name (which in unfortunate condition makes them the variable actually). At some point NVTs seem to access variables declared by other NVTs or variables of commonly included 'nasl libraries' (e.g. .inc s). * Solution: I do not yet see an easy solution to that problem. For new scripts, authors should be careful with variable naming. I fear that any solution will be tedious and long work, eventually changing a great portion of the (10K!) NVTs and/or changing the NASL-Syntax or semantics (e.g. variables are implicit local). Any suggestions welcome, I will open a CR once a practicable idea surfaced. I recommend hard-setting the number of concurrent checks to 1 until its fixed. Eventually the limit could be conditioned on existance of a local check. -- felix On Tuesday 14 April 2009 13:26:17 Felix Wolfsteller wrote: > Some evidence for chandras guess that it might have something to do with > variable naming: > make tests as described below, than apply the attached patch against > secpod_ms08-071.nasl in servers plugin dir, restart the server and redrive > the tests. > > -- felix > > On Tuesday 14 April 2009 13:06:59 Felix Wolfsteller wrote: > > I found a rather small setup that might allow inspections: > > > > Setup: openvas-server on debian, target is a win xp machine (w/sp2 i > > think). > > > > Dependency at runtime enabled, plus following checks (Family, Name, OID): > > * Microsoft Bulletins, SMB Could Allow Remote Code Execution > > Vulnerability (957097), 900057 > > * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could > > Enable DOS Attacks (Q3298349), 11178 > > * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231 > > * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code > > Execution (956802), 900059 > > * Microsoft Bulletins, Windows Kernel Elevation of Privilege > > Vulnerability (954211), 900051 > > * Windows, Microsoft Windows NSlookup.exe Remote Code Execution > > Vulnerability, 900108 > > * . Windows, .NET JIT Compiler Vulnerability, 90010 > > * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024 > > > > On this setup reports from scans with concurrent checks == 1 and ==2 > > differ quite consequently. > > > > hth > > felix > > > > On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > > > Time has come to get rid of the concurrent checks problem. > > > > > > Some bug prevents checks to result in a deterministic report if "Checks > > > to perform concurrently" is set != 1. > > > > > > The proposed solution (set "Checks to perform concurrently" != 1) is a > > > workaround at best. > > > > > > Therefore it is now time to find and eliminate this bug. I am calling > > > for help. > > > > > > The main bug report is > > > http://bugs.openvas/779 > > > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 > > > might be connected to it. > > > > > > It seems that the bug appears only when local checks are employed. > > > > > > Any help (logs, openvasrcs, tons of lines of code, words of > > > encouragement, insights) would be greatly appreciated. > > > > > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 From felix.wolfsteller at intevation.de Wed Apr 15 13:53:26 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 15 Apr 2009 13:53:26 +0200 Subject: [Openvas-devel] Need help with Concurrent Checks Bug In-Reply-To: <200904141306.59857.felix.wolfsteller@intevation.de> References: <200904071232.17754.felix.wolfsteller@intevation.de> <200904141306.59857.felix.wolfsteller@intevation.de> Message-ID: <200904151353.26593.felix.wolfsteller@intevation.de> It equally works well with just two nvts enabled (+depends): Both are in the 'Windows Bulletins' family. * secpod_ms09-001.nasl, OID 900069 : Vulnerabilities in SMB Could Allow Remote Code Execution (958687) * secpod_ms08-071.nasl, OID 900059 : Vulnerabilities in GDI Could Allow Remote Code Execution (956802) Running authorized against a WinXP, create different reports with concurrent checks ==1 and == 2. Renaming the variable share in secpod_ms09-001.nasl: ll96 and ll100 fixes this issue. That is very interesting because the variable name 'share' does not occur in any included files, but is handed as parameter to GetVer in secpod_smb_func. My first geuss was that it could have something to do with the named parameters ('share:share'), but when I renamed 'share' in secpod_ms08-071.nasl to match the new name from the second NVT, the problem occurs again, meaning that it is really the variable name that matters. -- felix On Tuesday 14 April 2009 13:06:59 Felix Wolfsteller wrote: > I found a rather small setup that might allow inspections: > > Setup: openvas-server on debian, target is a win xp machine (w/sp2 i > think). > > Dependency at runtime enabled, plus following checks (Family, Name, OID): > * Microsoft Bulletins, SMB Could Allow Remote Code Execution Vulnerability > (957097), 900057 > * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could Enable > DOS Attacks (Q3298349), 11178 > * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231 > * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code > Execution (956802), 900059 > * Microsoft Bulletins, Windows Kernel Elevation of Privilege Vulnerability > (954211), 900051 > * Windows, Microsoft Windows NSlookup.exe Remote Code Execution > Vulnerability, 900108 > * . Windows, .NET JIT Compiler Vulnerability, 90010 > * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024 > > On this setup reports from scans with concurrent checks == 1 and ==2 differ > quite consequently. > > hth > felix > > On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote: > > Time has come to get rid of the concurrent checks problem. > > > > Some bug prevents checks to result in a deterministic report if "Checks > > to perform concurrently" is set != 1. > > > > The proposed solution (set "Checks to perform concurrently" != 1) is a > > workaround at best. > > > > Therefore it is now time to find and eliminate this bug. I am calling for > > help. > > > > The main bug report is > > http://bugs.openvas/779 > > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might > > be connected to it. > > > > It seems that the bug appears only when local checks are employed. > > > > Any help (logs, openvasrcs, tons of lines of code, words of > > encouragement, insights) would be greatly appreciated. > > > > felix -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 openvas-bugs at wald.intevation.org Sun Apr 19 17:09:15 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Sun, 19 Apr 2009 17:09:15 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B971=5D_Openvas_is_?= =?utf-8?q?unabled_to_login_with_ssh_key?= Message-ID: <20090419150915.0FBE7407C2@pyrosoma.intevation.org> Bugs item #971, was opened at 19/04/2009 15:09 Status: Open Priority: 3 Submitted By: Andrea Briganti (kbyte) Assigned to: Nobody (None) Summary: Openvas is unabled to login with ssh key Resolution: None Severity: major Version: v2.0.3 Component: openvas-server Operating System: Linux Product: OpenVAS Hardware: None URL: Initial Comment: Openvas is unable to perform any local check with ssh login because it fails to use the login key. The openvasd.messages files reports these errors: user kbyte : launching gather-package-list.nasl against 192.168.89.2 [3181] shared_socket: Secret/SSH/socket is unknown process_internal_msg for gather-package-list.nasl returned -1 gather-package-list.nasl (process 3181) finished its job in 1.416 seconds user kbyte : Not launching deb_174_1.nasl against 192.168.89.2 because the key ssh/login/packages is missing (this is not an error) The concurrent checks value is set to 1. In the auth.log of target server I read: error: ssh_rsa_verify: len 257 > modlen 256 error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106) The ssl error 0407006A is: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 I tried to use the LSC Credential Manger and to create manually a ssh + p8 key and I'm able to login into server manually with generated keys. The openvas releases tested are the lastest stable and the source from the svn. The target system is a debian lenny server. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=971&group_id=29 From openvas-bugs at wald.intevation.org Mon Apr 20 13:21:49 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Mon, 20 Apr 2009 13:21:49 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B972=5D_openvas-lib?= =?utf-8?q?nasl_segfault_with_gpgme-1=2E1=2E6?= Message-ID: <20090420112149.EF5554079C@pyrosoma.intevation.org> Bugs item #972, was opened at 2009-04-20 11:21 Status: Open Priority: 3 Submitted By: Henrik Teichmann (henrik) Assigned to: Nobody (None) Summary: openvas-libnasl segfault with gpgme-1.1.6 Resolution: None Severity: None Version: None Component: None Operating System: None Product: None Hardware: None URL: Initial Comment: On a SLES10 SP2 System with selfcompiled gpgme-1.1.6 openvasd crashes with a segfault: $ gpgme-config --version $ 1.1.6 $ openvasd Loading the plugins... 1020 (out of 10678)[23837]() gpgme_engine_check_version_foo failed: GPGME/Invalid crypto engine Segmentation fault with gpgme-1.1.8 it works fine. See http://www.linux.hr/openvas/archive/index.php?d=2009-04-20#msg12700 prev. Bugreport: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=825&group_id=29 ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=972&group_id=29 From geoff at galitz.org Mon Apr 20 23:50:07 2009 From: geoff at galitz.org (Geoff Galitz) Date: Mon, 20 Apr 2009 14:50:07 -0700 Subject: [Openvas-devel] EN doc patch Message-ID: <25098.1240264207@sonic.net> This patch contains proofing corrections for the "About the OpenVAS Software Section" and the ChangeLog. ----------------------------------------- Geoff Galitz Blankenheim, Germany http://www.galitz.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090420/dffd0acf/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: about_software.diff Type: application/octet-stream Size: 1757 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090420/dffd0acf/about_software.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog.diff Type: application/octet-stream Size: 463 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090420/dffd0acf/ChangeLog.obj From jan-oliver.wagner at intevation.de Tue Apr 21 08:44:09 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 21 Apr 2009 08:44:09 +0200 Subject: [Openvas-devel] Systematic removal of superfluous checks-for-functions Message-ID: <200904210844.11833.jan-oliver.wagner@intevation.de> Hello, just another cleanup task for someone to pick up: There are several checks in the NASL scripts that test for existance of a built-in function. Many of these tests can removed because even OpenVAS 1.0 has most of these funtion as an integral part already. 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 michael.wiegand at intevation.de Tue Apr 21 08:46:06 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 21 Apr 2009 08:46:06 +0200 Subject: [Openvas-devel] EN doc patch In-Reply-To: <25098.1240264207@sonic.net> References: <25098.1240264207@sonic.net> Message-ID: <20090421064606.GB18319@intevation.de> * Geoff Galitz [20. Apr 2009]: > This patch contains proofing corrections for the "About the OpenVAS > Software Section" and the ChangeLog. Thanks a lot! I'll take a look at your patch and will probably commit it later today. 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-devel/attachments/20090421/3201626e/attachment.pgp From openvas-bugs at wald.intevation.org Tue Apr 21 18:03:01 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 21 Apr 2009 18:03:01 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B974=5D_Client_segf?= =?utf-8?q?ault_when_starting_new_scan?= Message-ID: <20090421160301.767D940742@pyrosoma.intevation.org> Bugs item #974, was opened at 2009-04-21 11:03 Status: Open Priority: 3 Submitted By: Ed Davison (edavison) Assigned to: Nobody (None) Summary: Client segfault when starting new scan Resolution: None Severity: critical Version: v2.0.2 Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: PC URL: Initial Comment: I am using all defaults on the scan settings and have set the host selection to 192.168.1.0/24 and then tell it to start and I get the following immediately: OpenVAS-Client Xlib: extension "RANDR" missing on display ":1.0". (OpenVAS-Client:22889): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated *** glibc detected *** OpenVAS-Client: free(): invalid pointer: 0x0809f41e *** ======= Backtrace: ========= /lib/libc.so.6[0xb7439a00] /lib/libc.so.6(cfree+0x89)[0xb743b6f9] OpenVAS-Client[0x8094d6c] OpenVAS-Client[0x80822d9] /usr/lib/libglib-2.0.so.0(g_hash_table_remove_all+0x88)[0xb771fdf8] /usr/lib/libglib-2.0.so.0(g_hash_table_destroy+0x33)[0xb7720123] OpenVAS-Client[0x8054126] OpenVAS-Client[0x80544eb] OpenVAS-Client[0x805e8b9] OpenVAS-Client[0x806bde7] OpenVAS-Client[0x8071294] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x4b)[0xb77f2a2b] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x13b)[0xb77e4ccb] /usr/lib/libgobject-2.0.so.0[0xb77f50a9] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x896)[0xb77f6556] /usr/lib/libgobject-2.0.so.0(g_signal_emit_by_name+0xee)[0xb77f9a2e] /usr/lib/libgtk-x11-2.0.so.0[0xb7d3af07] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x4b)[0xb77f2a2b] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x13b)[0xb77e4ccb] /usr/lib/libgobject-2.0.so.0[0xb77f50a9] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x896)[0xb77f6556] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb77f6719] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x55)[0xb7bc7015] /usr/lib/libgtk-x11-2.0.so.0[0xb7bc8b4c] /usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x4b)[0xb77f2a2b] /usr/lib/libgobject-2.0.so.0[0xb77e3289] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x13b)[0xb77e4ccb] /usr/lib/libgobject-2.0.so.0[0xb77f5518] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x896)[0xb77f6556] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb77f6719] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x55)[0xb7bc70a5] /usr/lib/libgtk-x11-2.0.so.0[0xb7bc7101] /usr/lib/libgtk-x11-2.0.so.0[0xb7c761d0] /usr/lib/libgobject-2.0.so.0[0xb77e3289] /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x13b)[0xb77e4ccb] /usr/lib/libgobject-2.0.so.0[0xb77f56cf] /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x71f)[0xb77f63df] /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb77f6719] /usr/lib/libgtk-x11-2.0.so.0[0xb7d7f544] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x127)[0xb7c6f0d7] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x347)[0xb7c703f7] /usr/lib/libgdk-x11-2.0.so.0[0xb7b12aca] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x188)[0xb7730948] /usr/lib/libglib-2.0.so.0[0xb77311a8] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1b7)[0xb7731557] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xc1)[0xb7c70821] OpenVAS-Client[0x808467d] /lib/libc.so.6(__libc_start_main+0xdc)[0xb73e9fdc] OpenVAS-Client[0x8052241] ======= Memory map: ======== 08048000-080ca000 r-xp 00000000 08:12 8561527 /usr/bin/OpenVAS-Client 080ca000-080cb000 r--p 00081000 08:12 8561527 /usr/bin/OpenVAS-Client 080cb000-080d2000 rw-p 00082000 08:12 8561527 /usr/bin/OpenVAS-Client 080d2000-0965d000 rw-p 080d2000 00:00 0 [heap] b5e00000-b5e21000 rw-p b5e00000 00:00 0 b5e21000-b5f00000 ---p b5e21000 00:00 0 b5fc2000-b5fcc000 r-xp 00000000 08:12 5481661 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 b5fcc000-b5fcd000 r--p 00009000 08:12 5481661 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 b5fcd000-b5fce000 rw-p 0000a000 08:12 5481661 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 b5ffd000-b6304000 rw-p b5ffd000 00:00 0 b6312000-b6413000 rw-p b6312000 00:00 0 b6413000-b6473000 rw-s 00000000 00:08 233603082 /SYSV00000000 (deleted) b6473000-b6dd7000 r--p 00000000 08:12 7310526 /usr/share/icons/gnome/icon-theme.cache b6dd7000-b701b000 r--p 00000000 08:12 7310533 /usr/share/icons/hicolor/icon-theme.cache b701b000-b701d000 r-xp 00000000 08:12 5705302 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so b701d000-b701e000 r--p 00001000 08:12 5705302 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so b701e000-b701f000 rw-p 00002000 08:12 5705302 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so b701f000-b7026000 r--s 00000000 08:12 5444147 /usr/lib/gconv/gconv-modules.cache b7026000-b7037000 r--p 00000000 08:12 7198390 /usr/share/fonts/ttf-bitstream-vera/Vera.ttf b7037000-b7039000 r--s 00000000 08:12 3399696 /var/cache/fontconfig/607fccf48f24023bb4836e9b54a058a0-x86.cache-2 b7039000-b7042000 r--s 00000000 08:12 3399687 /var/cache/fontconfig/87f5e051180a7a75f16eb6fe7dbd3749-x86.cache-2 b7042000-b7045000 r--s 00000000 08:12 3399692 /var/cache/fontconfig/7998293451e4b7352c3495b870377734-x86.cache-2 b7045000-b704b000 r--s 00000000 08:12 3399744 /var/cache/fontconfig/acc285bc1956c3c4bc7afb41d537a85a-x86.cache-2 b704b000-b704d000 r--s 00000000 08:12 3399689 /var/cache/fontconfig/f55bbeb01d684dc5b5f7b2c347cc42d9-x86.cache-2 b704d000-b704f000 r--s 00000000 08:12 3399742 /var/cache/fontconfig/76fa4b957c916922374347f144bde9da-x86.cache-2 b704f000-b7054000 r--s 00000000 08:12 3399740 /var/cache/fontconfig/4460665c0f3e88acdd4c85aa2f409b99-x86.cache-2 b7054000-b7058000 r--s 00000000 08:12 3399719 /var/cache/fontconfig/6355034d6588d5dc08dee953d4caf3fd-x86.cache-2 b7058000-b7066000 r--s 00000000 08:12 3399738 /var/cache/fontconfig/8d4af663993b81a124ee82e610bb31f9-x86.cache-2 b7066000-b7068000 r--s 00000000 08:12 3399712 /var/cache/fontconfig/cfde08ab28ad1d91784abb10973575e3-x86.cache-2 b7068000-b7073000 r--s 00000000 08:12 3399722 /var/cache/fontconfig/58318e6f46dd29577ed1e1d8fbe753bf-x86.cache-2 b7073000-b7080000 r--s 00000000 08:12 3399708 /var/cache/fontconfig/c175b612487af30ea3d94ae16ecc4270-x86.cache-2 b7080000-b708d000 r--s 00000000 08:12 3399701 /var/cache/fontconfig/221fd1126b80b777db535aea535e87ba-x86.cache-2 b708d000-b7092000 r--s 00000000 08:12 3399697 /var/cache/fontconfig/6cae3f256dd9cf1370ae54a008fe3d50-x86.cache-2 b7092000-b7098000 r--s 00000000 08:12 3399732 /var/cache/fontconfig/12b26b760a24f8b4feb03ad48a333a72-x86.cache-2 b7098000-b709a000 r--s 00000000 08:12 3399730 /var/cache/fontconfig/1dbbeb49bf9abb628447d57d1454c337-x86.cache-2 b709a000-b70ad000 r--s 00000000 08:12 3399729 /var/cache/fontconfig/4b5cf4386f1cde02a336ba961b4ac82d-x86.cache-2 b70ad000-b70b0000 r--s 00000000 08:12 3399728 /var/cache/fontconfig/d3169a704c6df42fa91819104f3eb94b-x86.cache-2 b70b0000-b70b8000 r--s 00000000 08:12 3399710 /var/cache/fontconfig/2b96f886f0b5be1bd7390eb46c0a520d-x86.cache-2 b70b8000-b70bb000 r--s 00000000 08:12 3399721 /var/cache/fontconfig/d62e99ef547d1d24cdb1bd22ec1a2976-x86.cache-2 b70bb000-b70da000 r--s 00000000 08:12 3399725 /var/cache/fontconfig/17090aa38d5c6f09fb8c5c354938f1d7-x86.cache-2 b70da000-b70e2000 r-xp 00000000 08:12 2695787 /lib/libnss_files-2.6.1.so b70e2000-b70e3000 r--p 00007000 08:12 2695787 /lib/libnss_files-2.6.1.so b70e3000-b70e4000 rw-p 00008000 08:12 2695787 /lib/libnss_files-2.6.1.so b70e4000-b70ec000 r-xp 00000000 08:12 2695790 /lib/libnss_nis-2.6.1.so b70ec000-b70ed000 r--p 00007000 08:12 2695790 /lib/libnss_nis-2.6.1.so b70ed000-b70ee000 rw-p 00008000 08:12 2695790 /lib/libnss_nis-2.6.1.so b70ee000-b70f4000 r-xp 00000000 08:12 2695785 /lib/libnss_compat-2.6.1.so b70f4000-b70f5000 r--p 00005000 08:12 2695785 /lib/libnss_compat-2.6.1.so b70f5000-b70f6000 rw-p 00006000 08:12 2695785 /lib/libnss_compat-2.6.1.so b70f6000-b70f9000 rw-p b70f6000 00:00 0 b70f9000-b710c000 r-xp 00000000 08:12 2695797 /lib/libpthread-2.6.1.so b710c000-b710d000 r--p 00013000 08:12 2695797 /lib/libpthread-2.6.1.so b710d000-b710e000 rw-p 00014000 08:12 2695797 /lib/libpthread-2.6.1.so b710e000-b7110000 rw-p b710e000 00:00 0 b7110000-b7117000 r-xp 00000000 08:12 2575109 /usr/lib/libkrb5support.so.0.1 b7117000-b7118000 r--p 00006000 08:12 2575109 /usr/lib/libkrb5support.so.0.1 b7118000-b7119000 rw-p 00007000 08:12 2575109 /usr/lib/libkrb5support.so.0.1 b7119000-b711e000 r-xp 00000000 08:12 2573217 /usr/lib/libXdmcp.so.6.0.0 b711e000-b711f000 r--p 00004000 08:12 2573217 /usr/lib/libXdmcp.so.6.0.0 b711f000-b7120000 rw-p 00005000 08:12 2573217 /usr/lib/libXdmcp.so.6.0.0 b7120000-b7121000 rw-p b7120000 00:00 0 b7121000-b7123000 r-xp 00000000 08:12 2573147 /usr/lib/libXau.so.6.0.0 b7123000-b7124000 r--p 00001000 08:12 2573147 /usr/lib/libXau.so.6.0.0 b7124000-b7125000 rw-p 00002000 08:12 2573147 /usr/lib/libXau.so.6.0.0 b7125000-b714b000 r-xp 00000000 08:12 2574798 /usr/lib/libk5crypto.so.3.1 b714b000-b714c000 r--p 00026000 08:12 2574798 /usr/lib/libk5crypto.so.3.1 b714c000-b714d000 rw-p 00027000 08:12 2574798 /usr/lib/libk5crypto.so.3.1 b714d000-b714f000 r-xp 00000000 08:12 8340786 /lib/libcom_err.so.2.1 b714f000-b7150000 r--p 00001000 08:12 8340786 /lib/libcom_err.so.2.1 b7150000-b7151000 rw-p 00002000 08:12 8340786 /lib/libcom_err.so.2.1 b7151000-b71de000 r-xp 00000000 08:12 25Aborted ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=974&group_id=29 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-devel] 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-devel/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-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-devel/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-devel] [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-devel/attachments/20090423/54d27f66/attachment.html From openvas-bugs at wald.intevation.org Thu Apr 23 13:21:37 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 23 Apr 2009 13:21:37 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B978=5D_False_Posit?= =?utf-8?q?ive_from_smbcl=5Fgetversion=2Enasl?= Message-ID: <20090423112137.177B140800@pyrosoma.intevation.org> Bugs item #978, was opened at 2009-04-23 11:21 Status: Open Priority: 3 Submitted By: Felix Wolfsteller (felix) Assigned to: Nobody (None) Summary: False Positive from smbcl_getversion.nasl Architecture: 32 Bit Resolution: None Severity: minor Version: v2.0.3 Component: openvas-plugins Operating System: Linux Product: OpenVAS Hardware: All URL: Initial Comment: I get following Security Note scanning a Debian Etch system: Reported by NVT "SMB Test" (1.3.6.1.4.1.25623.1.0.90011): OS Version = CONNECTION TO 192.168.xyz FAILED Domain = CONNECTION TO 192.168.xyz FAILED SMB Serverversion = CONNECTION TO 192.168.xyz FAILED (xyz blanks out a sane ip) As far as i checked, there is nothing samba-related installed on the machine. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=978&group_id=29 From geoff at galitz.org Thu Apr 23 22:38:41 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 23 Apr 2009 13:38:41 -0700 Subject: [Openvas-devel] more EN doc patches Message-ID: <10326.1240519121@sonic.net> These patches are for the Considering Coverage of Available Tests section. -geof ----------------------------------------- Geoff Galitz Blankenheim, Germany http://www.galitz.org [1] Links: ------ [1] http://www.galitz.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090423/0bfa24bf/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: coverage.diff Type: application/octet-stream Size: 2193 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090423/0bfa24bf/coverage.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangeLog.diff Type: application/octet-stream Size: 488 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090423/0bfa24bf/ChangeLog.obj From geoff at galitz.org Thu Apr 23 22:45:32 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 23 Apr 2009 22:45:32 +0200 Subject: [Openvas-devel] Discontinuing openvas-pluginstarball? In-Reply-To: <200904231116.59560.kontakt@ullrich-it.de> References: <20090423081146.GB11585@intevation.de> <200904231116.59560.kontakt@ullrich-it.de> Message-ID: My preference would be to see: - discontinue the plugin tarball - replace it with a simple feed manager/wizard - the feed manager would offer the user a choice of feeds which are registered with the OpenVAS project I envision the wizard would run automatically when no feeds are configured. I do agree, however, that having some simple default tests to make sure server and client are functioning normally is a good idea. Perhaps the server can ship with just a few very basic tests for verification purposes. --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090423/aa35d9ae/attachment.htm 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-devel] [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 jan-oliver.wagner at intevation.de Mon Apr 27 11:43:59 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 27 Apr 2009 11:43:59 +0200 Subject: [Openvas-devel] Hamonized Logging (CR #29) Message-ID: <200904271144.01757.jan-oliver.wagner@intevation.de> Hello Laban, all, CR#29 (http://www.openvas.org/openvas-cr-29.html) looks already promising. Laban: Can you prepare a sample patch (don't commit yet) how it could look like? Perhaps just logging info of the very initial startup messages. 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 labeneator at gmail.com Mon Apr 27 12:11:11 2009 From: labeneator at gmail.com (Lmwangi) Date: Mon, 27 Apr 2009 13:11:11 +0300 Subject: [Openvas-devel] Discussion: OpenVAS CR #29 Message-ID: <1e6e35b60904270311w6f3fc27eq3dbbe1186560eafe@mail.gmail.com> Hi All, I've done a bit of research on glib message logging and OpenVAS internals and have the following proposals, 1. Reuse glib's message logging functionality 2. Make configuration changes to logging by using key value pairs stored in a file 3. Make log levels be configured at runtime by changing loglevel in the config file. For example debug will show messages from all levels (info,warn....) while warning will show only messages with a severity greater than warning (critical, errors,....) 4. It is possible though harder and more confusing to the user to specify per logdomain logfiles. E.g. Nasl Debug messages to go to one file while critical and warning level messages go to another logfile 5. We need a classification scheme for currently reported errors. e.g. should we use the "error" log level (Error messages are always fatal, resulting in a call to abort() to terminate the application) because openvas might catch the error in the parent function (calling the function that throws error) 6. We also need to do away with loads of #define that were used to catch different errors e.g. #define SSL_VERBOSE and instead move that to debug calls 7. We may need to add new g_debug statements to make OpenVAS output out useful debugging messages e.g protocol dumps An example unified log group: All logs with a level >= critical are prepended with a PID and logged to stderr ["*"] prependstring="%p:" logfile="-" #Std err #logfile="/path/to/somewhere" loglevel="Critical" A more complicated scheme. Libnasl logs everything (debug+.....) to a logfile, openvasd logs info,warning,critical and error messages to another logfile while everything else greater than critical loglevel goes to another fil ["libnasl"] prependstring="%p:" logfile="/path/to/libnasl.log" loglevel="debug" ["openvasd"] prependstring="%p: %h:%m:%s " #logfile="/path/to/openvasd.log" loglevel="info" ["*"] prependstring="%p:" logfile="/path/to/error.log" loglevel="Critical" Please have a look at http://www.openvas.org/openvas-cr-29.html Regards Laban From labeneator at gmail.com Mon Apr 27 12:55:25 2009 From: labeneator at gmail.com (Lmwangi) Date: Mon, 27 Apr 2009 13:55:25 +0300 Subject: [Openvas-devel] Hamonized Logging (CR #29) In-Reply-To: <200904271144.01757.jan-oliver.wagner@intevation.de> References: <200904271144.01757.jan-oliver.wagner@intevation.de> Message-ID: <1e6e35b60904270355s20a78e28hd1c2208b1593334a@mail.gmail.com> Hi, The openvas-libnasl patches were generated by diff.. I had deleted the .svn directories during build :(. openvasd.diff sets the handler in main for glib's message logging openvas-libnasl_nasl_nasl_grammar is an example port of *printfs to glib logging functions openvas-libnasl_nasl_nasl_socket was a test to generate lots of debug messages during libnasl socket functions. At the moment I have set my logging threshold to be warnings and more severe messages. You may lower this to debug. I intend to move the threshold setting to a config file. It's a very rough cut made in the middle of the night. :) regards, Laban On Mon, Apr 27, 2009 at 12:43 PM, Jan-Oliver Wagner wrote: > Hello Laban, all, > > CR#29 (http://www.openvas.org/openvas-cr-29.html) > looks already promising. > > Laban: Can you prepare a sample patch (don't commit yet) how > it could look like? > Perhaps just logging info of the very initial startup messages. > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: openvasd.diff Type: text/x-patch Size: 5049 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090427/cb7b7611/openvasd.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-libnasl_nasl_nasl_grammar.diff Type: text/x-patch Size: 1467 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090427/cb7b7611/openvas-libnasl_nasl_nasl_grammar.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-libnasl_nasl_nasl_socket.diff Type: text/x-patch Size: 2225 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090427/cb7b7611/openvas-libnasl_nasl_nasl_socket.bin From jan-oliver.wagner at intevation.de Tue Apr 28 09:03:32 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 28 Apr 2009 09:03:32 +0200 Subject: [Openvas-devel] Hamonized Logging (CR #29) In-Reply-To: <1e6e35b60904270355s20a78e28hd1c2208b1593334a@mail.gmail.com> References: <200904271144.01757.jan-oliver.wagner@intevation.de> <1e6e35b60904270355s20a78e28hd1c2208b1593334a@mail.gmail.com> Message-ID: <200904280903.32773.jan-oliver.wagner@intevation.de> Hello Laban, thanks for the initial patch! On Monday 27 April 2009 12:55:25 Lmwangi wrote: > openvasd.diff sets the handler in main for glib's message logging > openvas-libnasl_nasl_nasl_grammar is an example port of *printfs to > glib logging functions > openvas-libnasl_nasl_nasl_socket was a test to generate lots of debug > messages during libnasl socket functions. > > At the moment I have set my logging threshold to be warnings and > more severe messages. You may lower this to debug. I intend to move > the threshold setting to a config file. I've not traced all of your changes. However, I have some comments: * we should hasve "log_domain" a configuration option in openvasd.conf rather than a compiletime option * We should us variables for g_log like "log_domain_nasl", "log_domain_otp", "log_domain_ssl", etc. In normal case all point to the same log_domain, but then it is easier to set a focus on a specific topic in the future. * we need to discuss whether to always use g_log, or whether to apply g_ctitical etc. I tend to prefer the g_log-only approach. * IIUC, the logger func can take care of PID, timestamp etc. So, actually, we can cut down many fprintf's to only the message. You haven't done so in the patch. Was that intentionally or by accident? * The openvas_logger_func needs a very precise documentation, so that it is well understood what will happen. * We should not forget that the compendium needs to be extended with a section for developers on how to use logging and which log_domains should be used. It is very good to see this progress!!! Al the best Jan -- 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 felix.wolfsteller at intevation.de Tue Apr 28 09:15:17 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Tue, 28 Apr 2009 09:15:17 +0200 Subject: [Openvas-devel] [Openvas-discuss] Web based Reporter tool In-Reply-To: <1240517487.10188.16.camel@LADY> References: <1240517487.10188.16.camel@LADY> Message-ID: <200904280915.18077.felix.wolfsteller@intevation.de> By the way, I could not find any LICENSE in the tarball (zipball), nor any information about the license on the webpage. Maybe you could clarify. The openvas page hosts a section 'related tools', mentioning autonessus only atm. I expect that during the DevCon2 in summer we will find a different organization for that section. Imho the scripts you provided should be linked from somewhere there (if the license is fine and we get permission from hackerstorm). Also some people might be interested in working with it (again, licensing...), in which case integration into the svn repository would be handy (I would think of trunk/tools/). enjoy -- felix On Thursday 23 April 2009 22:11:27 you wrote: > Hi, > > I have created a simple web based solution for presenting scans jobs. > Its all done in PHP and it reads scan jobs exported into the xml format. > > I just wanted to share it with you guys, I dont know if anyone has > anything similar or not. I created it to share nessus scans in an > intranet server for various groups. > > Anyway, please check it out, feel free to comment, its completely free, > I dont want anything at all, I just hope people find it useful, all > scripts included in download. I have'nt tested it much other than on my > systems so there may well be bugs or issues!. > > Demo here; http://www.hackerstorm.co.uk/openvas/openvas-index.php > my website and download here: http://www.hackerstorm.com > > > I'm not planning to take these scripts any further, though I am thinking > of doing something with MySQL, something a bit more powerful than static > files!. > > Has this been done already? > > Perhaps something with 'flash' DashBoards with various summaries, > historical charts, grouping scan jobs into platforms, services, > departments etc. In particular, I want to create a realtime chart for > regular scans. I perform multiple scans some 4-8 times per day and > create alerts when something is found on my private systems from > internet scans. I do this with commercial tools already but I would like > something opensource for sure. > > Would be happy for feedback on this also. Please note, I dont want to do > anything for Nessus, it will be just OpenVas if I do. > > Regards > Tim. > > > http://www.hackerstorm.com > > > > > > _______________________________________________ > Openvas-discuss mailing list > Openvas-discuss at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 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 labeneator at gmail.com Tue Apr 28 15:25:21 2009 From: labeneator at gmail.com (Laban Mwangi) Date: Tue, 28 Apr 2009 16:25:21 +0300 Subject: [Openvas-devel] Hamonized Logging (CR #29) In-Reply-To: <200904280903.32773.jan-oliver.wagner@intevation.de> References: <200904271144.01757.jan-oliver.wagner@intevation.de> <1e6e35b60904270355s20a78e28hd1c2208b1593334a@mail.gmail.com> <200904280903.32773.jan-oliver.wagner@intevation.de> Message-ID: <1240925121.4024.31.camel@hyperion.penguinlabs.co.ke> Hi Jan, I did some more work on this. Please find my comments inline On Tue, 2009-04-28 at 09:03 +0200, Jan-Oliver Wagner wrote: > * we should hasve "log_domain" a configuration option in openvasd.conf > rather than a compiletime option > * We should us variables for g_log like "log_domain_nasl", > "log_domain_otp", > "log_domain_ssl", etc. In normal case all point to the same log_domain, > but then it is easier to set a focus on a specific topic in the future. OK no problem :) We then have an openvasd logging configuration file that defines: - log domain - log prepend string - log file - log level threshold These parameters can be specified in gkeyfile groups. An example #libnasl >critical messages are logged to stderr [libnasl] prepend="%p" file="-" level="critical" #openvasd >warning messages have a pid prepended and #logged to openvasd.log [openvasd] prepend="%p" file="/var/log/openvasd.log" level="warnings" #All messages that do not match the above have the pid prepended #and are logged to openvas.log [*] prepend="%p" file="/var/log/openvas.log" What we can then do is handle the message routing within the logger_func based on the message log domain. > * we need to discuss whether to always use g_log, or whether to apply > g_ctitical etc. > I tend to prefer the g_log-only approach. Ok with me too. It allows one to set the log_domain easily. > > * IIUC, the logger func can take care of PID, timestamp etc. > So, actually, we can cut down many fprintf's to only the message. > You haven't done so in the patch. Was that intentionally or by accident? I hadn't done the actual implementation but the timestamp,pid etc can be done there. In my next patch I'll include that. > > * The openvas_logger_func needs a very precise documentation, so that > it is well understood what will happen. Ok will do... :) > > * We should not forget that the compendium needs to be extended with > a section for developers on how to use logging and which log_domains > should be used. OK will do this too > > > It is very good to see this progress!!! > > Al the best > > Jan > Thanks, -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20090428/bc1f5010/attachment.pgp From jan-oliver.wagner at intevation.de Wed Apr 29 14:11:41 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 29 Apr 2009 14:11:41 +0200 Subject: [Openvas-devel] Voting on Bug #779 with 300 Euro Message-ID: <200904291411.43773.jan-oliver.wagner@intevation.de> Hello all, bug #779 (concurrent checks problem)[1] is something I want to have resolved as soon as possible. We have invested quite some time into analysing the problem and now need to urgently care for other OpenVAS-realated things. So, in lack of time, I offer to pay 300 Euro for ultimately resolving the bug. Best Jan [1] http://bugs.openvas.com/779 -- 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 michael.wiegand at intevation.de Wed Apr 29 15:54:17 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 29 Apr 2009 15:54:17 +0200 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintext password storage Message-ID: <20090429135417.GC15363@intevation.de> Hello, while refactoring the OpenVAS user creation for the openvas-config-manager module, I noticed that the openvas-adduser script shipped with openvas-server will under certain conditions store the password of the new user as plaintext. You can read more details on this issue in the change request I've prepared: http://www.openvas.org/openvas-cr-31.html Removing this "feature" as described in the CR will take very little effort and will not break compatibility with existing installations. Since I'd like to start working on this ASAP, I'd like to call for votes regarding this CR. Please respond to this mail on openvas-devel and indicate if you are in favor of this CR (+1), don't care (+-0) or are against it (-1). 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-devel/attachments/20090429/13ba5ffc/attachment.pgp From tim at hackerstorm.com Tue Apr 28 21:57:22 2009 From: tim at hackerstorm.com (Tim Mehmet) Date: Tue, 28 Apr 2009 20:57:22 +0100 Subject: [Openvas-devel] [Openvas-discuss] Web based Reporter tool In-Reply-To: <200904280915.18077.felix.wolfsteller@intevation.de> References: <1240517487.10188.16.camel@LADY> <200904280915.18077.felix.wolfsteller@intevation.de> Message-ID: <1240948642.10869.10.camel@LADY> Hi Felix, >I could not find any LICENSE in the tarball (zipball) Yes, you are correct, I have no reason really, I need to sort it out. I am not sure which license is best in this instance, but i want to put something in to ensure people can use and develop the scripts. >I expect that during the DevCon2 in summer we will find a different organization for that section. Imho the scripts you provided should be linked from somewhere there (if the license is fine and we get permission from hackerstorm) I am happy to provide permission for this, and will do so formally once I can get a licence in place. >integration into the svn repository would be handy I agree totally, and am happy to do this. I'll get on and look into license asap, if anyone has any suggestions on what would suffice, please let me know. I must say, I am not a guru when it comes to this aspect! thanks -tim On Tue, 2009-04-28 at 09:15 +0200, Felix Wolfsteller wrote: > By the way, I could not find any LICENSE in the tarball (zipball), nor any > information about the license on the webpage. > Maybe you could clarify. > > The openvas page hosts a section 'related tools', mentioning autonessus only > atm. I expect that during the DevCon2 in summer we will find a different > organization for that section. Imho the scripts you provided should be linked > from somewhere there (if the license is fine and we get permission from > hackerstorm). > > Also some people might be interested in working with it (again, licensing...), > in which case integration into the svn repository would be handy (I would > think of trunk/tools/). > > enjoy > -- felix > > On Thursday 23 April 2009 22:11:27 you wrote: > > Hi, > > > > I have created a simple web based solution for presenting scans jobs. > > Its all done in PHP and it reads scan jobs exported into the xml format. > > > > I just wanted to share it with you guys, I dont know if anyone has > > anything similar or not. I created it to share nessus scans in an > > intranet server for various groups. > > > > Anyway, please check it out, feel free to comment, its completely free, > > I dont want anything at all, I just hope people find it useful, all > > scripts included in download. I have'nt tested it much other than on my > > systems so there may well be bugs or issues!. > > > > Demo here; http://www.hackerstorm.co.uk/openvas/openvas-index.php > > my website and download here: http://www.hackerstorm.com > > > > > > I'm not planning to take these scripts any further, though I am thinking > > of doing something with MySQL, something a bit more powerful than static > > files!. > > > > Has this been done already? > > > > Perhaps something with 'flash' DashBoards with various summaries, > > historical charts, grouping scan jobs into platforms, services, > > departments etc. In particular, I want to create a realtime chart for > > regular scans. I perform multiple scans some 4-8 times per day and > > create alerts when something is found on my private systems from > > internet scans. I do this with commercial tools already but I would like > > something opensource for sure. > > > > Would be happy for feedback on this also. Please note, I dont want to do > > anything for Nessus, it will be just OpenVas if I do. > > > > Regards > > Tim. > > > > > > http://www.hackerstorm.com > > > > > > > > > > > > _______________________________________________ > > Openvas-discuss mailing list > > Openvas-discuss at wald.intevation.org > > http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss > > From bchandra at secpod.com Thu Apr 30 06:19:25 2009 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 30 Apr 2009 09:49:25 +0530 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintextpassword storage In-Reply-To: <20090429135417.GC15363@intevation.de> References: <20090429135417.GC15363@intevation.de> Message-ID: <0CFF0F12844A4DDCA35FC7D6DA2D3F77@bchandra> +1 Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael Wiegand Sent: Wednesday, April 29, 2009 7:24 PM To: OpenVAS Development List Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintextpassword storage Hello, while refactoring the OpenVAS user creation for the openvas-config-manager module, I noticed that the openvas-adduser script shipped with openvas-server will under certain conditions store the password of the new user as plaintext. You can read more details on this issue in the change request I've prepared: http://www.openvas.org/openvas-cr-31.html Removing this "feature" as described in the CR will take very little effort and will not break compatibility with existing installations. Since I'd like to start working on this ASAP, I'd like to call for votes regarding this CR. Please respond to this mail on openvas-devel and indicate if you are in favor of this CR (+1), don't care (+-0) or are against it (-1). 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 From c_edjenguele at yahoo.it Thu Apr 30 09:02:35 2009 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Thu, 30 Apr 2009 07:02:35 +0000 (GMT) Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintextpassword storage In-Reply-To: <0CFF0F12844A4DDCA35FC7D6DA2D3F77@bchandra> References: <20090429135417.GC15363@intevation.de> <0CFF0F12844A4DDCA35FC7D6DA2D3F77@bchandra> Message-ID: <835816.36855.qm@web28610.mail.ukl.yahoo.com> +1 --- Christian Eric Edjenguele IT Security Software Developer & Researcher / Business Developer / Enterprise Software Architect mobile (IT): +39 3408580513 ----- Messaggio originale ----- > Da: Chandrashekhar B > A: Michael Wiegand ; OpenVAS Development List > Inviato: Gioved? 30 aprile 2009, 6:19:25 > Oggetto: Re: [Openvas-devel] CfV: CR #31 - Removing support for plaintextpassword storage > > +1 > > Chandra. > > -----Original Message----- > From: openvas-devel-bounces at wald.intevation.org > [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael > Wiegand > Sent: Wednesday, April 29, 2009 7:24 PM > To: OpenVAS Development List > Subject: [Openvas-devel] CfV: CR #31 - Removing support for > plaintextpassword storage > > Hello, > > while refactoring the OpenVAS user creation for the > openvas-config-manager module, I noticed that the openvas-adduser script > shipped with openvas-server will under certain conditions store the > password of the new user as plaintext. > > You can read more details on this issue in the change request I've > prepared: > http://www.openvas.org/openvas-cr-31.html > > Removing this "feature" as described in the CR will take very little > effort and will not break compatibility with existing installations. > > Since I'd like to start working on this ASAP, I'd like to call for votes > regarding this CR. Please respond to this mail on openvas-devel and > indicate if you are in favor of this CR (+1), don't care (+-0) or are > against it (-1). 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 > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From jan-oliver.wagner at intevation.de Thu Apr 30 10:16:24 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 30 Apr 2009 10:16:24 +0200 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintext password storage In-Reply-To: <20090429135417.GC15363@intevation.de> References: <20090429135417.GC15363@intevation.de> Message-ID: <200904301016.26448.jan-oliver.wagner@intevation.de> On Mittwoch, 29. April 2009, Michael Wiegand wrote: > http://www.openvas.org/openvas-cr-31.html > > Removing this "feature" as described in the CR will take very little > effort and will not break compatibility with existing installations. > > Since I'd like to start working on this ASAP, I'd like to call for votes > regarding this CR. Please respond to this mail on openvas-devel and > indicate if you are in favor of this CR (+1), don't care (+-0) or are > against it (-1). Thank you! +1 we might even consider writing a announcement that people should search for "password" files in ....users/ directory for both, OpenVAS and Nessus. 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 michael.wiegand at intevation.de Thu Apr 30 10:28:01 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 30 Apr 2009 10:28:01 +0200 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintext password storage In-Reply-To: <200904301016.26448.jan-oliver.wagner@intevation.de> References: <20090429135417.GC15363@intevation.de> <200904301016.26448.jan-oliver.wagner@intevation.de> Message-ID: <20090430082801.GB13966@intevation.de> * Jan-Oliver Wagner [30. Apr 2009]: > +1 > > we might even consider writing a announcement that people > should search for "password" files in ....users/ directory for > both, OpenVAS and Nessus. Good idea. I would be pretty easy for me to provide a script for conversion as well; since we "know" the plaintext password, we can use it to build the corresponding auth/hash file and (re)move the auth/password file. Users will still be able to use the same password and will not notice any difference. As I said in the CR, we will need a script like this sooner or later to convert existing installation once we switch off support in openvasd; we might as well write one now. I suspect the exact location of the user directory has changed over time, so I'm not sure if this will work with all older Nessus or OpenVAS versions. But if we provide a script and the server administrator knows the location of the user directory, the adjustment should be pretty straightforward and not beyond the capabilities of most administrators. 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-devel/attachments/20090430/2fbc7086/attachment-0001.pgp From mime at gmx.de Thu Apr 30 10:49:25 2009 From: mime at gmx.de (Michael Meyer) Date: Thu, 30 Apr 2009 10:49:25 +0200 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintext password storage In-Reply-To: <20090429135417.GC15363@intevation.de> References: <20090429135417.GC15363@intevation.de> Message-ID: <20090430084925.GA2960@m2.homelinux.org> *** Michael Wiegand wrote: > Since I'd like to start working on this ASAP, I'd like to call for votes > regarding this CR. Please respond to this mail on openvas-devel and > indicate if you are in favor of this CR (+1), don't care (+-0) or are > against it (-1). +1 Micha From jan-oliver.wagner at intevation.de Thu Apr 30 16:39:27 2009 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 30 Apr 2009 16:39:27 +0200 Subject: [Openvas-devel] =?iso-8859-1?q?CfV=3A_CR_=2331_-_Removing_support?= =?iso-8859-1?q?_for=09plaintext_password_storage?= In-Reply-To: <20090430082801.GB13966@intevation.de> References: <20090429135417.GC15363@intevation.de> <200904301016.26448.jan-oliver.wagner@intevation.de> <20090430082801.GB13966@intevation.de> Message-ID: <200904301639.28940.jan-oliver.wagner@intevation.de> On Donnerstag, 30. April 2009, Michael Wiegand wrote: > I would be pretty easy for me to provide a script for conversion as > well; since we "know" the plaintext password, we can use it to build the > corresponding auth/hash file and (re)move the auth/password file. the password possibly leaked and should not be re-used. -- 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 geoff at galitz.org Thu Apr 30 23:01:33 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 30 Apr 2009 23:01:33 +0200 Subject: [Openvas-devel] CfV: CR #31 - Removing support for plaintextpassword storage In-Reply-To: <20090429135417.GC15363@intevation.de> References: <20090429135417.GC15363@intevation.de> Message-ID: <8824554D5DEE461EA1791C5BD1F254D9@geoffPC> +1 --------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/