From christian.edjenguele at owasp.org Thu Oct 1 15:10:56 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Thu, 01 Oct 2009 15:10:56 +0200 Subject: [Openvas-devel] Openvas-Devel administration Message-ID: <4AC4AA60.1020704@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello List, Just since currently some ML doesn't have a co/maintainer, I would like to volunteer for openvas-devel ML administration. and if possible moderator for openvas-discuss. Best. - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKxKpaAAoJENETScWxZUSYSV4IAJd0gqqxr/QSROWDVWD+DaFE FQPPxnDn1i6/XlCnwbnlxbThrpk1qfEqzQBVKOHculSFgy5YNRRZSZvzdpewB6jq TeJMcf4+VVQF67e4XTa3dH2oeCQ5e0s4p5lYQrHJzXoGrMN6gW+e9z+5AmnVhdxX PkBccg1VJKQyX6ndlzbE4yxcUSZjlCzEwDHIOSqaGwlTo0eNi+em76tMtwn589cf 7VYRwC+Ic9pk8NzVrnLX2c9dGRfR8KMSAsSGSIXNfBhzKk81KLLTGoL682YvlCiy sv5/4ne1pd+5AQQcvTsm1CcbSYmE28r2EuozDlgwFfXN6O/lpqnaTMT16XMzImA= =25fM -----END PGP SIGNATURE----- From geoff at galitz.org Thu Oct 1 21:04:26 2009 From: geoff at galitz.org (Geoff Galitz) Date: Thu, 1 Oct 2009 21:04:26 +0200 Subject: [Openvas-devel] bug tracker maintainer volunteer Message-ID: <5BAC803943B349BEAAADCE008263BB4B@geoffPC> Good day, I'm volunteering for the bug tracker maintainer position. -geoff --------------------------------- 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/20091001/fa192d24/attachment.htm From Jan-Oliver.Wagner at greenbone.net Thu Oct 1 22:39:46 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 1 Oct 2009 22:39:46 +0200 Subject: [Openvas-devel] Openvas-Devel administration In-Reply-To: <4AC4AA60.1020704@owasp.org> References: <4AC4AA60.1020704@owasp.org> Message-ID: <200910012239.46495.Jan-Oliver.Wagner@greenbone.net> Hello Christian, On Thursday 01 October 2009 15:10:56 Christian Eric Edjenguele wrote: > Just since currently some ML doesn't have a co/maintainer, I would like > to volunteer for openvas-devel ML administration. and if possible > moderator for openvas-discuss. thanks a lot for your help! I added you as co-maintainer for both lists. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From Jan-Oliver.Wagner at greenbone.net Thu Oct 1 22:49:40 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Thu, 1 Oct 2009 22:49:40 +0200 Subject: [Openvas-devel] bug tracker maintainer volunteer In-Reply-To: <5BAC803943B349BEAAADCE008263BB4B@geoffPC> References: <5BAC803943B349BEAAADCE008263BB4B@geoffPC> Message-ID: <200910012249.40339.Jan-Oliver.Wagner@greenbone.net> Geoff, On Thursday 01 October 2009 21:04:26 Geoff Galitz wrote: > I'm volunteering for the bug tracker maintainer position. thanks a lot for caring about the bug tracker entries!! I added you as maintainer to the team list. Your GForge account should have sufficient rights now. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From felix.wolfsteller at intevation.de Fri Oct 2 09:10:56 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Fri, 2 Oct 2009 09:10:56 +0200 Subject: [Openvas-devel] bug tracker maintainer volunteer In-Reply-To: <5BAC803943B349BEAAADCE008263BB4B@geoffPC> References: <5BAC803943B349BEAAADCE008263BB4B@geoffPC> Message-ID: <200910020910.56110.felix.wolfsteller@intevation.de> Thats great, geoff. Thanks a lot. --felix On Thursday 01 October 2009 21:04:26 Geoff Galitz wrote: > Good day, > > > > I'm volunteering for the bug tracker maintainer position. > > > > -geoff > > --------------------------------- > Geoff Galitz > Blankenheim NRW, Germany > http://www.galitz.org/ > http://german-way.com/blog/ -- Felix Wolfsteller | ++49 541 335083-783 | 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 Thu Oct 1 14:39:11 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 1 Oct 2009 14:39:11 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1136=5D_Local_chec?= =?utf-8?q?k_generator_for_Solaris_incompatible_with_newer_environm?= =?utf-8?q?ents?= Message-ID: <20091001123911.5490485D9F59@pyrosoma.intevation.org> Bugs item #1136, was opened at 2009-10-01 14:39 Status: Open Priority: 3 Submitted By: Geoff Galitz (geoff) Assigned to: Nobody (None) Summary: Local check generator for Solaris incompatible with newer environments Architecture: None Resolution: Fixed Severity: None Version: v2.0 Component: openvas-plugins Operating System: None Product: OpenVAS Hardware: None URL: Initial Comment: The LSCGenerator for Solaris had trouble properly downloading patches from Sunsolve to due to changes in later versions of wget and changes to SunSolve in the last few months. Older platforms running LSCGenerator were unaffected. A patch has been committed to enable downloading the patches properly. The patch also fixes a minor issue where temporary files were vaguely named. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1136&group_id=29 From Jan-Oliver.Wagner at greenbone.net Mon Oct 5 08:36:05 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Mon, 5 Oct 2009 08:36:05 +0200 Subject: [Openvas-devel] Going to retire 1.0 (?) Message-ID: <200910050836.06548.Jan-Oliver.Wagner@greenbone.net> Hi OpenVAS developers, according to our retirement procedure http://www.openvas.org/release-life-cycle.html I would like to starte the retirement of 1.0 around Oct 15th so that the final end of life is mid of January. The pre-condition is met (2.0 available since Dec. 2008) and I volunteer to be the retirement coordinator. Are there any concerns from the developer side about the retirement of 1.0. 1.0 is part of some distributions that continue to have it as "stable". Does this cause any implications? (OpenVAS is surely not the only product that has end-of-life-dates no matching the ones if distributions). The advantage of retirering 1.0 is that we can use some 2.0 features for NASL scripts in the feed. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From lists at securityspace.com Mon Oct 5 21:59:07 2009 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 05 Oct 2009 15:59:07 -0400 Subject: [Openvas-devel] [Openvas-commits] r5349 - in trunk/openvas-plugins: . scripts In-Reply-To: <20091001165734.70DD5852AD1D@pyrosoma.intevation.org> References: <20091001165734.70DD5852AD1D@pyrosoma.intevation.org> Message-ID: <4ACA500B.1030106@securityspace.com> > trunk/openvas-plugins/scripts/ms_smb2_highid.nasl > + script_category(ACT_GATHER_INFO); > +data = raw_string(0x00,0x00,0x00,0x90,0xff,0x53,0x4d,0x42,0x72,0x00,0x00,0x00,0x00,0x18,0x53,0xc8, > + 0x00,0x26,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0xff,0xfe, > + 0x00,0x00,0x00,0x00,0x00,0x6d,0x00,0x02,0x50,0x43,0x20,0x4e,0x45,0x54,0x57,0x4f, > + 0x52,0x4b,0x20,0x50,0x52,0x4f,0x47,0x52,0x41,0x4d,0x20,0x31,0x2e,0x30,0x00,0x02, > + 0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x31,0x2e,0x30,0x00,0x02,0x57,0x69,0x6e,0x64,0x6f, > + 0x77,0x73,0x20,0x66,0x6f,0x72,0x20,0x57,0x6f,0x72,0x6b,0x67,0x72,0x6f,0x75,0x70, > + 0x73,0x20,0x33,0x2e,0x31,0x61,0x00,0x02,0x4c,0x4d,0x31,0x2e,0x32,0x58,0x30,0x30, > + 0x32,0x00,0x02,0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x32,0x2e,0x31,0x00,0x02,0x4e,0x54, > + 0x20,0x4c,0x4d,0x20,0x30,0x2e,0x31,0x32,0x00,0x02,0x53,0x4d,0x42,0x20,0x32,0x2e, > + 0x30,0x30,0x32,0x00); # Tested against 2008 Server. A vulnerable Server doing a reboot. I'm not happy with that, but a the moment i have no idea how to detect this vulnerability without exploiting it. > + I suspect this script should be classified as ACT_DENIAL rather than ACT_GATHER_INFO, given that it causes the vulnerable server to reboot. Thomas From timb at openvas.org Mon Oct 5 22:46:50 2009 From: timb at openvas.org (Tim Brown) Date: Mon, 5 Oct 2009 21:46:50 +0100 Subject: [Openvas-devel] [Openvas-commits] r5349 - in trunk/openvas-plugins: . scripts In-Reply-To: <4ACA500B.1030106@securityspace.com> References: <20091001165734.70DD5852AD1D@pyrosoma.intevation.org> <4ACA500B.1030106@securityspace.com> Message-ID: <200910052146.54243.timb@openvas.org> On Monday 05 October 2009 20:59:07 you wrote: > > trunk/openvas-plugins/scripts/ms_smb2_highid.nasl > > > > + script_category(ACT_GATHER_INFO); > > > > +data = > > raw_string(0x00,0x00,0x00,0x90,0xff,0x53,0x4d,0x42,0x72,0x00,0x00,0x00,0x > >00,0x18,0x53,0xc8, + > > 0x00,0x26,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0xf > >f,0xfe, + > > 0x00,0x00,0x00,0x00,0x00,0x6d,0x00,0x02,0x50,0x43,0x20,0x4e,0x45,0x54,0x5 > >7,0x4f, + > > 0x52,0x4b,0x20,0x50,0x52,0x4f,0x47,0x52,0x41,0x4d,0x20,0x31,0x2e,0x30,0x0 > >0,0x02, + > > 0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x31,0x2e,0x30,0x00,0x02,0x57,0x69,0x6e,0x6 > >4,0x6f, + > > 0x77,0x73,0x20,0x66,0x6f,0x72,0x20,0x57,0x6f,0x72,0x6b,0x67,0x72,0x6f,0x7 > >5,0x70, + > > 0x73,0x20,0x33,0x2e,0x31,0x61,0x00,0x02,0x4c,0x4d,0x31,0x2e,0x32,0x58,0x3 > >0,0x30, + > > 0x32,0x00,0x02,0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x32,0x2e,0x31,0x00,0x02,0x4 > >e,0x54, + > > 0x20,0x4c,0x4d,0x20,0x30,0x2e,0x31,0x32,0x00,0x02,0x53,0x4d,0x42,0x20,0x3 > >2,0x2e, + 0x30,0x30,0x32,0x00); # Tested against 2008 > > Server. A vulnerable Server doing a reboot. I'm not happy with that, but > > a the moment i have no idea how to detect this vulnerability without > > exploiting it. + > > I suspect this script should be classified as ACT_DENIAL > rather than ACT_GATHER_INFO, given that it causes the > vulnerable server to reboot. The /safe/ version of the check would be just to check for SMBv2 support and flag it as a possible issue. It's not perfect but AFAIk it is all that can be done at the moment. You might also be able to fix up the packet so that it uses values that are unlikely to trigger the crash but I haven't investigated that in any detail. Tim -- Tim Brown From timb at openvas.org Mon Oct 5 23:57:06 2009 From: timb at openvas.org (Tim Brown) Date: Mon, 5 Oct 2009 22:57:06 +0100 Subject: [Openvas-devel] [Openvas-commits] r5349 - in trunk/openvas-plugins: . scripts Message-ID: <200910052257.09290.timb@openvas.org> (moved to openvas-plugins) On Monday 05 October 2009 20:59:07 Thomas Reinke wrote: > > trunk/openvas-plugins/scripts/ms_smb2_highid.nasl > > > > + script_category(ACT_GATHER_INFO); > > > > +data = > > raw_string(0x00,0x00,0x00,0x90,0xff,0x53,0x4d,0x42,0x72,0x00,0x00,0x00,0x > >00,0x18,0x53,0xc8, + > > 0x00,0x26,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0xff,0xf > >f,0xfe, + > > 0x00,0x00,0x00,0x00,0x00,0x6d,0x00,0x02,0x50,0x43,0x20,0x4e,0x45,0x54,0x5 > >7,0x4f, + > > 0x52,0x4b,0x20,0x50,0x52,0x4f,0x47,0x52,0x41,0x4d,0x20,0x31,0x2e,0x30,0x0 > >0,0x02, + > > 0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x31,0x2e,0x30,0x00,0x02,0x57,0x69,0x6e,0x6 > >4,0x6f, + > > 0x77,0x73,0x20,0x66,0x6f,0x72,0x20,0x57,0x6f,0x72,0x6b,0x67,0x72,0x6f,0x7 > >5,0x70, + > > 0x73,0x20,0x33,0x2e,0x31,0x61,0x00,0x02,0x4c,0x4d,0x31,0x2e,0x32,0x58,0x3 > >0,0x30, + > > 0x32,0x00,0x02,0x4c,0x41,0x4e,0x4d,0x41,0x4e,0x32,0x2e,0x31,0x00,0x02,0x4 > >e,0x54, + > > 0x20,0x4c,0x4d,0x20,0x30,0x2e,0x31,0x32,0x00,0x02,0x53,0x4d,0x42,0x20,0x3 > >2,0x2e, + 0x30,0x30,0x32,0x00); # Tested against 2008 > > Server. A vulnerable Server doing a reboot. I'm not happy with that, but > > a the moment i have no idea how to detect this vulnerability without > > exploiting it. + > > I suspect this script should be classified as ACT_DENIAL > rather than ACT_GATHER_INFO, given that it causes the > vulnerable server to reboot. I agree. For the record, the /safe/ version of the check would be just to check for SMBv2 support and flag it as a possible issue. It's not perfect but AFAIK it is all that can be done at the moment. You might also be able to fix up the packet so that it uses values that are unlikely to trigger the crash but I haven't investigated that in any detail. Tim -- Tim Brown From timb at openvas.org Tue Oct 6 23:52:25 2009 From: timb at openvas.org (Tim Brown) Date: Tue, 6 Oct 2009 22:52:25 +0100 Subject: [Openvas-devel] Race condition in openvassd Message-ID: <200910062252.31302.timb@openvas.org> All, Whilst doing some janitor work on the OpenVAS code base I spotted a potential race condition. openvas-scanner/openvassd/utils.c contains a function temp_file_name() which contains a loop that recusively constructs random filenames under OPENVASSD_STATEDIR/tmp and then checks whether they exist by attempting to open them with O_RDONLY. When open returns a file descriptor >= 0, the filename is returned. This function is called from openvas-scanner/openvassd/ntp_11.c by the ntp_11_recv_file() function. This function opens the filename returned with O_CREAT|O_WRONLY|O_TRUNC and then writes to it. There exists a time of check, time of use race condition which might be exploited to overwrite arbitrary files. Thoughts before I start to clean it up? ATTACHED_FILE still seems to be supported by OTP 1.0, no? Tim -- Tim Brown From felix.wolfsteller at intevation.de Wed Oct 7 07:45:09 2009 From: felix.wolfsteller at intevation.de (Felix Wolfsteller) Date: Wed, 7 Oct 2009 07:45:09 +0200 Subject: [Openvas-devel] Race condition in openvassd In-Reply-To: <200910062252.31302.timb@openvas.org> References: <200910062252.31302.timb@openvas.org> Message-ID: <200910070745.10065.felix.wolfsteller@intevation.de> On Tuesday 06 October 2009 23:52:25 Tim Brown wrote: > Whilst doing some janitor work on the OpenVAS code base I spotted a > potential race condition. > > openvas-scanner/openvassd/utils.c contains a function temp_file_name() > which contains a loop that recusively constructs random filenames under > OPENVASSD_STATEDIR/tmp and then checks whether they exist by attempting to > open them with O_RDONLY. When open returns a file descriptor >= 0, the > filename is returned. > > This function is called from openvas-scanner/openvassd/ntp_11.c by the > ntp_11_recv_file() function. This function opens the filename returned > with O_CREAT|O_WRONLY|O_TRUNC and then writes to it. > > There exists a time of check, time of use race condition which might be > exploited to overwrite arbitrary files. > > Thoughts before I start to clean it up? I would say go ahead. > ATTACHED_FILE still seems to be supported by OTP 1.0, no? Yes, its needed for credentials assignment (comes in form of a file) and for nvts that require a "File" preference. -- felix -- Felix Wolfsteller | ++49 541 335083-783 | 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 Fri Oct 9 23:06:33 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Fri, 9 Oct 2009 23:06:33 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1148=5D_English_au?= =?utf-8?q?th_dialog_image_has_German_button_text?= Message-ID: <20091009210633.E8EE9865F4AC@pyrosoma.intevation.org> Bugs item #1148, was opened at 2009-10-09 21:06 Status: Open Priority: 1 Submitted By: Matthew Mundell (mattm) Assigned to: Nobody (None) Summary: English auth dialog image has German button text Architecture: None Resolution: None Severity: minor Version: None Component: openvas-compendium Operating System: None Product: OpenVAS Hardware: None URL: Initial Comment: The buttons on the English auth dialog image (openvas-compendium/images/authentication-dlg-en.png) have text in German. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1148&group_id=29 From Jan-Oliver.Wagner at greenbone.net Wed Oct 14 09:28:19 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Wed, 14 Oct 2009 09:28:19 +0200 Subject: [Openvas-devel] Going to retire 1.0 (?) In-Reply-To: <200910050836.06548.Jan-Oliver.Wagner@greenbone.net> References: <200910050836.06548.Jan-Oliver.Wagner@greenbone.net> Message-ID: <200910140928.20627.Jan-Oliver.Wagner@greenbone.net> Hello, On Montag, 5. Oktober 2009, Jan-Oliver Wagner wrote: > according to our retirement procedure > http://www.openvas.org/release-life-cycle.html > > I would like to starte the retirement of 1.0 around Oct 15th > so that the final end of life is mid of January. > The pre-condition is met (2.0 available since Dec. 2008) > and I volunteer to be the retirement coordinator. > > Are there any concerns from the developer side about > the retirement of 1.0. > > 1.0 is part of some distributions that continue to have it > as "stable". Does this cause any implications? > (OpenVAS is surely not the only product that has > end-of-life-dates no matching the ones if distributions). > > The advantage of retirering 1.0 is that we can use some 2.0 > features for NASL scripts in the feed. got no feedback on this, so I will start the retirement process today with the announcement on openvas-announce. Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460 Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Wed Oct 14 13:45:08 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Wed, 14 Oct 2009 13:45:08 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1153=5D_openvas-li?= =?utf-8?q?bnasl-2=2E0=2E2_Failed_configure_CentOS_5=2E3?= Message-ID: <20091014114508.15088861EACE@pyrosoma.intevation.org> Bugs item #1153, was opened at 2009-10-14 11:45 Status: Open Priority: 3 Submitted By: Raita Ode (oderaita) Assigned to: Nobody (None) Summary: openvas-libnasl-2.0.2 Failed configure CentOS 5.3 Architecture: 32 Bit Resolution: None Severity: None Version: v2.0.2 Component: openvas-libnasl Operating System: other Product: OpenVAS Hardware: Other URL: Initial Comment: When running a configure for openvas-libnasl-2.0.2 I get the following: checking for short... yes checking size of short... configure: error: cannot compute sizeof (short) See `config.log' for more details. I have included my config.log. Have I missed installing something needed? Any help in configuring this will be much appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1153&group_id=29 From openvas-bugs at wald.intevation.org Thu Oct 15 12:33:06 2009 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 15 Oct 2009 12:33:06 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1157=5D_openvas-cl?= =?utf-8?q?ient_crashes_when_connecting_to_openvas_scanning_daemon_?= =?utf-8?q?in_SVN=2Etrunk_=28r5551=29?= Message-ID: <20091015103306.6924C865F495@pyrosoma.intevation.org> Bugs item #1157, was opened at 2009-10-15 12:33 Status: Open Priority: 3 Submitted By: Vlatko Kosturjak (kost) Assigned to: Nobody (None) Summary: openvas-client crashes when connecting to openvas scanning daemon in SVN.trunk (r5551) Architecture: None Resolution: None Severity: None Version: None Component: None Operating System: None Product: None Hardware: None URL: Initial Comment: openvas-client crashes when connecting to openvas scanning daemon in SVN.trunk (r5551) It did not have any plugins. Started openvassd, and then started openvas-client. When I initiate connection from openvas-client to openvassd, openvas-client crashes with following backtrace: Starting program: /opt/openvas-svn-2009-10-15/bin/OpenVAS-Client [Thread debugging using libthread_db enabled] [New Thread 0xb6f7a700 (LWP 6769)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6f7a700 (LWP 6769)] 0x0806ed8b in prefs_dialog_apply_plugin_prefs (plugins=0x8e18c40) at prefs_dialog/prefs_dialog.c:1455 1455 while(pref && pref->next) (gdb) bt #0 0x0806ed8b in prefs_dialog_apply_plugin_prefs (plugins=0x8e18c40) at prefs_dialog/prefs_dialog.c:1455 #1 0x0808d5b1 in prefs_context_update (context=0x89904a8) at prefs_dialog/prefs_context.c:394 #2 0x0807a805 in prefs_dialog_auth_do_connect (context=0x89904a8, ctrls=0x8bcd8d8) at prefs_dialog/prefs_dialog_auth.c:257 #3 0x0807afd4 in prefs_dialog_auth_connect_dialog (context=0x89904a8, ctrls=0x8bcd8d8) at prefs_dialog/prefs_dialog_auth.c:600 #4 0xb78ab3d4 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb789dc4b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb78b4095 in ?? () from /usr/lib/libgobject-2.0.so.0 #7 0xb78b57ac in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0xb78b5acd in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #9 0xb7dc10c7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #10 0xb78ab3d4 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #11 0xb789dc4b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0xb78b4095 in ?? () from /usr/lib/libgobject-2.0.so.0 #13 0xb78b57ac in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0xb78b5c26 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0xb7c3eeaa in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 #16 0xb7c3ff58 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 ---Type to continue, or q to quit--- #17 0xb78ab3d4 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #18 0xb789c3c9 in ?? () from /usr/lib/libgobject-2.0.so.0 #19 0xb789dc4b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #20 0xb78b38ee in ?? () from /usr/lib/libgobject-2.0.so.0 #21 0xb78b57ac in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #22 0xb78b5c26 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #23 0xb7c3ef4a in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 #24 0xb7c3ef83 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7cf3036 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #26 0xb789c3c9 in ?? () from /usr/lib/libgobject-2.0.so.0 #27 0xb789dc4b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #28 0xb78b3d3d in ?? () from /usr/lib/libgobject-2.0.so.0 #29 0xb78b562b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #30 0xb78b5c26 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #31 0xb7e0833e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xb7cebb4c in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #33 0xb7cecef7 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #34 0xb7b8350a in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #35 0xb7810718 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #36 0xb7813dc3 in ?? () from /usr/lib/libglib-2.0.so.0 #37 0xb78142e2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #38 0xb7ced3a9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x0808a139 in main (argc=Cannot access memory at address 0x0 ) at openvas-client.c:1722 ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1157&group_id=29 From timb at openvas.org Sun Oct 18 01:08:03 2009 From: timb at openvas.org (Tim Brown) Date: Sun, 18 Oct 2009 00:08:03 +0100 Subject: [Openvas-devel] Race condition in openvassd In-Reply-To: <200910070745.10065.felix.wolfsteller@intevation.de> References: <200910062252.31302.timb@openvas.org> <200910070745.10065.felix.wolfsteller@intevation.de> Message-ID: <200910180008.06279.timb@openvas.org> On Wednesday 07 October 2009 06:45:09 Felix Wolfsteller wrote: > On Tuesday 06 October 2009 23:52:25 Tim Brown wrote: > > Whilst doing some janitor work on the OpenVAS code base I spotted a > > potential race condition. > > > > openvas-scanner/openvassd/utils.c contains a function temp_file_name() > > which contains a loop that recusively constructs random filenames under > > OPENVASSD_STATEDIR/tmp and then checks whether they exist by attempting > > to open them with O_RDONLY. When open returns a file descriptor >= 0, > > the filename is returned. > > > > This function is called from openvas-scanner/openvassd/ntp_11.c by the > > ntp_11_recv_file() function. This function opens the filename returned > > with O_CREAT|O_WRONLY|O_TRUNC and then writes to it. > > > > There exists a time of check, time of use race condition which might be > > exploited to overwrite arbitrary files. > > > > Thoughts before I start to clean it up? > > I would say go ahead. > > > ATTACHED_FILE still seems to be supported by OTP 1.0, no? > > Yes, its needed for credentials assignment (comes in form of a file) and > for nvts that require a "File" preference. Hmm, this is actually a lot more bothersome that I first thought....the lifetime of the files seems to be quite long. After generating the filename it writes to it and then does daft things like: files_add_translation (globals, origname, localname); Using mkstemp alone won't be enough although it did solve the time of check time of write which inititially caught my eye :(. Seems we need to cache the filename we generate, the device ID and the inode and check this on each subsequent read but it seems like a real nasty solution. Either that or hold the contents in memory and bin the whole write to disk element entirely. Suggestions? Tim -- Tim Brown From Jan-Oliver.Wagner at greenbone.net Sun Oct 18 19:40:57 2009 From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner) Date: Sun, 18 Oct 2009 19:40:57 +0200 Subject: [Openvas-devel] Race condition in openvassd In-Reply-To: <200910180008.06279.timb@openvas.org> References: <200910062252.31302.timb@openvas.org> <200910070745.10065.felix.wolfsteller@intevation.de> <200910180008.06279.timb@openvas.org> Message-ID: <200910181940.58151.Jan-Oliver.Wagner@greenbone.net> On Sunday 18 October 2009 01:08:03 Tim Brown wrote: > On Wednesday 07 October 2009 06:45:09 Felix Wolfsteller wrote: > > On Tuesday 06 October 2009 23:52:25 Tim Brown wrote: > Hmm, this is actually a lot more bothersome that I first thought....the > lifetime of the files seems to be quite long. After generating the filename > it writes to it and then does daft things like: > > files_add_translation (globals, origname, localname); > > Using mkstemp alone won't be enough although it did solve the time of check > time of write which inititially caught my eye :(. > > Seems we need to cache the filename we generate, the device ID and the inode > and check this on each subsequent read but it seems like a real nasty > solution. Either that or hold the contents in memory and bin the whole write > to disk element entirely. > > Suggestions? I think, keeping them in memory is the best approach. Thus avoiding any disk IO. Isn't it an option to have the file contents in the KB? Perhaps define a maximum length for files and a maximum number of files that can be uploaded? Best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From ckuerste at gmx.ch Tue Oct 20 11:14:02 2009 From: ckuerste at gmx.ch (Christian Kuersteiner) Date: Tue, 20 Oct 2009 16:14:02 +0700 Subject: [Openvas-devel] OpenVAS and Web App Security Message-ID: <4ADD7F5A.4080203@gmx.ch> Hi, I was talking with Jan about the plan to further integrate web application security scans into OpenVAS. I would be interested to help out there (and of course in other areas). Could you guys elaborate on this plan? I guess the goal wouldn't be a fully specialized web app security suite like WebInspect or Acunetix. On the other side some basic scans are already supported with the integration of nikto. So I am very keen to know what ideas you have in mind, where to start it and where it should lead. On another note I saw in the Devconf minutes that one step is to support virtual hosts scanning. If someone could give me some pointers to start with or maybe is already working on it? If some of this discussion should be rather in the plugins list feel free to move it there since I was unsure if the most changes would be in the code base or rather in the plugins itself. Thanks and best Regards, Christian From christian.edjenguele at owasp.org Tue Oct 20 11:23:52 2009 From: christian.edjenguele at owasp.org (Christian Eric Edjenguele) Date: Tue, 20 Oct 2009 11:23:52 +0200 Subject: [Openvas-devel] OpenVAS and Web App Security In-Reply-To: <4ADD7F5A.4080203@gmx.ch> References: <4ADD7F5A.4080203@gmx.ch> Message-ID: <4ADD81A8.6030700@owasp.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Christian, a web application scanner feature for OpenVAS is a really great idea, currently I'm working on a SQL injection tool http://opensqling.sourceforge.net/ it is Embeddable an plugins-based, this means it can also be used for XSS and other vulnerabilities. I have not released the source code yet, but I can share the engine. Regards. Christian Kuersteiner wrote: > Hi, > > I was talking with Jan about the plan to further integrate web > application security scans into OpenVAS. I would be interested to help > out there (and of course in other areas). > > Could you guys elaborate on this plan? I guess the goal wouldn't be a > fully specialized web app security suite like WebInspect or Acunetix. On > the other side some basic scans are already supported with the > integration of nikto. So I am very keen to know what ideas you have in > mind, where to start it and where it should lead. > > On another note I saw in the Devconf minutes that one step is to support > virtual hosts scanning. If someone could give me some pointers to start > with or maybe is already working on it? If some of this discussion > should be rather in the plugins list feel free to move it there since I > was unsure if the most changes would be in the code base or rather in > the plugins itself. > > Thanks and best Regards, > > Christian > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel - -- Christian Eric Edjenguele IT Security Engineer PGP KeyID: 0xB1654498 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJK3YGgAAoJENETScWxZUSYbdAH/1bJjFvqJRNDsyYen+d41IZQ O8NewvCyPmVD/TFQA4VxO4bznlVJcQrvDc3hugIybAUdDYm5zeQ6xw24UIA/oTB6 xLvKKb7QY8s4ikVf96HaqF0CLX/VchP94UQDYTa/fbhoPwxDjb6C/ztHpnATUMMh UDOoIxMJ+dDwOhaYXMtiYhwIb6c72OCikfKO/heV5f3so06ZVRGj2DWcCdD4YmI1 1ysLu4ukTPct/lzpTGwqnjyAfkEvyAzRxA1rXz6vhNTkh0j0f8Scz/m7IbceJwXf xzHayRJEbySVVf7ANdtbdWsZciZR0L9OTHQkncyb68SMRzwdoa19doK3KbjM1Sk= =UUG2 -----END PGP SIGNATURE----- From kost at linux.hr Tue Oct 20 13:23:44 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Tue, 20 Oct 2009 13:23:44 +0200 Subject: [Openvas-devel] OpenVAS and Web App Security In-Reply-To: <4ADD7F5A.4080203@gmx.ch> References: <4ADD7F5A.4080203@gmx.ch> Message-ID: <4ADD9DC0.1040004@linux.hr> Christian Kuersteiner wrote: > I was talking with Jan about the plan to further integrate web > application security scans into OpenVAS. I would be interested to help > out there (and of course in other areas). > > Could you guys elaborate on this plan? I guess the goal wouldn't be a > fully specialized web app security suite like WebInspect or Acunetix. On > the other side some basic scans are already supported with the > integration of nikto. So I am very keen to know what ideas you have in > mind, where to start it and where it should lead. We have also integrated w3af ( http://w3af.sf.net ) recently. Here's link to the NVT on OpenVAS SVN trunk: http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/scripts/remote-web-w3af.nasl?root=openvas&view=log Best regards, Kost From ckuerste at gmx.ch Wed Oct 21 05:51:28 2009 From: ckuerste at gmx.ch (Christian Kuersteiner) Date: Wed, 21 Oct 2009 10:51:28 +0700 Subject: [Openvas-devel] OpenVAS and Web App Security In-Reply-To: <4ADD9DC0.1040004@linux.hr> References: <4ADD7F5A.4080203@gmx.ch> <4ADD9DC0.1040004@linux.hr> Message-ID: <4ADE8540.60008@gmx.ch> Vlatko Kosturjak wrote: > We have also integrated w3af ( http://w3af.sf.net ) recently. > > Here's link to the NVT on OpenVAS SVN trunk: > http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/scripts/remote-web-w3af.nasl?root=openvas&view=log > > > Best regards, > > Kost > Ah, that's great. Thanks for the information. For me the question is rising in which direction we would like to go. Should we try to integrate as many external tools (like w3af, nikto) and let the user customize the parameters as much as possible? Or should we try to integrate some own scanning engine e.g. with the engine of opensqling (thanks Christian for the hint!). On one side as an auditor I like to customize as much as possible. On the other side I think admins like to use a vuln scanner as a shoot and forget tool where they tweak the parameters once in a while but otherwise don't bother too much with the fine tuning. I think a lot of great work is already done in web app scanning and there is not really a need for reinventing the wheel. The question is what and how OpenVAS should support it. Christian From michael.wiegand at intevation.de Thu Oct 22 11:45:59 2009 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Thu, 22 Oct 2009 11:45:59 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball Message-ID: <20091022094559.GA27258@intevation.de> Hello, I have created tarballs of the current OpenVAS NVT Feed for a while now and have been uploading them to the OpenVAS webserver. I'd like to announce that I will make this permanent now and will ensure a tarball is uploaded with every feed update. The tarball will be available at http://www.openvas.org/openvas-nvt-feed-current.tar.bz2 and contain the current feed content with all OpenVAS Transfer Integrity signatures and the md5sums for all NVTs. This should help users behind a strict firewall or proxy without rsync support to update their feed. This means that the openvas-nvt-sync script contained in the openvas-scanner module can now be adjusted to support synchronization via http if rsync fails. Any volunteers? If there are any questions or suggestions, feel free to reply to this mail. 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/20091022/edd947dc/attachment.pgp From kost at linux.hr Thu Oct 22 18:37:20 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 22 Oct 2009 18:37:20 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <20091022094559.GA27258@intevation.de> References: <20091022094559.GA27258@intevation.de> Message-ID: <4AE08A40.5070408@linux.hr> Michael Wiegand wrote: > Hello, > > I have created tarballs of the current OpenVAS NVT Feed for a while now > and have been uploading them to the OpenVAS webserver. I'd like to > [...] > This means that the openvas-nvt-sync script contained in the > openvas-scanner module can now be adjusted to support synchronization > via http if rsync fails. > Any volunteers? Sort of ;) Here's my version of openvas-nvt-sync script. It's complete rewrite of old script. What's new: - removed bashism - can use rsync, wget and curl (and failing back with that order) - can force each option via --rsync --wget and --curl - only check feed via --check - can set various script options through environment (like NVT_DIR) - can set proxies through http_proxy env, wget/curl will respect it - and of course, there is --help now ;) As this is frequently used and very important script, I haven't commited it to SVN, but I'm letting you to try first. If you don't find bugs on friday(tomorrow) - i'll commit it to SVN, Because script is configure ready, if you want to try it out and sync - you should do the following: NVT_DIR=/your/openvas/plugins/dir ./openvas-nvt-sync.in Also try: ./openvas-nvt-sync.in --help Let me know if you have any comments... Kost -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openvas-nvt-sync.in Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091022/d91dab46/openvas-nvt-sync.pot From d.jagdmann at dn-systems.de Thu Oct 22 20:53:17 2009 From: d.jagdmann at dn-systems.de (Dirk Jagdmann) Date: Thu, 22 Oct 2009 11:53:17 -0700 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <4AE08A40.5070408@linux.hr> References: <20091022094559.GA27258@intevation.de> <4AE08A40.5070408@linux.hr> Message-ID: <4AE0AA1D.2070503@dn-systems.de> Hello Vlatko, your new script looks good, but I don't like the concatenation of multiple program invocations with &&, because if one of them fails, nobody knows which one failed. I suggest replacing something like: mkdir -p "$NVT_DIR" \ && wget "$OVHTTPFEED" -O $TMPNVT \ && cd "$NVT_DIR" \ && tar xvjf $TMPNVT \ && rm -f $TMPVNT \ && echo "[i] Download complete" with errexit() { echo "$*" exit 1 } mkdir -p "$NVT_DIR" || errexit "could not mkdir $NVT_DIR" wget "$OVHTTPFEED" -O $TMPNVT || errexit "could not download feed with wget" cd "$NVT_DIR" || errexit "could not chdir to $NVT_DIR" tar xvjf $TMPNVT || errexit "could not untar $TMPNVT" rm -f $TMPVNT || errexit "could not remove $TMPNVT" # although a failure here would not be fatal... echo "[i] Download complete" Further I don't understand why you use eval "..." when checking the md5sums of the tarball, with a function like errexit() you can check the chdir and md5sum invocation in two steps. And as a third point, your parsing of the command line arguments to your script only works when a single argument is given. If I invoke something like "openvas-nvt-sync --check --curl" it's not going to work. What you need here is a "while" loop to check $# combined with "shift" in the loop body to parse all arguments present on the command line. -- 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 kost at linux.hr Thu Oct 22 21:54:49 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 22 Oct 2009 21:54:49 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <4AE0AA1D.2070503@dn-systems.de> References: <20091022094559.GA27258@intevation.de> <4AE08A40.5070408@linux.hr> <4AE0AA1D.2070503@dn-systems.de> Message-ID: <4AE0B889.2070709@linux.hr> Hello Dirk! Thanks on looking and reviewing the script. Dirk Jagdmann wrote: > Hello Vlatko, > your new script looks good, but I don't like the concatenation of multiple > program invocations with &&, because if one of them fails, nobody knows which > one failed. I suggest replacing something like: > > mkdir -p "$NVT_DIR" \ > && wget "$OVHTTPFEED" -O $TMPNVT \ > && cd "$NVT_DIR" \ > && tar xvjf $TMPNVT \ > && rm -f $TMPVNT \ > && echo "[i] Download complete" It's GPL. Feel free to patch it :) > Further I don't understand why you use eval "..." when checking the md5sums of > the tarball, with a function like errexit() you can check the chdir and md5sum > invocation in two steps. It's same part from the old script. There is thousands way to do it, I took the way from the old script... > And as a third point, your parsing of the command line arguments to your script > only works when a single argument is given. If I invoke something like > "openvas-nvt-sync --check --curl" it's not going to work. What you need here is I know. It's on purpose as every command option have sense (stand)alone. Because --check and --curl is invalid anyway. Keep Simple and Stupid design.... As the most of your comments are "about (not) likings", and not bugs, I won't change the script myself :) Feel free to send/submit the patch :) Kost From kost at linux.hr Thu Oct 22 22:17:38 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 22 Oct 2009 22:17:38 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <20091022194809.0DE26DF0EA@mail.ukfsn.org> References: <20091022194809.0DE26DF0EA@mail.ukfsn.org> Message-ID: <4AE0BDE2.9050402@linux.hr> Matthew Mundell wrote: >> Let me know if you have any comments... > Thanks for the work Kost. Three English typos quoted below. Thanks Matthew! > We've agreed to use spacing instead of tabs in the source code, so it might > be nice to do it in the script too. > I think VAR_NAME is more readable than VARNAME. NVT_DIR is like this > already, how about making it consistent? Fixed. New script is in the attachment. Did not know there is coding style for scripts as well. TMPDIR only left as it is standard environment variable. > I guess that if --rsync, --wget and --curl are given the script will update > the feed 3 times, once with each method. No. --rsync will be only executed (first argument). It ignores all other(s)... Feel free to send comments or better patches :) Kost -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openvas-nvt-sync.in Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091022/07facb63/openvas-nvt-sync.asc From kost at linux.hr Thu Oct 22 22:23:16 2009 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 22 Oct 2009 22:23:16 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <4AE0BDE2.9050402@linux.hr> References: <20091022194809.0DE26DF0EA@mail.ukfsn.org> <4AE0BDE2.9050402@linux.hr> Message-ID: <4AE0BF34.6010204@linux.hr> Vlatko Kosturjak wrote: > Matthew Mundell wrote: >> I guess that if --rsync, --wget and --curl are given the script will >> update >> the feed 3 times, once with each method. > No. --rsync will be only executed (first argument). It ignores all > other(s)... ...but have to add that if you call script without arguments it will go with following order: try rsync, if not try wget, if not try curl, if not give error. From my point of view, command line options are only for debugging or calling specific synchronization options in specific enviroments. Kost From matthew.mundell at intevation.de Thu Oct 22 22:20:01 2009 From: matthew.mundell at intevation.de (Matthew Mundell) Date: 22 Oct 2009 20:19:01 -0001 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: Message of Thu, 22 Oct 2009 22:17:38 +0200. <4AE0BDE2.9050402@linux.hr> Message-ID: <20091022202414.2C17CDF127@mail.ukfsn.org> > Fixed. New script is in the attachment. Did not know there is coding > style for scripts as well. TMPDIR only left as it is standard > environment variable. Thanks. I think the coding standard is intended for the C code. From jfs at computer.org Fri Oct 23 10:42:01 2009 From: jfs at computer.org (Javier Fernandez-Sanguino) Date: Fri, 23 Oct 2009 10:42:01 +0200 Subject: [Openvas-devel] OpenVAS NVT Feed as Tarball In-Reply-To: <4AE0BDE2.9050402@linux.hr> References: <20091022194809.0DE26DF0EA@mail.ukfsn.org> <4AE0BDE2.9050402@linux.hr> Message-ID: 2009/10/22 Vlatko Kosturjak : > Fixed. New script is in the attachment. Did not know there is coding style > for scripts as well. TMPDIR only left as it is standard environment > variable. If I might be of help: instead of using TMPDIR (which is not commonly defined in Linux environments) it should use tempfile instead if availaable. As there is only one file being downloaded it would be best if you replaced TMP_NVT="$SYNC_TMP_DIR/openvas-feed-`date +%F`-$$.tar.bz2" With this (untested, but should work): ---------------------------------------------------------------------------------------------------------------------------------------------------- CURDATE=-`date +%F` # Try to find tempfile, if available, then use it for the download file if [ -n "`which tempfile`" ] ; then TMP_NVT=`tempfile --suffix=-openvas-feed-$CURDATE.tar.bz2` || { echo "Cannot create temporary file for download!" >&2; exit 1 ;} else TMP_NVT="$SYNC_TMP_DIR/openvas-feed-$CURDATE-$$.tar.bz2" fi # Set up a trap so that the file is removed if there are any errors trap "rm -f -- '$TMP_NVT" EXIT ---------------------------------------------------------------------------------------------------------------------------------------------------- Best regards Javier