From kost at linux.hr Mon Sep 1 00:52:15 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 01 Sep 2008 00:52:15 +0200 Subject: [Openvas-devel] Few ideas for development/contest In-Reply-To: <200808291215.54327.jan-oliver.wagner@intevation.de> References: <48B71F6D.4070007@linux.hr> <48B7A200.4000103@linux.hr> <200808291215.54327.jan-oliver.wagner@intevation.de> Message-ID: <48BB209F.5060100@linux.hr> >> ...or to write another msfwrapper (msfopenvas). Another thing which must >> be added to support metasploit is xref's in plugins to relevant plugin >> in metasploit. > hm, this would turn OpenVAS into a cracker tool. > We have to be careful with this. OpenVAS should > stay a analysis tool. Though it might make sense to > use metasploit in some ways to report security problems > rather to pop up a root shell. I did little research on this topic because it would be good to integrate them, but I didn't get any idea regarding metasploit integration except this one (which is obviously unnacceptable). Because metasploit is exploitation framework, I didn't see too much vuln checks ... Kost From kost at linux.hr Mon Sep 1 00:54:21 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 01 Sep 2008 00:54:21 +0200 Subject: [Openvas-devel] Few ideas for development/contest In-Reply-To: <200808291212.46525.jan-oliver.wagner@intevation.de> References: <48B71F6D.4070007@linux.hr> <48B7A200.4000103@linux.hr> <200808291212.46525.jan-oliver.wagner@intevation.de> Message-ID: <48BB211D.8030402@linux.hr> > Let the proprietary folks do proprietary stuff and leave > their customers unclear about what the tools are doing > with root grants and unclear about source code quality. > We do better. Agree. Anyway, it would be pain to implement as NBIN is not open format. Better to focus energy on something else.... Kost From kost at linux.hr Mon Sep 1 09:37:12 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 01 Sep 2008 09:37:12 +0200 Subject: [Openvas-devel] OpenVAS plugins standardization Message-ID: <48BB9BA8.1020705@linux.hr> > IMHO information like that a tool was not found to execute > should *always* be reported. Because the has requested to execute > the respective NVT, he *must* be informed what is the result > of the execution. I really hate the way Nessus handles it: don't report > anything if nothing is found. I am confident that many many people > are scanning networks and think all is OK allthough the > server side logs nessusd would show that many plugins > failed to execute. That means if you have e.g. 25000 plugins selected and each of them should report it's status(failed/success) and why it failed? That would be report of at least 12500 pages! > I guess the daemon will just through an error in the log file as long > as the new NASL methods are not implemented. > Once the server is extended, we can report it to the client > and once this one has extended the information will be available to the > user. > Hm, as I think about it, we can also simply introduce a better > and consistent naming. How about > report_hole() (perhaps better report_vulnerability) > report_warning() > report_note() > report_debug() > report_log() > The old functions can stay for backward compatibility for a while. > Just sketched my ideas. What do you think? Sounds good. But when we're discussing this report verbosity option. It's important to note and discuss Report paranoia option also as it is tightly connected and should be discussed together (because to clearly differ those two options). Kost From jan-oliver.wagner at intevation.de Mon Sep 1 14:09:40 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 1 Sep 2008 14:09:40 +0200 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <48BB9BA8.1020705@linux.hr> References: <48BB9BA8.1020705@linux.hr> Message-ID: <200809011409.42398.jan-oliver.wagner@intevation.de> On Montag, 1. September 2008, Vlatko Kosturjak wrote: > > IMHO information like that a tool was not found to execute > > should *always* be reported. Because the has requested to execute > > the respective NVT, he *must* be informed what is the result > > of the execution. I really hate the way Nessus handles it: don't report > > anything if nothing is found. I am confident that many many people > > are scanning networks and think all is OK allthough the > > server side logs nessusd would show that many plugins > > failed to execute. > > That means if you have e.g. 25000 plugins selected and each of them > should report it's status(failed/success) and why it failed? > That would be report of at least 12500 pages! well, the printed report should not necessarily contain all of this. Even the GUI client should allow it configurable whether to manage these information. > > I guess the daemon will just through an error in the log file as long > > as the new NASL methods are not implemented. > > Once the server is extended, we can report it to the client > > and once this one has extended the information will be available to the > > user. > > Hm, as I think about it, we can also simply introduce a better > > and consistent naming. How about > > report_hole() (perhaps better report_vulnerability) > > report_warning() > > report_note() > > report_debug() > > report_log() > > The old functions can stay for backward compatibility for a while. > > Just sketched my ideas. What do you think? > > Sounds good. But when we're discussing this report verbosity option. > It's important to note and discuss Report paranoia option also as it is > tightly connected and should be discussed together (because to clearly > differ those two options). yes, indeed. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kost at linux.hr Mon Sep 1 14:14:38 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 01 Sep 2008 14:14:38 +0200 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <200809011409.42398.jan-oliver.wagner@intevation.de> References: <48BB9BA8.1020705@linux.hr> <200809011409.42398.jan-oliver.wagner@intevation.de> Message-ID: <48BBDCAE.1010702@linux.hr> >> That means if you have e.g. 25000 plugins selected and each of them >> should report it's status(failed/success) and why it failed? >> That would be report of at least 12500 pages! > well, the printed report should not necessarily contain all of this. > Even the GUI client should allow it configurable whether > to manage these information. I would expect such report output if report_debug option is selected or if some specific complaince check list scan needed. Kost From bchandra at secpod.com Mon Sep 1 14:25:31 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 1 Sep 2008 17:55:31 +0530 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <200809011409.42398.jan-oliver.wagner@intevation.de> References: <48BB9BA8.1020705@linux.hr> <200809011409.42398.jan-oliver.wagner@intevation.de> Message-ID: <00b701c90c2d$d6988070$0201a8c0@mahesh> -----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: Monday, September 01, 2008 5:40 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] OpenVAS plugins standardization On Montag, 1. September 2008, Vlatko Kosturjak wrote: > > IMHO information like that a tool was not found to execute > > should *always* be reported. Because the has requested to execute > > the respective NVT, he *must* be informed what is the result > > of the execution. I really hate the way Nessus handles it: don't report > > anything if nothing is found. I am confident that many many people > > are scanning networks and think all is OK allthough the > > server side logs nessusd would show that many plugins > > failed to execute. > > That means if you have e.g. 25000 plugins selected and each of them > should report it's status(failed/success) and why it failed? > That would be report of at least 12500 pages! > well, the printed report should not necessarily contain all of this. > Even the GUI client should allow it configurable whether > to manage these information. By looking at logs and the KB items store, we can make out why a plugin isn't launched. In any case, it would be better if there's a single location where we can look through to identify failed instances. Instead of clogging the reports, can we redirect these to a log and debug file? > > I guess the daemon will just through an error in the log file as long > > as the new NASL methods are not implemented. > > Once the server is extended, we can report it to the client > > and once this one has extended the information will be available to the > > user. > > Hm, as I think about it, we can also simply introduce a better > > and consistent naming. How about > > report_hole() (perhaps better report_vulnerability) > > report_warning() > > report_note() > > report_debug() > > report_log() > > The old functions can stay for backward compatibility for a while. > > Just sketched my ideas. What do you think? > > > Sounds good. But when we're discussing this report verbosity option. > > It's important to note and discuss Report paranoia option also as it is > > tightly connected and should be discussed together (because to clearly > > differ those two options). > yes, indeed. In NASL 'debug' global variable is already there which can be used for this purpose. So, it can be like if debug == 1 report_log() # directed to a log file of failed instances if debug == 2 report_debug() # directed to a debug file And report_paranoia is used when we are unsure of what we are saying in the plugin :) Regards, Chandra. From jan-oliver.wagner at intevation.de Mon Sep 1 15:45:02 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 1 Sep 2008 15:45:02 +0200 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <00b701c90c2d$d6988070$0201a8c0@mahesh> References: <48BB9BA8.1020705@linux.hr> <200809011409.42398.jan-oliver.wagner@intevation.de> <00b701c90c2d$d6988070$0201a8c0@mahesh> Message-ID: <200809011545.04513.jan-oliver.wagner@intevation.de> On Montag, 1. September 2008, Chandrashekhar B wrote: > > well, the printed report should not necessarily contain all of this. > > Even the GUI client should allow it configurable whether > > to manage these information. > > By looking at logs and the KB items store, we can make out why a plugin > isn't launched. In any case, it would be better if there's a single location > where we can look through to identify failed instances. Instead of clogging > the reports, can we redirect these to a log and debug file? a major concern of mine is that with the current concept you have the OpenVAS-Client running and right next to it a root shell to the openvas-server installation. OK, you can configure things for non-root, but after all it is a bit strange to always accompany the GUI client with a shell ... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Mon Sep 1 16:02:21 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 1 Sep 2008 16:02:21 +0200 Subject: [Openvas-devel] OpenVAS Server/Client 1.1: strictly and only OID and OTP 1.0 ?! In-Reply-To: <200808291602.14732.jan-oliver.wagner@intevation.de> References: <200808291602.14732.jan-oliver.wagner@intevation.de> Message-ID: <200809011602.23617.jan-oliver.wagner@intevation.de> Hi, On Freitag, 29. August 2008, Jan-Oliver Wagner wrote: > To summarize, the big step would be: > * thin out OTP 1.0 > * reduce protocol implementations in openvas-server trunk to only support OTP 1.0. > * strictly use OIDs in openvas-server trunk (there is a legacy method for NASL scripts with old IDs) > * reduce protocol implementation in openvas-client trunk to only support OTP 1.0 > (openvas-client 1.0.x is maintained for NTP support) > * strictly use OIDs in openvas-client trunk. > > Any concerns with doing this big step _now_? > Alternatives? none came in so far :-) So, I will start as proposed. For a while it will be quite easy to roll-back commits in case another strategy is prefered. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kost at linux.hr Mon Sep 1 16:11:24 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 01 Sep 2008 16:11:24 +0200 Subject: [Openvas-devel] OpenVAS Server/Client 1.1: strictly and only OID and OTP 1.0 ?! In-Reply-To: <200809011602.23617.jan-oliver.wagner@intevation.de> References: <200808291602.14732.jan-oliver.wagner@intevation.de> <200809011602.23617.jan-oliver.wagner@intevation.de> Message-ID: <48BBF80C.5010208@linux.hr> >> Any concerns with doing this big step _now_? >> Alternatives? > none came in so far :-) > > So, I will start as proposed. > For a while it will be quite easy to roll-back commits in case > another strategy is prefered. As long as you have branched/tagged stable version of OpenVAS, but currently I see only openvas-client and openvas-server branch. You won't modify anything else? even not openvas-libraries? Kost From bchandra at secpod.com Mon Sep 1 16:13:59 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Mon, 1 Sep 2008 19:43:59 +0530 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <200809011545.04513.jan-oliver.wagner@intevation.de> References: <48BB9BA8.1020705@linux.hr><200809011409.42398.jan-oliver.wagner@intevation.de><00b701c90c2d$d6988070$0201a8c0@mahesh> <200809011545.04513.jan-oliver.wagner@intevation.de> Message-ID: <00b801c90c3c$fd2c26b0$0201a8c0@mahesh> -----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: Monday, September 01, 2008 7:15 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] OpenVAS plugins standardization On Montag, 1. September 2008, Chandrashekhar B wrote: > > well, the printed report should not necessarily contain all of this. > > Even the GUI client should allow it configurable whether > > to manage these information. > > By looking at logs and the KB items store, we can make out why a plugin > isn't launched. In any case, it would be better if there's a single location > where we can look through to identify failed instances. Instead of clogging > the reports, can we redirect these to a log and debug file? > a major concern of mine is that with the current concept you > have the OpenVAS-Client running and right next to it a root > shell to the openvas-server installation. > OK, you can configure things for non-root, but after all it is a bit > strange to always accompany the GUI client with a shell ... My concern is about not being able to separate data that reports vulnerabilities against data that is aiding us to analyze. Reports can become huge with number of notes such as, Application not installed, service not installed, port not open... If there's an option to separate, it is good. Regards, Chandra. From jan-oliver.wagner at intevation.de Mon Sep 1 16:37:08 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 1 Sep 2008 16:37:08 +0200 Subject: [Openvas-devel] OpenVAS Server/Client 1.1: strictly and only OID and OTP 1.0 ?! In-Reply-To: <48BBF80C.5010208@linux.hr> References: <200808291602.14732.jan-oliver.wagner@intevation.de> <200809011602.23617.jan-oliver.wagner@intevation.de> <48BBF80C.5010208@linux.hr> Message-ID: <200809011637.13813.jan-oliver.wagner@intevation.de> On Montag, 1. September 2008, Vlatko Kosturjak wrote: > >> Any concerns with doing this big step _now_? > >> Alternatives? > > none came in so far :-) > > > > So, I will start as proposed. > > For a while it will be quite easy to roll-back commits in case > > another strategy is prefered. > > As long as you have branched/tagged stable version of OpenVAS, > but currently I see only openvas-client and openvas-server branch. > You won't modify anything else? even not openvas-libraries? yes, only openvas-server and openvas-client are branched for stable development so far. As soon as it turns out necessary, I plan to branch the other modules as well. It will be only necessary upon compatibility breaking or risk of instability. Didn't saw a reason to do this earlier than necessary ... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Mon Sep 1 16:40:28 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 1 Sep 2008 16:40:28 +0200 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <00b801c90c3c$fd2c26b0$0201a8c0@mahesh> References: <48BB9BA8.1020705@linux.hr> <200809011545.04513.jan-oliver.wagner@intevation.de> <00b801c90c3c$fd2c26b0$0201a8c0@mahesh> Message-ID: <200809011640.30729.jan-oliver.wagner@intevation.de> On Montag, 1. September 2008, Chandrashekhar B wrote: > -----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: Monday, September 01, 2008 7:15 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] OpenVAS plugins standardization > > On Montag, 1. September 2008, Chandrashekhar B wrote: > > > well, the printed report should not necessarily contain all of this. > > > Even the GUI client should allow it configurable whether > > > to manage these information. > > > > By looking at logs and the KB items store, we can make out why a plugin > > isn't launched. In any case, it would be better if there's a single > location > > where we can look through to identify failed instances. Instead of > clogging > > the reports, can we redirect these to a log and debug file? > > > a major concern of mine is that with the current concept you > > have the OpenVAS-Client running and right next to it a root > > shell to the openvas-server installation. > > OK, you can configure things for non-root, but after all it is a bit > > strange to always accompany the GUI client with a shell ... > > My concern is about not being able to separate data that reports > vulnerabilities against data that is aiding us to analyze. Reports can > become huge with number of notes such as, > > Application not installed, service not installed, port not open... very true. > If there's an option to separate, it is good. we have to find a way to allow for both needs. Some configure options to switch on/off verbosity is the way to go, I guess. I am open regarding the default config ;-) Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From c_edjenguele at yahoo.it Mon Sep 1 19:37:43 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Mon, 1 Sep 2008 17:37:43 +0000 (GMT) Subject: [Openvas-devel] Plugins development Message-ID: <161802.88731.qm@web26008.mail.ukl.yahoo.com> Hi all, so, i made a HTTP GET REQUEST,?does openvas has a function to?lookup for specific string in the header ? for example if the response look like this: date: 12/30/2008 server: apache 2.25 (Win32) can I get the header 'server' and lookup for the string Win32 ? or they are not function that do that, and I've to use alternate method (regular expressions)? ?=== Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com --- Management, Developers, Security Professionals ? can only result in one thing?? better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From lists at securityspace.com Mon Sep 1 23:05:26 2008 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 01 Sep 2008 17:05:26 -0400 Subject: [Openvas-devel] Plugins development In-Reply-To: <161802.88731.qm@web26008.mail.ukl.yahoo.com> References: <161802.88731.qm@web26008.mail.ukl.yahoo.com> Message-ID: <48BC5916.7030401@securityspace.com> There is a wealth of information on how to do this by looking at the nasl scripts already in svn. An example (one of many), can be found by looking at apache_input_header_folding_dos.nasl. The only thing I don't like in this script is the egrep pattern to verify a version number. I have seen numerous times when regexs fail after a version number bumps from 9 to 10, causing false positive vulnerability reports. There are available libs that do that comparison more easily and accurately (e.g. see revcomp(a,b) in revisions-lib.inc). Thomas Christian Eric EDJENGUELE wrote: > Hi all, > so, i made a HTTP GET REQUEST, does openvas has a function to lookup for specific string in the header ? > > for example if the response look like this: > > date: 12/30/2008 > server: apache 2.25 (Win32) > > can I get the header 'server' and lookup for the string Win32 ? or they are not function that do that, and I've to use alternate method (regular expressions)? > === > Christian Eric Edjenguele > IT Security Software Developer & Researcher > tel. +39 3408580513 > View my linkedin profile: http://www.linkedin.com/in/edjenguele > My blog: http://www.edjenguele.blogspot.com > --- > Management, Developers, Security Professionals ? can only result in one thing?? better security. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 > > __________________________________________________ > Do You Yahoo!? > Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi > http://mail.yahoo.it > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From c_edjenguele at yahoo.it Tue Sep 2 13:14:39 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Tue, 2 Sep 2008 11:14:39 +0000 (GMT) Subject: [Openvas-devel] Plugins development Message-ID: <205391.23456.qm@web26003.mail.ukl.yahoo.com> hm,?I see, so finally I've to use a regular expression to do that... I think that integrating?the python interpreter (cpython) should very interesting, python is open and they are a lot of standard modules for security?and network manipulation. what do you think ? ?=== Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com --- Management, Developers, Security Professionals ? can only result in one thing?? better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 ----- Messaggio originale ----- Da: Thomas Reinke Cc: openvas-devel Inviato: Luned? 1 settembre 2008, 23:05:26 Oggetto: Re: [Openvas-devel] Plugins development There is a wealth of information on how to do this by looking at the nasl scripts already in svn.? An example (one of many), can be found by looking at apache_input_header_folding_dos.nasl. The only thing I don't like in this script is the egrep pattern to verify a version number. I have seen numerous times when regexs fail after a version number bumps from 9 to 10, causing false positive vulnerability reports.? There are available libs that do that comparison more easily and accurately (e.g. see revcomp(a,b) in revisions-lib.inc). Thomas Christian Eric EDJENGUELE wrote: > Hi all, > so, i made a HTTP GET REQUEST, does openvas has a function to lookup for specific string in the header ? > > for example if the response look like this: > > date: 12/30/2008 > server: apache 2.25 (Win32) > > can I get the header 'server' and lookup for the string Win32 ? or they are not function that do that, and I've to use alternate method (regular expressions)? >? === > Christian Eric Edjenguele > IT Security Software Developer & Researcher > tel. +39 3408580513 > View my linkedin profile: http://www.linkedin.com/in/edjenguele > My blog: http://www.edjenguele.blogspot.com > --- > Management, Developers, Security Professionals ? can only result in one thing?? better security. > http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 > > __________________________________________________ > Do You Yahoo!? > Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi > http://mail.yahoo.it > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From bchandra at secpod.com Tue Sep 2 13:32:22 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Tue, 2 Sep 2008 17:02:22 +0530 Subject: [Openvas-devel] OpenVAS plugins standardization In-Reply-To: <200809011640.30729.jan-oliver.wagner@intevation.de> References: <48BB9BA8.1020705@linux.hr><200809011545.04513.jan-oliver.wagner@intevation.de><00b801c90c3c$fd2c26b0$0201a8c0@mahesh> <200809011640.30729.jan-oliver.wagner@intevation.de> Message-ID: <003d01c90cef$944a8ac0$0301a8c0@mahesh> -----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: Monday, September 01, 2008 8:10 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] OpenVAS plugins standardization On Montag, 1. September 2008, Chandrashekhar B wrote: > -----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: Monday, September 01, 2008 7:15 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel] OpenVAS plugins standardization > > On Montag, 1. September 2008, Chandrashekhar B wrote: > > > well, the printed report should not necessarily contain all of this. > > > Even the GUI client should allow it configurable whether > > > to manage these information. > > > > By looking at logs and the KB items store, we can make out why a plugin > > isn't launched. In any case, it would be better if there's a single > location > > where we can look through to identify failed instances. Instead of > clogging > > the reports, can we redirect these to a log and debug file? > > > a major concern of mine is that with the current concept you > > have the OpenVAS-Client running and right next to it a root > > shell to the openvas-server installation. > > OK, you can configure things for non-root, but after all it is a bit > > strange to always accompany the GUI client with a shell ... > > > My concern is about not being able to separate data that reports > > vulnerabilities against data that is aiding us to analyze. Reports can > > become huge with number of notes such as, > > > > Application not installed, service not installed, port not open... > very true. >> If there's an option to separate, it is good. > we have to find a way to allow for both needs. > Some configure options to switch on/off verbosity is > the way to go, I guess. I am open regarding the default config ;-) Separation with on/off verbosity should work. Chandra. From timb at nth-dimension.org.uk Tue Sep 2 14:01:08 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Tue, 2 Sep 2008 13:01:08 +0100 Subject: [Openvas-devel] Plugins development (moved to -plugins, please do not cc -devel in further responses) In-Reply-To: <161802.88731.qm@web26008.mail.ukl.yahoo.com> References: <161802.88731.qm@web26008.mail.ukl.yahoo.com> Message-ID: <200809021301.08754.timb@nth-dimension.org.uk> On Monday 01 September 2008 18:37:43 Christian Eric EDJENGUELE wrote: > so, i made a HTTP GET REQUEST,?does openvas has a function to?lookup for > specific string in the header ? > > for example if the response look like this: > > date: 12/30/2008 > server: apache 2.25 (Win32) > > can I get the header 'server' and lookup for the string Win32 ? or they are > not function that do that, and I've to use alternate method (regular Yes, there are several ways to do this. Either the >< operator or stridx can be used for this purpose. For example: if (response >< Win32) { ... } or: if (stridx(response, "Win32)) >= 0) { ... } Cheers, Tim -- Tim Brown From c_edjenguele at yahoo.it Tue Sep 2 14:25:33 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Tue, 2 Sep 2008 12:25:33 +0000 (GMT) Subject: [Openvas-devel] Plugins development (moved to -plugins, please do not cc -devel in further responses) Message-ID: <570889.38196.qm@web26001.mail.ukl.yahoo.com> yes, I have made exactly in that way. ?=== Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com --- Management, Developers, Security Professionals ? can only result in one thing?? better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 ----- Messaggio originale ----- Da: Tim Brown A: openvas-plugins at wald.intevation.org Cc: Christian Eric EDJENGUELE ; openvas-devel at wald.intevation.org Inviato: Marted? 2 settembre 2008, 14:01:08 Oggetto: Re: [Openvas-devel] Plugins development (moved to -plugins, please do not cc -devel in further responses) On Monday 01 September 2008 18:37:43 Christian Eric EDJENGUELE wrote: > so, i made a HTTP GET REQUEST,?does openvas has a function to?lookup for > specific string in the header ? > > for example if the response look like this: > > date: 12/30/2008 > server: apache 2.25 (Win32) > > can I get the header 'server' and lookup for the string Win32 ? or they are > not function that do that, and I've to use alternate method (regular Yes, there are several ways to do this.? Either the >< operator or stridx can be used for this purpose.? For example: if (response >< Win32) { ??? ... } or: if (stridx(response, "Win32)) >= 0) { ??? ... } Cheers, Tim -- Tim Brown __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From jan-oliver.wagner at intevation.de Tue Sep 2 14:26:01 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 2 Sep 2008 14:26:01 +0200 Subject: [Openvas-devel] Plugins development In-Reply-To: <205391.23456.qm@web26003.mail.ukl.yahoo.com> References: <205391.23456.qm@web26003.mail.ukl.yahoo.com> Message-ID: <200809021426.03773.jan-oliver.wagner@intevation.de> Christian, On Dienstag, 2. September 2008, Christian Eric EDJENGUELE wrote: > hm,?I see, so finally I've to use a regular expression to do that... > I think that integrating?the python interpreter (cpython) should very interesting, > python is open and they are a lot of standard modules for security?and network manipulation. > what do you think ? this has indeed been discussed in the beginnings of OpenVAS. It is still a valid idea. However, to get the ball rolling we started based on what we have readily available. Next OpenVAS DevCon I'd like to pick this story up again. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From c_edjenguele at yahoo.it Tue Sep 2 14:32:04 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Tue, 2 Sep 2008 12:32:04 +0000 (GMT) Subject: [Openvas-devel] Plugins development Message-ID: <738122.79347.qm@web26005.mail.ukl.yahoo.com> Great!, all the security test that I've made were written in python. ?=== Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com --- Management, Developers, Security Professionals ? can only result in one thing?? better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 ----- Messaggio originale ----- Da: Jan-Oliver Wagner A: openvas-devel at wald.intevation.org Inviato: Marted? 2 settembre 2008, 14:26:01 Oggetto: Re: [Openvas-devel] Plugins development Christian, On Dienstag, 2. September 2008, Christian Eric EDJENGUELE wrote: > hm,?I see, so finally I've to use a regular expression to do that... > I think that integrating?the python interpreter (cpython) should very interesting, > python is open and they are a lot of standard modules for security?and network manipulation. > what do you think ? this has indeed been discussed in the beginnings of OpenVAS. It is still a valid idea. However, to get the ball rolling we started based on what we have readily available. Next OpenVAS DevCon I'd like to pick this story up again. Best ??? Jan -- Dr. Jan-Oliver Wagner? ? ? ? ? ? ? ? ? ? ? ? Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998? ? ? ? ? ? http://www.intevation.de/ 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 __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From c_edjenguele at yahoo.it Thu Sep 4 16:34:58 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Thu, 4 Sep 2008 14:34:58 +0000 (GMT) Subject: [Openvas-devel] HTTPS Request ! Message-ID: <841472.3927.qm@web26007.mail.ukl.yahoo.com> Hello all, how can I perform an HTTP GET Request over ssl with nasl api ? is there something like httplib.HTTPSConnection from httplib of python standard libraries ? if yes: what's the syntax ? thanks. ?=== Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com --- Management, Developers, Security Professionals ? can only result in one thing?? better security. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From kost at linux.hr Thu Sep 4 17:12:45 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Thu, 04 Sep 2008 17:12:45 +0200 Subject: [Openvas-devel] HTTPS Request ! In-Reply-To: <841472.3927.qm@web26007.mail.ukl.yahoo.com> References: <841472.3927.qm@web26007.mail.ukl.yahoo.com> Message-ID: <48BFFAED.2010203@linux.hr> Christian Eric EDJENGUELE wrote: > Hello all, > how can I perform an HTTP GET Request over ssl with nasl api ? > is there something like httplib.HTTPSConnection from httplib of python standard libraries ? > if yes: what's the syntax ? I've just cross referenced this question to openvas-plugins, so please reply to this thread to openvas-plugins mailing list as it is plugins related. Here's the simplest example, but first grab the file openvas-https.inc via SVN (it's new!) or via this URL: http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/scripts/openvas-https.inc?rev=1280&root=openvas&view=auto This is the example: include("http_func.inc"); include("http_keepalive.inc"); include("openvas-https.inc"); port = 3994; if(get_port_state(port)) { req = http_get(item:"/deploymentmanager/index.jsp", port:port); rep = https_req_get(request:req, port:port); if( rep == NULL ) exit(0); if ("SiteProtector" >< rep && egrep(pattern:"Welcome to SiteProtector Deployment Manager", string:rep)) { security_note(port); } } Note that is basic example. Well written script should do (instead of just defining port): https = get_kb_list("Services/https"); and then: foreach port (https) and then in foreach loop execute the script above. (Because there might be web servers listening on different port than default). This is also case for using plain http: http = get_kb_list("Services/www"); and then: foreach port (http) and then in foreach loop execute the script. Kost From jan-oliver.wagner at intevation.de Fri Sep 5 16:48:13 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 5 Sep 2008 16:48:13 +0200 Subject: [Openvas-devel] License clarification: webserver_favicon.nasl In-Reply-To: <48B3A82B.5090605@suse.cz> References: <48B3A82B.5090605@suse.cz> Message-ID: <200809051648.15914.jan-oliver.wagner@intevation.de> Javier, since this affects a script authored by you. On Dienstag, 26. August 2008, Ales Nosek wrote: > There is a statement in openvas-plugins-1.0.2/scripts/webserver_favicon.nasl: > > "Licensed under the GPL as available at http://www.gnu.org/licenses/gpl.html" > > This is ambiguous, as this website is changed with every update of the GPL. > Thus, if the script comes from <= June 2007, the author would have licensed it > under the GPLv2. After June 2007, it would be the GPLv3. > > Please, could you change that statement to something like "Licensed under the GPL v3 or later"? > > It would help to clarify the licensing situation considerably. "Licensed under V2 or later" would be more adequate. V3+ is too high for license compatibility I guess. Or it is plain v2, then this link should apply: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jfs at computer.org Sun Sep 7 02:12:42 2008 From: jfs at computer.org (Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?=) Date: Sun, 7 Sep 2008 02:12:42 +0200 Subject: [Openvas-devel] License clarification: webserver_favicon.nasl In-Reply-To: <200809051648.15914.jan-oliver.wagner@intevation.de> References: <48B3A82B.5090605@suse.cz> <200809051648.15914.jan-oliver.wagner@intevation.de> Message-ID: <20080907001242.GA19334@javifsp.no-ip.org> On Fri, Sep 05, 2008 at 04:48:13PM +0200, Jan-Oliver Wagner wrote: > Javier, > > since this affects a script authored by you. Oh. This script should be "under the GPLv2 license or later (at your option)". Regards Javier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080907/bc4ab145/attachment.pgp From jan-oliver.wagner at intevation.de Mon Sep 8 15:06:40 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 8 Sep 2008 15:06:40 +0200 Subject: [Openvas-devel] smb_nt.inc In-Reply-To: <200808211516.27373.jan-oliver.wagner@intevation.de> References: <001a01c8eb35$82b73d20$0301a8c0@mahesh> <488A8FCB.40208@securityspace.com> <200808211516.27373.jan-oliver.wagner@intevation.de> Message-ID: <200809081506.43057.jan-oliver.wagner@intevation.de> On Donnerstag, 21. August 2008, Jan-Oliver Wagner wrote: > The only problem is to find a clean download of the plugin feed that > is not mixed up with a local nessus-plugins installation that contained > already proprietary plugins. > If anyone has such lying around, I'd be glad to receive it as I do not have such. > Helpful would be one from the very first days of GPL feed and one of the very last > days. I received two states of the GPL feed and uploaded them here: http://www.openvas.org/download/misc/ One is from the very beginning, the second (smaller!) one from 18 months later. I did not receive a snapshot of the very last day of the GPL feed (don't even when it died exactly). However, these two should be good to fill some gaps of missing .inc and dpenedency .nasl files. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Tue Sep 9 13:54:21 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 9 Sep 2008 13:54:21 +0200 Subject: [Openvas-devel] trunk: big changes towards OTP and OID Message-ID: <200809091354.24425.jan-oliver.wagner@intevation.de> Hello OpenVAS developers, today we (Michael and myself) will start the big change towards OTP and OID. The changes will be applied to trunk, so will not affect the stable branches. openvas-libraries now needs to be branched as well. openvas-libnasl may remain as is because it seems we do not need to change anything there. However, it does not make sense to create a giant patch to have this all in one go. We rather will commit patches step by step. Each will compile, but very likely the functionality will be broken for a while. We try to be as quick as possible with this, but it might take a week or so to have the three modules adapted. IMHO this preocedure is much more cost efficient than keeping permanent compatibility. After that, I think we should release 2.0-beta1. Initially I had a 1.1-beta1 in mind, but the changes are quite comprehensive and there will be no compatibily with the 1.0 release (except for the NVTs of course!). All the best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Tue Sep 9 16:38:58 2008 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 09 Sep 2008 10:38:58 -0400 Subject: [Openvas-devel] [Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts In-Reply-To: <20080909074546.48ED740732@pyrosoma.intevation.org> References: <20080909074546.48ED740732@pyrosoma.intevation.org> Message-ID: <48C68A82.9000706@securityspace.com> Re gather-package-list-sigkeyid.nasl If I'm not mistaken, we might need to rethink the approach on this script. As it stands, this script overwrites the "ssh/login/rpms" kb item that is set by gather-package-list.nasl We should either change gather-package.list.nasl to include the desired capability, or have this gather-package-list-sigkeyid.nasl set a different set of kb variables to avoid conflicts. Thomas > + buf = ssh_cmd(socket:sock, cmd:"/bin/rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig};'"); > + set_kb_item(name: "ssh/login/rpms", value: ";" + buf); From jan-oliver.wagner at intevation.de Tue Sep 9 17:24:30 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 9 Sep 2008 17:24:30 +0200 Subject: [Openvas-devel] [Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts In-Reply-To: <48C68A82.9000706@securityspace.com> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <48C68A82.9000706@securityspace.com> Message-ID: <200809091724.32245.jan-oliver.wagner@intevation.de> On Dienstag, 9. September 2008, Thomas Reinke wrote: > Re gather-package-list-sigkeyid.nasl > > If I'm not mistaken, we might need to rethink the > approach on this script. As it stands, this script > overwrites the "ssh/login/rpms" kb item that is > set by gather-package-list.nasl hm, the new script overwrites the KB in any case, even if not used? However, checking it is easily done and not noticed. Michael: better fix this soon. > We should either change gather-package.list.nasl > to include the desired capability, or have this > gather-package-list-sigkeyid.nasl set a different > set of kb variables to avoid conflicts. Probably it is best to make it configurable to retrieve signatures at it blows up the KB for the NASL-based tests unecessarily. Maybe a global setting "support oval" ? Or more explicit "Retrieve package signatures into KB" as an preferences option of gather-package.list.nasl (off by default) ? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Tue Sep 9 19:57:13 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 9 Sep 2008 19:57:13 +0200 Subject: [Openvas-devel] [Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts In-Reply-To: <200809091724.32245.jan-oliver.wagner@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <48C68A82.9000706@securityspace.com> <200809091724.32245.jan-oliver.wagner@intevation.de> Message-ID: <200809091957.13565.michael.wiegand@intevation.de> Am Dienstag, 9. September 2008 17:24:30 schrieb Jan-Oliver Wagner: > > If I'm not mistaken, we might need to rethink the > > approach on this script. As it stands, this script > > overwrites the "ssh/login/rpms" kb item that is > > set by gather-package-list.nasl > > hm, the new script overwrites the KB in any case, even if not used? > However, checking it is easily done and not noticed. > > Michael: better fix this soon. I think there is only little potential for conflict as it is unlikely that both scripts will run during the same scan run. The only "script" that uses gather-package-list-sigkeyid.nasl is the OVAL integration; my rationale behind creating a modified .nasl was that I was not sure if all plugins that required gather-package-list.nasl would be able to handle the additional item of information retrieved by the modified rpm query. This modification was strictly a measure to avoid breaking compatibility with plugins already in existence; once we have established that all plugins can handle the additional information, we can safely include this capability into gather-package.list.nasl. > > We should either change gather-package.list.nasl > > to include the desired capability, or have this > > gather-package-list-sigkeyid.nasl set a different > > set of kb variables to avoid conflicts. As I explained, this will happen sooner rather than later with OVAL support maturing in the near future. > Probably it is best to make it configurable to retrieve > signatures at it blows up the KB for the NASL-based tests > unecessarily. I don't think KB size is a big issue in this case, since a great amount of KB space is currently being wasted by simply dumping the result of the remote package query in one single KB entry. I think it would really make sense to put the package information into the KB in a more structured way, preferably distribution-independent. This would make the information retrieved a lot more useful, especially for other plugins. > Maybe a global setting "support oval" ? > Or more explicit "Retrieve package signatures into KB" > as an preferences option of gather-package.list.nasl (off by default) ? That would certainly be a possibility if KB size is a big concern; another option would be to only retrieve the package signatures from system where we know we can use them, namely RHEL3, 4 and 5. But on the whole I'm very much in favor of a more structured approach to information gathering that would avoid issues like this in the future. Regards, Michael From lists at securityspace.com Wed Sep 10 02:30:46 2008 From: lists at securityspace.com (Thomas Reinke) Date: Tue, 09 Sep 2008 20:30:46 -0400 Subject: [Openvas-devel] [Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts In-Reply-To: <200809091957.13565.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <48C68A82.9000706@securityspace.com> <200809091724.32245.jan-oliver.wagner@intevation.de> <200809091957.13565.michael.wiegand@intevation.de> Message-ID: <48C71536.3070003@securityspace.com> > I think there is only little potential for conflict as it is unlikely that > both scripts will run during the same scan run. If both scripts are in the feed, both scripts are automatically run on any open ssh port. If both can login, then both will retrieve information, and whichever one is run second will clobber the kb entries made by the first one. > > The only "script" that uses gather-package-list-sigkeyid.nasl is the OVAL > integration; my rationale behind creating a modified .nasl was that I was not > sure if all plugins that required gather-package-list.nasl would be able to > handle the additional item of information retrieved by the modified rpm > query. Whether or not there are scripts dependent on this new script is irrelevant. The fact that they are both in the feed at the same time makes for unpredictable results, unless kb variable names are changed. > > This modification was strictly a measure to avoid breaking compatibility with > plugins already in existence; once we have established that all plugins can > handle the additional information, we can safely include this capability into > gather-package.list.nasl. Ok...I understand the intent, it's just the execution failed to accomplish that what was desired. Thomas From michael.wiegand at intevation.de Wed Sep 10 09:16:54 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 10 Sep 2008 09:16:54 +0200 Subject: [Openvas-devel] =?iso-8859-1?q?=5BOpenvas-commits=5D_r1298_-_in?= =?iso-8859-1?q?=09trunk/openvas-plugins=3A_=2E_scripts?= In-Reply-To: <48C71536.3070003@securityspace.com> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <200809091957.13565.michael.wiegand@intevation.de> <48C71536.3070003@securityspace.com> Message-ID: <200809100916.54702.michael.wiegand@intevation.de> Am Mittwoch, 10. September 2008 02:30:46 schrieb Thomas Reinke: > If both scripts are in the feed, both scripts are automatically run > on any open ssh port. If both can login, then both will retrieve > information, and whichever one is run second will clobber the kb > entries made by the first one. > > Whether or not there are scripts dependent on this new script is > irrelevant. The fact that they are both in the feed at the same > time makes for unpredictable results, unless kb variable names > are changed. I have now checked the scripts that do access ssh/login/rpms. It turn out that there are only three of them in the feed, and they all access ssh/login/rpms in the same way: cups_CB-A08-0045.nasl, kerberos_CB-A08-0044.nasl and samba_CB-A08-0085.nasl. As far as I can tell from reading the NASL, those scripts will ignore any additional information. I would appreciate it if someone could confirm my observation, but I do think there is little potential for conflict. If this is the case, I think we could safely include the new feature into gather-package-list.nasl. As a precautionary measure, we could limit collection of signatures to RHEL3-5 as I proposed yesterday; since the three scripts mentioned aboved only access ssh/login/rpms if the detect a SuSE or Fedora system, this should eliminate any potential for conflict. I also discovered that there are two other scripts collecting ssh/login/rpms: ssh_get_info.nasl and secpod_ssh_sys_info.nasl. The changes in secpod_ssh_sys_info.nasl might also break the three scripts mentioned above, since they introduced a newline character in the rpm query results. As I said before, I am no NASL expert, but you might want to take a look at that. > Ok...I understand the intent, it's just the execution failed to > accomplish that what was desired. Agreed. I guess I might have been a little too enthusiastic to get OVAL support into the trunk. ;) Let me know what you think. Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Wed Sep 10 09:55:10 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Wed, 10 Sep 2008 13:25:10 +0530 Subject: [Openvas-devel] [Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts In-Reply-To: <200809100916.54702.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org><200809091957.13565.michael.wiegand@intevation.de><48C71536.3070003@securityspace.com> <200809100916.54702.michael.wiegand@intevation.de> Message-ID: <001d01c9131a$9094ad30$0201a8c0@mahesh> We initially had secpod_ssh_sys_info.nasl and all our scripts were written with this. Later on, when we tried to integrate with ssh_get_info.nasl, it turned out that some regular expressions were not working on the results of "rpm -qa" and hence we introduced the newline char. As of now, only Gentoo advisory checks are using ssh_get_info.nasl, if they do not break with \n addition, it should work. We can move to using ssh_get_info.nasl or Gentoo checks can be moved to use secpod_ssh_sys_info.nasl. Thanks, 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, September 10, 2008 12:47 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel][Openvas-commits] r1298 - in trunk/openvas-plugins: . scripts Am Mittwoch, 10. September 2008 02:30:46 schrieb Thomas Reinke: > If both scripts are in the feed, both scripts are automatically run > on any open ssh port. If both can login, then both will retrieve > information, and whichever one is run second will clobber the kb > entries made by the first one. > > Whether or not there are scripts dependent on this new script is > irrelevant. The fact that they are both in the feed at the same > time makes for unpredictable results, unless kb variable names > are changed. I have now checked the scripts that do access ssh/login/rpms. It turn out that there are only three of them in the feed, and they all access ssh/login/rpms in the same way: cups_CB-A08-0045.nasl, kerberos_CB-A08-0044.nasl and samba_CB-A08-0085.nasl. As far as I can tell from reading the NASL, those scripts will ignore any additional information. I would appreciate it if someone could confirm my observation, but I do think there is little potential for conflict. If this is the case, I think we could safely include the new feature into gather-package-list.nasl. As a precautionary measure, we could limit collection of signatures to RHEL3-5 as I proposed yesterday; since the three scripts mentioned aboved only access ssh/login/rpms if the detect a SuSE or Fedora system, this should eliminate any potential for conflict. I also discovered that there are two other scripts collecting ssh/login/rpms: ssh_get_info.nasl and secpod_ssh_sys_info.nasl. The changes in secpod_ssh_sys_info.nasl might also break the three scripts mentioned above, since they introduced a newline character in the rpm query results. As I said before, I am no NASL expert, but you might want to take a look at that. > Ok...I understand the intent, it's just the execution failed to > accomplish that what was desired. Agreed. I guess I might have been a little too enthusiastic to get OVAL support into the trunk. ;) Let me know what you think. Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht 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 Wed Sep 10 14:23:17 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 10 Sep 2008 14:23:17 +0200 Subject: [Openvas-devel] =?iso-8859-1?q?=5BOpenvas-commits=5D_r1298_-_in?= =?iso-8859-1?q?=09trunk/openvas-plugins=3A_=2E_scripts?= In-Reply-To: <001d01c9131a$9094ad30$0201a8c0@mahesh> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <200809100916.54702.michael.wiegand@intevation.de> <001d01c9131a$9094ad30$0201a8c0@mahesh> Message-ID: <200809101423.19927.jan-oliver.wagner@intevation.de> On Mittwoch, 10. September 2008, Chandrashekhar B wrote: > We initially had secpod_ssh_sys_info.nasl and all our scripts were written > with this. Later on, when we tried to integrate with ssh_get_info.nasl, it > turned out that some regular expressions were not working on the results of > "rpm -qa" and hence we introduced the newline char. As of now, only Gentoo > advisory checks are using ssh_get_info.nasl, if they do not break with \n > addition, it should work. We can move to using ssh_get_info.nasl or Gentoo > checks can be moved to use secpod_ssh_sys_info.nasl. I'd prefer to consolidate on a single gatherer. IMHO it should be the one by Thomas, because it the most advanced one. A detailed analysis/comparison before removing the other ones should be done of course. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openvas-bugs at wald.intevation.org Tue Sep 9 15:16:32 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Tue, 9 Sep 2008 15:16:32 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B758=5D_Floating_Po?= =?utf-8?q?int_Exception_Crashes_Client?= Message-ID: <20080909131632.C004B404DF@pyrosoma.intevation.org> Bugs item #758, was opened at 2008-09-09 13:16 Status: Open Priority: 3 Submitted By: John Smith (johnsmith) Assigned to: Nobody (None) Summary: Floating Point Exception Crashes Client Resolution: None Severity: normal Version: v1.0 Component: openvas-client Operating System: Linux Product: OpenVAS Hardware: Other URL: Initial Comment: The linux client always seems to crash, prodominantly when Openvas just begins scanning,(might be to do with the math drawing the progress bars?). Using: 64bit Linux Gentoo Openvas client 1.0.4v GCC 4.1.2 compiler ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=758&group_id=29 From openvas-bugs at wald.intevation.org Thu Sep 11 01:48:45 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 11 Sep 2008 01:48:45 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B759=5D_PID_file_no?= =?utf-8?q?t_in_FHS_location?= Message-ID: <20080910234845.102F34073E@pyrosoma.intevation.org> Bugs item #759, was opened at 2008-09-10 23:48 Status: Open Priority: 3 Submitted By: Tim Brown (timb) Assigned to: Tim Brown (timb) Summary: PID file not in FHS location Resolution: None Severity: None Version: None Component: openvas-server Operating System: None Product: None Hardware: None URL: Initial Comment: PID file is written to /var/lib/run/openvasd.pid. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=759&group_id=29 From openvas-bugs at wald.intevation.org Thu Sep 11 01:50:56 2008 From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org) Date: Thu, 11 Sep 2008 01:50:56 +0200 (CEST) Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B760=5D_OpenVAS_cli?= =?utf-8?q?ent_HTML_exports_of_report_reference_Nessus_not_OpenVAS?= Message-ID: <20080910235056.A69964073E@pyrosoma.intevation.org> Bugs item #760, was opened at 2008-09-10 23:50 Status: Open Priority: 3 Submitted By: Tim Brown (timb) Assigned to: Tim Brown (timb) Summary: OpenVAS client HTML exports of report reference Nessus not OpenVAS Resolution: None Severity: None Version: v1.1 Component: openvas-client Operating System: None Product: None Hardware: None URL: Initial Comment: Reports reference Nessus not OpenVAS. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=220&aid=760&group_id=29 From jan-oliver.wagner at intevation.de Thu Sep 11 09:13:01 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 11 Sep 2008 09:13:01 +0200 Subject: [Openvas-devel] planning release openvas-plugins 1.0.3 Message-ID: <200809110913.04740.jan-oliver.wagner@intevation.de> Hello, it is time to make a new release of the openvas-plugins module. Major reason is a important improvement of the sync routine for anyone who is connected to a feed. For those who are not, it is nice to get 1000+ new NVTs :-) I want to make the release fast, so let me know asap if you want special things in the new release. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Thu Sep 11 17:37:14 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 11 Sep 2008 11:37:14 -0400 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <001d01c9131a$9094ad30$0201a8c0@mahesh> References: <20080909074546.48ED740732@pyrosoma.intevation.org><200809091957.13565.michael.wiegand@intevation.de><48C71536.3070003@securityspace.com> <200809100916.54702.michael.wiegand@intevation.de> <001d01c9131a$9094ad30$0201a8c0@mahesh> Message-ID: <48C93B2A.4050401@securityspace.com> Hmmm... Well, two problems - there's the variable naming conflict, and repeated data gathering done by different scripts. To avoid all of this, I would recommend that a) OpenVAS have a single data gatherer b) Any family of local checks added to OpenVAS should (must?) have the data dathering commands added to the OpenVAS data gatherer. I think someone on the OpenVAS team needs to take charge of a single data gathering script, and as various local check families are added to OpenVAS, support for the package retrievals are added to that single script. Anyone else that wants to have their own proprietary families of scripts can choose to implement their own data gathering functions, but when a family of scripts is added to OpenVAS, the queries needed to do that (be it dpkg, rpm -qa, or whatever) ought to be in a single data gatherer. I am willing to work on moving Gentoo scripts over to a single data gatherer (currently, Gentoo isn't up to date - Michel - are you still providing GPLed support for Gentoo, and if so, do you wish to continue to do so?), and hopefully thereby remove ssh_get_info.nasl out of the loop (or the very least, remove within it any code made redundant by another data gatherer). Michael, re signature checks for RHEL line, I see no reason why this should't be put directly into the this same data gatherer. It won't break anything at this point in OpenVAS to do so. Chandra, could you check out pkg-lib-rpm.inc and see if that helps you at all with resolving your regex problems? I've just checked this in - it is the helper library we've been using on all distros that support RPMs (RedHat, Fedora, Mandrake, SuSE, Trustix, TurboLinux) Thomas Chandrashekhar B wrote: > We initially had secpod_ssh_sys_info.nasl and all our scripts were written > with this. Later on, when we tried to integrate with ssh_get_info.nasl, it > turned out that some regular expressions were not working on the results of > "rpm -qa" and hence we introduced the newline char. As of now, only Gentoo > advisory checks are using ssh_get_info.nasl, if they do not break with \n > addition, it should work. We can move to using ssh_get_info.nasl or Gentoo > checks can be moved to use secpod_ssh_sys_info.nasl. > > Thanks, > 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, September 10, 2008 12:47 PM > To: openvas-devel at wald.intevation.org > Subject: Re: [Openvas-devel][Openvas-commits] r1298 - in > trunk/openvas-plugins: . scripts > > Am Mittwoch, 10. September 2008 02:30:46 schrieb Thomas Reinke: >> If both scripts are in the feed, both scripts are automatically run >> on any open ssh port. If both can login, then both will retrieve >> information, and whichever one is run second will clobber the kb >> entries made by the first one. >> >> Whether or not there are scripts dependent on this new script is >> irrelevant. The fact that they are both in the feed at the same >> time makes for unpredictable results, unless kb variable names >> are changed. > > I have now checked the scripts that do access ssh/login/rpms. It turn out > that > there are only three of them in the feed, and they all access ssh/login/rpms > > in the same way: cups_CB-A08-0045.nasl, kerberos_CB-A08-0044.nasl and > samba_CB-A08-0085.nasl. > > As far as I can tell from reading the NASL, those scripts will ignore any > additional information. I would appreciate it if someone could confirm my > observation, but I do think there is little potential for conflict. > > If this is the case, I think we could safely include the new feature into > gather-package-list.nasl. As a precautionary measure, we could limit > collection of signatures to RHEL3-5 as I proposed yesterday; since the three > > scripts mentioned aboved only access ssh/login/rpms if the detect a SuSE or > Fedora system, this should eliminate any potential for conflict. > > I also discovered that there are two other scripts collecting > ssh/login/rpms: > ssh_get_info.nasl and secpod_ssh_sys_info.nasl. The changes in > secpod_ssh_sys_info.nasl might also break the three scripts mentioned above, > > since they introduced a newline character in the rpm query results. As I > said > before, I am no NASL expert, but you might want to take a look at that. > >> Ok...I understand the intent, it's just the execution failed to >> accomplish that what was desired. > > Agreed. I guess I might have been a little too enthusiastic to get OVAL > support into the trunk. ;) > > Let me know what you think. > > Regards, > > Michael From jan-oliver.wagner at intevation.de Thu Sep 11 22:24:14 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 11 Sep 2008 22:24:14 +0200 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <48C93B2A.4050401@securityspace.com> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <001d01c9131a$9094ad30$0201a8c0@mahesh> <48C93B2A.4050401@securityspace.com> Message-ID: <200809112224.17384.jan-oliver.wagner@intevation.de> Thomas, On Thursday 11 September 2008 17:37, Thomas Reinke wrote: > Well, two problems - there's the variable naming conflict, > and repeated data gathering done by different scripts. > > To avoid all of this, I would recommend that > a) OpenVAS have a single data gatherer agreed! > b) Any family of local checks added to OpenVAS > should (must?) have the data dathering commands > added to the OpenVAS data gatherer. agreed (a 'must' is probably not enforcable, but a very strong recommendation should be made). > I think someone on the OpenVAS team needs to take charge > of a single data gathering script, and as various > local check families are added to OpenVAS, support for > the package retrievals are added to that single script. This is a very good idea. We need also someone to do the QA. And another one to write up the documentation about this into the OpenVAS compendium. Intevation can provide resources, but it would be good to have people with different backgrounds in this 'team-of-three'. Any proposals or recommendations? > Anyone else that wants to have their own proprietary > families of scripts can choose to implement their > own data gathering functions, but when a family of > scripts is added to OpenVAS, the queries needed to > do that (be it dpkg, rpm -qa, or whatever) ought to > be in a single data gatherer. yes. > Michael, re signature checks for RHEL line, I see no > reason why this should't be put directly into the > this same data gatherer. It won't break anything > at this point in OpenVAS to do so. good. Should be consolidate this before the release or might it need more than just ~2 hours to do it? > Chandra, could you check out pkg-lib-rpm.inc and > see if that helps you at all with resolving your > regex problems? I've just checked this in - it is > the helper library we've been using on all distros > that support RPMs (RedHat, Fedora, Mandrake, SuSE, > Trustix, TurboLinux) thanks for the contribtion, Thomas. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Fri Sep 12 07:53:07 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 12 Sep 2008 07:53:07 +0200 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809112224.17384.jan-oliver.wagner@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <48C93B2A.4050401@securityspace.com> <200809112224.17384.jan-oliver.wagner@intevation.de> Message-ID: <200809120753.07959.michael.wiegand@intevation.de> Am Donnerstag, 11. September 2008 22:24:14 schrieb Jan-Oliver Wagner: > > Michael, re signature checks for RHEL line, I see no > > reason why this should't be put directly into the > > this same data gatherer. It won't break anything > > at this point in OpenVAS to do so. > > good. Should be consolidate this before the release > or might it need more than just ~2 hours to do it? If we take up my proposal and just change the rpm queries for RHEL, this will take only a few minutes. > > Chandra, could you check out pkg-lib-rpm.inc and > > see if that helps you at all with resolving your > > regex problems? I've just checked this in - it is > > the helper library we've been using on all distros > > that support RPMs (RedHat, Fedora, Mandrake, SuSE, > > Trustix, TurboLinux) Chandra: rpm queries on RHEL would return '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig};' (instead of '%{NAME}~%{VERSION}~%{RELEASE};') after the change. Does this affect your regex issue? Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Sep 12 08:36:47 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 12:06:47 +0530 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120753.07959.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org><48C93B2A.4050401@securityspace.com><200809112224.17384.jan-oliver.wagner@intevation.de> <200809120753.07959.michael.wiegand@intevation.de> Message-ID: <003201c914a1$f2616890$0301a8c0@mahesh> For RHEL, if we can add \n at the end in this query, it works, rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' The regular expression is failing because of large string and it doesn't seem to grep appropriately. I think, we should all move to gather-package-list.nasl, move everything into this. I just glanced through, nothing seems to break by adding '\n' at the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl and move all our scripts to point to this. If someone can move all Gentoo scripts to point to gather-package-list.nasl, all works fine. Thanks, 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: Friday, September 12, 2008 11:23 AM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] KB name conflicts & package list gathering Am Donnerstag, 11. September 2008 22:24:14 schrieb Jan-Oliver Wagner: > > Michael, re signature checks for RHEL line, I see no > > reason why this should't be put directly into the > > this same data gatherer. It won't break anything > > at this point in OpenVAS to do so. > > good. Should be consolidate this before the release > or might it need more than just ~2 hours to do it? If we take up my proposal and just change the rpm queries for RHEL, this will take only a few minutes. > > Chandra, could you check out pkg-lib-rpm.inc and > > see if that helps you at all with resolving your > > regex problems? I've just checked this in - it is > > the helper library we've been using on all distros > > that support RPMs (RedHat, Fedora, Mandrake, SuSE, > > Trustix, TurboLinux) Chandra: rpm queries on RHEL would return '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig};' (instead of '%{NAME}~%{VERSION}~%{RELEASE};') after the change. Does this affect your regex issue? Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht 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 michael.wiegand at intevation.de Fri Sep 12 09:03:01 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Fri, 12 Sep 2008 09:03:01 +0200 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <003201c914a1$f2616890$0301a8c0@mahesh> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <200809120753.07959.michael.wiegand@intevation.de> <003201c914a1$f2616890$0301a8c0@mahesh> Message-ID: <200809120903.01519.michael.wiegand@intevation.de> Am Freitag, 12. September 2008 08:36:47 schrieb Chandrashekhar B: > For RHEL, if we can add \n at the end in this query, it works, > rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' Sure, no problem on my side. I will fix the parser for the OVAL plugins accordingly. > The regular expression is failing because of large string and it doesn't > seem to grep appropriately. > > I think, we should all move to gather-package-list.nasl, move everything > into this. I just glanced through, nothing seems to break by adding '\n' at > the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl > and move all our scripts to point to this. While we are at it, would it make sense to leave the parsing as well to gather-package-list.nasl? That way, we wouldn't end up with a huge string in the KB that could be in any of the different formats (depending on the distribution) but with structured information about the packages in the KB. This would enable us to check for package versions etc. using the functions already available for the KB instead of writing dozens of new functions in NASL. I'm not sure how much work it would take, but IMHO it would be well worth the effort and make writing LSCs both easier and more efficient. Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Sep 12 09:16:18 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 12:46:18 +0530 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120903.01519.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org><200809120753.07959.michael.wiegand@intevation.de><003201c914a1$f2616890$0301a8c0@mahesh> <200809120903.01519.michael.wiegand@intevation.de> Message-ID: <003901c914a7$84245f80$0301a8c0@mahesh> -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Michael Wiegand Sent: Friday, September 12, 2008 12:33 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] KB name conflicts & package list gathering > Am Freitag, 12. September 2008 08:36:47 schrieb Chandrashekhar B: >> For RHEL, if we can add \n at the end in this query, it works, >> rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' > Sure, no problem on my side. I will fix the parser for the OVAL plugins > accordingly. >> The regular expression is failing because of large string and it doesn't >> seem to grep appropriately. >> >> I think, we should all move to gather-package-list.nasl, move everything >> into this. I just glanced through, nothing seems to break by adding '\n' >>at >> the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl >> and move all our scripts to point to this. > While we are at it, would it make sense to leave the parsing as well to > gather-package-list.nasl? > That way, we wouldn't end up with a huge string in the KB that could be in > any > of the different formats (depending on the distribution) but with > structured information about the packages in the KB. This would enable us > to check for package versions etc. using the functions already available > for the KB instead of writing dozens of new functions in NASL. By adding \n, it would look nice in the KB item :) If we need additional parsing, we should add respective .inc files where specific parsing is done. Am not sure if I understood this correctly. > I'm not sure how much work it would take, but IMHO it would be well worth > the effort and make writing LSCs both easier and more efficient. Chandra. From jan-oliver.wagner at intevation.de Fri Sep 12 09:18:49 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Sep 2008 09:18:49 +0200 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120903.01519.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <003201c914a1$f2616890$0301a8c0@mahesh> <200809120903.01519.michael.wiegand@intevation.de> Message-ID: <200809120918.52035.jan-oliver.wagner@intevation.de> On Freitag, 12. September 2008, Michael Wiegand wrote: > Am Freitag, 12. September 2008 08:36:47 schrieb Chandrashekhar B: > > For RHEL, if we can add \n at the end in this query, it works, > > rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' > > Sure, no problem on my side. I will fix the parser for the OVAL plugins > accordingly. yes, I'd say: go ahead. Chandra, Thomas, can you make your changes accrodingly so that we can get out openvas-plugins today? > > The regular expression is failing because of large string and it doesn't > > seem to grep appropriately. > > > > I think, we should all move to gather-package-list.nasl, move everything > > into this. I just glanced through, nothing seems to break by adding '\n' at > > the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl > > and move all our scripts to point to this. > > While we are at it, would it make sense to leave the parsing as well to > gather-package-list.nasl? > > That way, we wouldn't end up with a huge string in the KB that could be in any > of the different formats (depending on the distribution) but with structured > information about the packages in the KB. This would enable us to check for > package versions etc. using the functions already available for the KB > instead of writing dozens of new functions in NASL. > > I'm not sure how much work it would take, but IMHO it would be well worth the > effort and make writing LSCs both easier and more efficient. Sounds promising. But I would like to first do the new release. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Sep 12 10:25:35 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 13:55:35 +0530 Subject: [Openvas-devel] http_keepalive.inc Message-ID: <000001c914b1$28309810$0301a8c0@mahesh> From bchandra at secpod.com Fri Sep 12 10:42:20 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 14:12:20 +0530 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120918.52035.jan-oliver.wagner@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org><003201c914a1$f2616890$0301a8c0@mahesh><200809120903.01519.michael.wiegand@intevation.de> <200809120918.52035.jan-oliver.wagner@intevation.de> Message-ID: <000201c914b3$7bb9b780$0301a8c0@mahesh> > > For RHEL, if we can add \n at the end in this query, it works, > > rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' > > > Sure, no problem on my side. I will fix the parser for the OVAL plugins > > accordingly. > yes, I'd say: go ahead. > Chandra, Thomas, can you make your changes accrodingly so that we > can get out openvas-plugins today? We are working on gather-package-list.nasl to add \n and also reworking our scripts to point to gather-package-list.nasl There's ss_ssh_func.inc which is same as ssh_func.inc except few changes that I had made to ssh_func.inc. Can we again, retain just one file here? We'll move this to ssh_func.inc? > > The regular expression is failing because of large string and it doesn't > > seem to grep appropriately. > > > > I think, we should all move to gather-package-list.nasl, move everything > > into this. I just glanced through, nothing seems to break by adding '\n' at > > the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl > > and move all our scripts to point to this. > > While we are at it, would it make sense to leave the parsing as well to > gather-package-list.nasl? > > That way, we wouldn't end up with a huge string in the KB that could be in any > of the different formats (depending on the distribution) but with structured > information about the packages in the KB. This would enable us to check for > package versions etc. using the functions already available for the KB > instead of writing dozens of new functions in NASL. > > I'm not sure how much work it would take, but IMHO it would be well worth the > effort and make writing LSCs both easier and more efficient. > Sounds promising. > But I would like to first do the new release. Chandra. From jan-oliver.wagner at intevation.de Fri Sep 12 12:20:23 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Sep 2008 12:20:23 +0200 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <000201c914b3$7bb9b780$0301a8c0@mahesh> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <200809120918.52035.jan-oliver.wagner@intevation.de> <000201c914b3$7bb9b780$0301a8c0@mahesh> Message-ID: <200809121220.26150.jan-oliver.wagner@intevation.de> On Freitag, 12. September 2008, Chandrashekhar B wrote: > We are working on gather-package-list.nasl to add \n and also reworking our > scripts to point to gather-package-list.nasl thanks! > There's ss_ssh_func.inc which is same as ssh_func.inc except few changes > that I had made to ssh_func.inc. Can we again, retain just one file here? > We'll move this to ssh_func.inc? I'd leave it to Thomas to comment, as ss_ssh_func.inc was contributed by him. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Sep 12 12:22:01 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Sep 2008 12:22:01 +0200 Subject: [Openvas-devel] http_keepalive.inc In-Reply-To: <000001c914b1$28309810$0301a8c0@mahesh> References: <000001c914b1$28309810$0301a8c0@mahesh> Message-ID: <200809121222.04637.jan-oliver.wagner@intevation.de> On Freitag, 12. September 2008, Chandrashekhar B wrote: > From nessus_gpl_feed_20060710_all-2.0.tar.gz, I can see an updated > http_keepalive.inc which has some new functions implemented. There are > number of plugins in the repository that are using these new functions. Can > I merge with this latest one? it was distributed with the GPL feed, so it is GPL. You should add a comment on the origin of the patch into ChangeLog and commit message. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Fri Sep 12 12:26:17 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 12 Sep 2008 12:26:17 +0200 Subject: [Openvas-devel] planning release openvas-plugins 1.0.3 In-Reply-To: <200809110913.04740.jan-oliver.wagner@intevation.de> References: <200809110913.04740.jan-oliver.wagner@intevation.de> Message-ID: <200809121226.20672.jan-oliver.wagner@intevation.de> On Donnerstag, 11. September 2008, Jan-Oliver Wagner wrote: > it is time to make a new release of the openvas-plugins module. > Major reason is a important improvement of the sync routine > for anyone who is connected to a feed. > For those who are not, it is nice to get 1000+ new NVTs :-) > > I want to make the release fast, so let me know asap if you > want special things in the new release. wow, it is almost impossible to find a quiet phase of openvas-plugins ;-) I'll wait for the gatherer consolidation and then will do the release. Hopefully this is done today, but this would mean some work for Chandra and Thomas. Don't whether this is feasable? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bchandra at secpod.com Fri Sep 12 13:24:12 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 16:54:12 +0530 Subject: [Openvas-devel] planning release openvas-plugins 1.0.3 In-Reply-To: <200809121226.20672.jan-oliver.wagner@intevation.de> References: <200809110913.04740.jan-oliver.wagner@intevation.de> <200809121226.20672.jan-oliver.wagner@intevation.de> Message-ID: <001301c914ca$17e59140$0301a8c0@mahesh> We consolidated with gather-package-list.nasl after adding a \n char and changed all secpod plugins to reflect to the new one. Chandra. -----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: Friday, September 12, 2008 3:56 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] planning release openvas-plugins 1.0.3 On Donnerstag, 11. September 2008, Jan-Oliver Wagner wrote: > it is time to make a new release of the openvas-plugins module. > Major reason is a important improvement of the sync routine > for anyone who is connected to a feed. > For those who are not, it is nice to get 1000+ new NVTs :-) > > I want to make the release fast, so let me know asap if you > want special things in the new release. wow, it is almost impossible to find a quiet phase of openvas-plugins ;-) I'll wait for the gatherer consolidation and then will do the release. Hopefully this is done today, but this would mean some work for Chandra and Thomas. Don't whether this is feasable? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ 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 bchandra at secpod.com Fri Sep 12 13:32:00 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 17:02:00 +0530 Subject: [Openvas-devel] http_keepalive.inc In-Reply-To: <200809121222.04637.jan-oliver.wagner@intevation.de> References: <000001c914b1$28309810$0301a8c0@mahesh> <200809121222.04637.jan-oliver.wagner@intevation.de> Message-ID: <001501c914cb$2ef08100$0301a8c0@mahesh> I have synched http_keepalive.inc with the 2006 GPL script. Along with that, I have also synched misc_func.inc and telnet_func.inc, also from the same set. This resolved number of script parse errors. Apart from the freebas* scripts, we have these many script errors that can't be resolved right now, smb_file_funcs.inc: No such file or directory [11708](js.scob.trojan.nasl) Undefined function 'smb_file_read' [11708](ossim_server_detect.nasl) Undefined function 'get_unknown_svc' [11708](pirelli_router_default_password.nasl) Undefined function 'get_telnet_banner' byte_func.inc: No such file or directory [11708](poptop_negative_read.nasl) Undefined function 'set_byte_order' smb_file_funcs.inc: No such file or directory [11708](putty_logon_credential_leak.nasl) Undefined function 'smb_file_read' slad.inc: No such file or directory [11708](slad_fetch_results.nasl) Undefined function 'get_slad_description' slad.inc: No such file or directory [11708](slad_run.nasl) Undefined function 'init_add_preferences' [11708](smb_nt_ms02-016.nasl) Undefined function 'hotfix_check_domain_controler' [11708](smb_nt_ms02-018.nasl) Undefined function 'hotfix_check_iis_installed' [11708](smb_nt_ms02-025.nasl) Undefined function 'hotfix_check_nt_server' [11708](smb_nt_ms02-051.nasl) Undefined function 'hotfix_check_nt_server' [11708](smb_nt_ms04-026.nasl) Undefined function 'hotfix_check_nt_server' ssl_funcs.inc: No such file or directory [11708](ssl_cert_expiry.nasl) Undefined function 'get_server_cert' [11708](webserver_robot.nasl) Undefined function 'http_recv_headers' Thanks, Chandra. -----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: Friday, September 12, 2008 3:52 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] http_keepalive.inc On Freitag, 12. September 2008, Chandrashekhar B wrote: > From nessus_gpl_feed_20060710_all-2.0.tar.gz, I can see an updated > http_keepalive.inc which has some new functions implemented. There are > number of plugins in the repository that are using these new functions. Can > I merge with this latest one? it was distributed with the GPL feed, so it is GPL. You should add a comment on the origin of the patch into ChangeLog and commit message. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ 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 kost at linux.hr Fri Sep 12 13:37:46 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Fri, 12 Sep 2008 13:37:46 +0200 Subject: [Openvas-devel] http_keepalive.inc In-Reply-To: <001501c914cb$2ef08100$0301a8c0@mahesh> References: <000001c914b1$28309810$0301a8c0@mahesh> <200809121222.04637.jan-oliver.wagner@intevation.de> <001501c914cb$2ef08100$0301a8c0@mahesh> Message-ID: <48CA548A.6090500@linux.hr> > [11708](slad_fetch_results.nasl) Undefined function 'get_slad_description' > slad.inc: No such file or directory > [11708](slad_run.nasl) Undefined function 'init_add_preferences' These two should work when OpenVAS is compiled with SLAD. Kost From bchandra at secpod.com Fri Sep 12 13:48:32 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Fri, 12 Sep 2008 17:18:32 +0530 Subject: [Openvas-devel] http_keepalive.inc In-Reply-To: <48CA548A.6090500@linux.hr> References: <000001c914b1$28309810$0301a8c0@mahesh> <200809121222.04637.jan-oliver.wagner@intevation.de><001501c914cb$2ef08100$0301a8c0@mahesh> <48CA548A.6090500@linux.hr> Message-ID: <001b01c914cd$7e4126e0$0301a8c0@mahesh> Ok...cool, I didn't compile with slad. Chandra. -----Original Message----- From: openvas-devel-bounces at wald.intevation.org [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Vlatko Kosturjak Sent: Friday, September 12, 2008 5:08 PM To: openvas-devel at wald.intevation.org Subject: Re: [Openvas-devel] http_keepalive.inc > [11708](slad_fetch_results.nasl) Undefined function 'get_slad_description' > slad.inc: No such file or directory > [11708](slad_run.nasl) Undefined function 'init_add_preferences' These two should work when OpenVAS is compiled with SLAD. Kost _______________________________________________ Openvas-devel mailing list Openvas-devel at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel From lists at securityspace.com Fri Sep 12 14:26:18 2008 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 12 Sep 2008 08:26:18 -0400 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120903.01519.michael.wiegand@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <200809120753.07959.michael.wiegand@intevation.de> <003201c914a1$f2616890$0301a8c0@mahesh> <200809120903.01519.michael.wiegand@intevation.de> Message-ID: <48CA5FEA.2070709@securityspace.com> Michael Wiegand wrote: >> I think, we should all move to gather-package-list.nasl, move everything >> into this. I just glanced through, nothing seems to break by adding '\n' at >> the end of rpm -qa queries. So, we'll add \n to gather-package-list.nasl >> and move all our scripts to point to this. > > While we are at it, would it make sense to leave the parsing as well to > gather-package-list.nasl? > > That way, we wouldn't end up with a huge string in the KB that could be in any > of the different formats (depending on the distribution) but with structured > information about the packages in the KB. This would enable us to check for > package versions etc. using the functions already available for the KB > instead of writing dozens of new functions in NASL. > > I'm not sure how much work it would take, but IMHO it would be well worth the > effort and make writing LSCs both easier and more efficient. > > Regards, > > Michael > Given the current approach of putting the parsing into a helper function in 'pkg-lib-*.inc', the LSC writing is about as easy as it is going to get. And if you look at the helper functions, they are simple as well, so I'm not sure the pain of trying to come up with and shoehorning all the distributions into a given structure would be worth it. Just my $0.02 worth. Thomas From lists at securityspace.com Fri Sep 12 15:10:30 2008 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 12 Sep 2008 09:10:30 -0400 Subject: [Openvas-devel] KB name conflicts & package list gathering In-Reply-To: <200809120918.52035.jan-oliver.wagner@intevation.de> References: <20080909074546.48ED740732@pyrosoma.intevation.org> <003201c914a1$f2616890$0301a8c0@mahesh> <200809120903.01519.michael.wiegand@intevation.de> <200809120918.52035.jan-oliver.wagner@intevation.de> Message-ID: <48CA6A46.4090005@securityspace.com> Jan-Oliver Wagner wrote: > On Freitag, 12. September 2008, Michael Wiegand wrote: >> Am Freitag, 12. September 2008 08:36:47 schrieb Chandrashekhar B: >>> For RHEL, if we can add \n at the end in this query, it works, >>> rpm -qa --qf '%{NAME}~%{VERSION}~%{RELEASE}~%{SIGGPG:pgpsig}\n' >> Sure, no problem on my side. I will fix the parser for the OVAL plugins >> accordingly. > > yes, I'd say: go ahead. > > Chandra, Thomas, can you make your changes accrodingly so that we > can get out openvas-plugins today? Ok...finished fixing the screwup on the bsd scripts done when we converted to OpenVAS' naming conventions (my bad). Gentoo scripts are going to be a problem. I'm noting that the pre-requisite is that they rely on a piece of code from the original ssh_get_info.nasl (Nessus version) that OpenVAS is choosing to not use. That, coupled with the fact that Gentoo isn't up to date anyways nor appears to be maintained anymore makes me loath to fix up the existing Gentoo scripts, at least for today's plugin release. Thomas From jan-oliver.wagner at intevation.de Wed Sep 17 16:52:28 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 17 Sep 2008 16:52:28 +0200 Subject: [Openvas-devel] http_keepalive.inc In-Reply-To: <001b01c914cd$7e4126e0$0301a8c0@mahesh> References: <000001c914b1$28309810$0301a8c0@mahesh> <48CA548A.6090500@linux.hr> <001b01c914cd$7e4126e0$0301a8c0@mahesh> Message-ID: <200809171652.32680.jan-oliver.wagner@intevation.de> On Freitag, 12. September 2008, Chandrashekhar B wrote: > Ok...cool, I didn't compile with slad. its not exactly "compile with": If you perform a SLAD installation somewhere, this installation will create a slad.inc which you have to put into the plugins directory. This concept leaves room for improvemens. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Wed Sep 17 17:01:01 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 17 Sep 2008 17:01:01 +0200 Subject: [Openvas-devel] Planning 2.0-beta1 release ! Message-ID: <200809171701.03499.jan-oliver.wagner@intevation.de> Hi, we are ready to reach out for the next generation OpenVAS! OpenVAS Client and OpenVAS Server as in trunk do offer new major features: * OTP * OID * OVAL All of this is not ultimately finished. But it works! To allow for easier testing, I'd like to release 2.0-beta1 releases of these modules: openvas-client openvas-server openvas-libraries openvas-libnasl and openvas-plugins remain compatible with 2.0 series. This especially means also that OpenVAS 2.0-beta1 is compatible with the OpenVAS NVT Feed! Maybe end of next week it is a good time to go for the releases. Any opinions/suggestions welcome! Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From phornung at gmail.com Wed Sep 17 17:04:45 2008 From: phornung at gmail.com (Patrick Hornung) Date: Wed, 17 Sep 2008 11:04:45 -0400 Subject: [Openvas-devel] Planning 2.0-beta1 release ! In-Reply-To: <200809171701.03499.jan-oliver.wagner@intevation.de> References: <200809171701.03499.jan-oliver.wagner@intevation.de> Message-ID: <9587e64c0809170804h24cea983y7f9182a6f6eb9df4@mail.gmail.com> Congratulations to all! That's excellent news! Once it's released, I'll create another virtual machine to allow everyone to try it out without impacting their current environments. On Wed, Sep 17, 2008 at 11:01 AM, Jan-Oliver Wagner < jan-oliver.wagner at intevation.de> wrote: > Hi, > > we are ready to reach out for the next generation OpenVAS! > > OpenVAS Client and OpenVAS Server as in trunk do offer new major features: > > * OTP > * OID > * OVAL > > All of this is not ultimately finished. But it works! > > To allow for easier testing, I'd like to release 2.0-beta1 releases > of these modules: > > openvas-client > openvas-server > openvas-libraries > > openvas-libnasl and openvas-plugins remain compatible with 2.0 series. > This especially means also that OpenVAS 2.0-beta1 is compatible with > the OpenVAS NVT Feed! > > Maybe end of next week it is a good time to go for the releases. > > Any opinions/suggestions welcome! > > Best > > Jan > > -- > Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck > Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ > 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 -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080917/d86f3ef7/attachment.htm From lists at securityspace.com Wed Sep 17 19:15:32 2008 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 17 Sep 2008 13:15:32 -0400 Subject: [Openvas-devel] Gentoo local security checks Message-ID: <48D13B34.2000701@securityspace.com> As mentioned earlier, the gentoo local checks are non-functional due to a missing prerequisite, and are no longer being kept up to date with new GPLed scripts. Does anyone have an issue with the entire set being replaced with an up-to-date set of Gentoo scripts that work using the existing gather-package-list.nasl script as a prerequisite? Thomas From hanno at hboeck.de Wed Sep 17 20:46:19 2008 From: hanno at hboeck.de (Hanno =?utf-8?q?B=C3=B6ck?=) Date: Wed, 17 Sep 2008 20:46:19 +0200 Subject: [Openvas-devel] [PATCH] openvas-plugins: respect LDFLAGS Message-ID: <200809172046.19682.hanno@hboeck.de> Attached patch will let openvas-plugins respect user-setted LDFLAGS. Latest gentoo portage throws warnings if this is not the case. Please apply. -- Hanno B?ck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de -------------- next part -------------- A non-text attachment was scrubbed... Name: openvas-plugins-respect-ldflags.diff Type: text/x-diff Size: 9987 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080917/400cb8c9/openvas-plugins-respect-ldflags.bin -------------- 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/20080917/400cb8c9/attachment.pgp From skjortan at gmail.com Thu Sep 18 08:45:03 2008 From: skjortan at gmail.com (Thomas Olofsson) Date: Thu, 18 Sep 2008 08:45:03 +0200 Subject: [Openvas-devel] [PATCH] openvas-plugins: respect LDFLAGS In-Reply-To: <200809172046.19682.hanno@hboeck.de> References: <200809172046.19682.hanno@hboeck.de> Message-ID: Thanks. This is great and this patch will help my OSX mac port greatly. This was my major concern since i had to link against /opt/*** in osx port and give some other magic ld flags to. I can report that everything now builds on OSX. I have made a few changes in the code using ifdefs. And a few changes that i think should be generic. I will post patches later this week when i see that everything runs and not just builds. On Wed, Sep 17, 2008 at 8:46 PM, Hanno B?ck wrote: > Attached patch will let openvas-plugins respect user-setted LDFLAGS. > > Latest gentoo portage throws warnings if this is not the case. > > Please apply. > > -- > Hanno B?ck Blog: http://www.hboeck.de/ > GPG: 3DBD3B20 Jabber/Mail: hanno at hboeck.de > > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > > From marco.fradin at free.fr Sun Sep 21 10:59:59 2008 From: marco.fradin at free.fr (marco) Date: Sun, 21 Sep 2008 10:59:59 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation Message-ID: <200809211059.59443.marco.fradin@free.fr> Hi everyone, See enclosed fr.po I started yesterday for OpenVAS-Client. Hope this will help you. Regards and keep to be free as a GNU Marco (sitepamarco) -------------- next part -------------- A non-text attachment was scrubbed... Name: fr.po Type: application/x-gettext Size: 70833 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080921/2581f76d/fr-0001.bin From michael.wiegand at intevation.de Mon Sep 22 10:57:46 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 22 Sep 2008 10:57:46 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <200809211059.59443.marco.fradin@free.fr> References: <200809211059.59443.marco.fradin@free.fr> Message-ID: <200809221057.46882.michael.wiegand@intevation.de> Am Sonntag, 21. September 2008 10:59:59 schrieb marco: > Hi everyone, > See enclosed fr.po I started yesterday for OpenVAS-Client. > Hope this will help you. Thank you very much for your work, this is indeed very helpful. As far as I can tell (and understand), the translation looks very good, I just found a few minor issues: Line 3: "German" should probably be "French". ;) Line 758: "Security hole(s) found" has a German translation. Line 1011: Doesn't make sense to me, am I missing something? Line 1039: The getchar in nessus/sslui.c:394 is hardcoded to 'y' and 'n', so '(o/n)' won't work. This isn't nice for i18n, but that's another issue. Could you fix these issues and send me the updated file? All: If there are no objections, I'd like to commit this translation to -trunk as soon as it is done and backport it to the 1-0 branch. Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Tue Sep 23 03:22:30 2008 From: lists at securityspace.com (Thomas Reinke) Date: Mon, 22 Sep 2008 21:22:30 -0400 Subject: [Openvas-devel] Gentoo local security checks In-Reply-To: <48D13B34.2000701@securityspace.com> References: <48D13B34.2000701@securityspace.com> Message-ID: <48D844D6.10304@securityspace.com> 2nd call - any problems with the below? Thomas Thomas Reinke wrote: > As mentioned earlier, the gentoo local checks are > non-functional due to a missing prerequisite, and > are no longer being kept up to date with new GPLed > scripts. > > Does anyone have an issue with the entire set being > replaced with an up-to-date set of Gentoo scripts > that work using the existing gather-package-list.nasl > script as a prerequisite? > > Thomas > _______________________________________________ > Openvas-devel mailing list > Openvas-devel at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-devel > From michael.wiegand at intevation.de Tue Sep 23 10:33:28 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Tue, 23 Sep 2008 10:33:28 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <200809230720.18141.marco.fradin@free.fr> References: <200809211059.59443.marco.fradin@free.fr> <200809221057.46882.michael.wiegand@intevation.de> <200809230720.18141.marco.fradin@free.fr> Message-ID: <200809231033.29013.michael.wiegand@intevation.de> Am Dienstag, 23. September 2008 07:20:18 schrieben Sie: > > Could you fix these issues and send me the updated file? > > > > All: If there are no objections, I'd like to commit this translation to > > -trunk as soon as it is done and backport it to the 1-0 branch. > > That was quicker than I thought. > Let me know if you see anything else. Thanks for the quick fix, I have added the french translation to the SVN repository. Thank you for helping! Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kost at linux.hr Tue Sep 23 12:05:43 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Tue, 23 Sep 2008 12:05:43 +0200 Subject: [Openvas-devel] [Fwd: [Openvas-commits] r1377 - in trunk/openvas-plugins: . plugins] Message-ID: <48D8BF77.8010907@linux.hr> Michael, nmap.nasl is not replacement for nmap_tcp_connect. BTW nmap_tcp_connect has best performance (accuracy/speed) regarding all portscanners tested. Note that nmap.nasl is not good in performing port scans directly, but for importing nmap scans into openvas. Why? That I don't repeat - Read here: http://www.nessus.org/documentation/index.php?doc=nmap-usage I would suggest to restore nmap_tcp_connect! -------- Original Message -------- Subject: [Openvas-commits] r1377 - in trunk/openvas-plugins: . plugins Date: Fri, 19 Sep 2008 09:42:23 +0200 (CEST) From: scm-commit at wald.intevation.org Reply-To: openvas-devel at wald.intevation.org To: openvas-commits at wald.intevation.org Author: mwiegand Date: 2008-09-19 09:42:22 +0200 (Fri, 19 Sep 2008) New Revision: 1377 Removed: trunk/openvas-plugins/plugins/nmap_tcp_connect/ Modified: trunk/openvas-plugins/ChangeLog trunk/openvas-plugins/MANIFEST Log: Removed obsolete plugins/nmap_tcp_connect since it has already been superseded by scripts/nmap.nasl and was disabled since the initial SVN revision. Modified: trunk/openvas-plugins/ChangeLog =================================================================== --- trunk/openvas-plugins/ChangeLog 2008-09-18 14:17:04 UTC (rev 1376) +++ trunk/openvas-plugins/ChangeLog 2008-09-19 07:42:22 UTC (rev 1377) @@ -1,3 +1,21 @@ +2008-09-19 Michael Wiegand + + Removed obsolete plugins/nmap_tcp_connect since it has already been + superseded by scripts/nmap.nasl and was disabled since the + initial SVN revision. + + * plugins/nmap_tcp_connect/nmap_tcp_connect.c: Removed. + + * plugins/nmap_tcp_connect/Makefile: Removed. + + * plugins/nmap_tcp_connect/Makefile.darwin: Removed. + + * plugins/nmap_tcp_connect/nmap.h: Removed. + + * plugins/nmap_tcp_connect/: Removed. + + * MANIFEST: Updated. + 2008-09-18 Tim Brown openvas.tmpl.in: Honour LDFLAGS. Modified: trunk/openvas-plugins/MANIFEST =================================================================== --- trunk/openvas-plugins/MANIFEST 2008-09-18 14:17:04 UTC (rev 1376) +++ trunk/openvas-plugins/MANIFEST 2008-09-19 07:42:22 UTC (rev 1377) @@ -43,10 +43,6 @@ plugins/linux_tftp/Makefile plugins/linux_tftp/Makefile.darwin plugins/make_world -plugins/nmap_tcp_connect/Makefile -plugins/nmap_tcp_connect/Makefile.darwin -plugins/nmap_tcp_connect/nmap.h -plugins/nmap_tcp_connect/nmap_tcp_connect.c plugins/nmap_wrapper/Makefile plugins/nmap_wrapper/Makefile.darwin plugins/nmap_wrapper/nmap_wrapper.c _______________________________________________ Openvas-commits mailing list Openvas-commits at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-commits From michael.wiegand at intevation.de Wed Sep 24 08:31:05 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 24 Sep 2008 08:31:05 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <200809231804.58847.marco.fradin@free.fr> References: <200809211059.59443.marco.fradin@free.fr> <200809231033.29013.michael.wiegand@intevation.de> <200809231804.58847.marco.fradin@free.fr> Message-ID: <200809240831.05647.michael.wiegand@intevation.de> Am Dienstag, 23. September 2008 18:04:58 schrieben Sie: > > Thanks for the quick fix, I have added the french translation to the SVN > > repository. Thank you for helping! > > You're welcome. I saw that this morning on the svn repository and ICQ. > What's the next step? Tell me if you want another translation. I was > thinking about the manual... Maybe that's not a priority for your project? On the contrary, I think this is a great idea! We are working on the English version of the compendium right now and there are still some things that will change in the compendium until the next release. It would probably be a good idea to wait a little bit until the compendium has become stable so your translations don't become obsolete once the compendium is done. This should happen in the next few weeks. We will be working on a German translation of the compendium as well once the original is done, so it would be great to have a French one available as well. OpenVAS-Client is the only component right now where translations are available, there might be a few changes in the translation strings for the upcoming 2.0 release, but from what I have seen that shouldn't be hard for you. :) So it is your decision if you want to start working on the compendium now or if you would rather wait until the next release. The compendium is written in LaTeX with hyperlatex extensions; let me know if you need any pointers for editing that. One more thing: Could you please CC: openvas-devel at wald.intevation.org in your mails? There are a lot of people on the list who might be able to help or support you or who spot things that I might overlook. :) Thanks again for your efforts, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From michael.wiegand at intevation.de Wed Sep 24 09:25:48 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 24 Sep 2008 09:25:48 +0200 Subject: [Openvas-devel] [Fwd: [Openvas-commits] r1377 - in trunk/openvas-plugins: . plugins] In-Reply-To: <48D8BF77.8010907@linux.hr> References: <48D8BF77.8010907@linux.hr> Message-ID: <200809240925.48760.michael.wiegand@intevation.de> [Tuesday 23 September 2008 - 12:05:43] Vlatko Kosturjak : > nmap.nasl is not replacement for nmap_tcp_connect. BTW nmap_tcp_connect > has best performance (accuracy/speed) regarding all portscanners tested. > > Note that nmap.nasl is not good in performing port scans directly, but > for importing nmap scans into openvas. > Why? That I don't repeat - Read here: > http://www.nessus.org/documentation/index.php?doc=nmap-usage > > I would suggest to restore nmap_tcp_connect! Just to clarify: It was nmap_tcp_connect that was removed, *not* nmap_wrapper. The functionality provided by nmap_wrapper (namely nmap scans) still remains, it was just the inactive functionality provided by nmap_tcp_connect that had already be incorporated into nmap.nasl (according to chandra) and was now redundant there. This means no actual functionality was removed; unless we are planning on restoring the functionality provided by nmap_tcp_connect as a .c plugin, I would suggest that nmap_tcp_connect can safely be removed. Is this okay with you? Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Wed Sep 24 09:45:59 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 24 Sep 2008 09:45:59 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <200809240831.05647.michael.wiegand@intevation.de> References: <200809211059.59443.marco.fradin@free.fr> <200809231804.58847.marco.fradin@free.fr> <200809240831.05647.michael.wiegand@intevation.de> Message-ID: <200809240946.02608.jan-oliver.wagner@intevation.de> On Mittwoch, 24. September 2008, Michael Wiegand wrote: > Am Dienstag, 23. September 2008 18:04:58 schrieben Sie: > > You're welcome. I saw that this morning on the svn repository and ICQ. > > What's the next step? Tell me if you want another translation. I was > > thinking about the manual... Maybe that's not a priority for your project? > > On the contrary, I think this is a great idea! > > We are working on the English version of the compendium right now and there > are still some things that will change in the compendium until the next > release. It would probably be a good idea to wait a little bit until the > compendium has become stable so your translations don't become obsolete once > the compendium is done. This should happen in the next few weeks. > > We will be working on a German translation of the compendium as well once the > original is done, so it would be great to have a French one available as > well. I even suggest to start right away: Chapter "Using OpenVAS-Client" will not undergo much changes anymore. This could be a nice start. We will do so for the german translation right away in the next couple of days ... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Wed Sep 24 09:54:14 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Wed, 24 Sep 2008 09:54:14 +0200 Subject: [Openvas-devel] Open full time position for OpenVAS developments Message-ID: <200809240954.16812.jan-oliver.wagner@intevation.de> Hello, OpenVAS is developing at a fantastic speed. To further accelerate this success story, we are looking for additional staff for working on the OpenVAS framework full time, long time and asap :-) All the best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From marco.fradin at free.fr Wed Sep 24 11:26:48 2008 From: marco.fradin at free.fr (marco.fradin@free.fr) Date: Wed, 24 Sep 2008 11:26:48 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <200809240946.02608.jan-oliver.wagner@intevation.de> References: <200809211059.59443.marco.fradin@free.fr> <200809231804.58847.marco.fradin@free.fr> <200809240831.05647.michael.wiegand@intevation.de> <200809240946.02608.jan-oliver.wagner@intevation.de> Message-ID: <1222248408.48da07d82518c@imp.free.fr> Ok, I saw it was hyperlatex yesterday. What's your tool? I tried kile with no great success, maybe LyX or Texmaker are better... Kate may be the best! Free the GNU Marco (sitepamarco) Selon Jan-Oliver Wagner : > On Mittwoch, 24. September 2008, Michael Wiegand wrote: > > Am Dienstag, 23. September 2008 18:04:58 schrieben Sie: > > > You're welcome. I saw that this morning on the svn repository and ICQ. > > > What's the next step? Tell me if you want another translation. I was > > > thinking about the manual... Maybe that's not a priority for your > project? > > > > On the contrary, I think this is a great idea! > > > > We are working on the English version of the compendium right now and there > > are still some things that will change in the compendium until the next > > release. It would probably be a good idea to wait a little bit until the > > compendium has become stable so your translations don't become obsolete > once > > the compendium is done. This should happen in the next few weeks. > > > > We will be working on a German translation of the compendium as well once > the > > original is done, so it would be great to have a French one available as > > well. > > I even suggest to start right away: Chapter "Using OpenVAS-Client" will > not undergo much changes anymore. This could be a nice start. > We will do so for the german translation right away in the next couple of > days ... > > Best > > Jan > > -- > Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck > Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > From michael.wiegand at intevation.de Wed Sep 24 12:14:25 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 24 Sep 2008 12:14:25 +0200 Subject: [Openvas-devel] OpenVAS-Client french translation In-Reply-To: <1222248408.48da07d82518c@imp.free.fr> References: <200809211059.59443.marco.fradin@free.fr> <200809240946.02608.jan-oliver.wagner@intevation.de> <1222248408.48da07d82518c@imp.free.fr> Message-ID: <200809241214.26062.michael.wiegand@intevation.de> [Wednesday 24 September 2008 - 11:26:48] marco.fradin at free.fr: > Ok, I saw it was hyperlatex yesterday. What's your tool? I tried kile with > no great success, maybe LyX or Texmaker are better... Kate may be the best! I'm working with kile myself, so maybe I am able to help you there. The only issue I had with kile so far is that the "LaTeX" Button fails with a fresh checkout since the eps versions of the images are not in der SVN, but are generated on demand from the png files. A "make dvi" will generate the images needed, the "LaTeX" button should work now. Does that solve your problem? Regards, Michael -- Michael Wiegand OpenPGP key: D7D049EC Intevation GmbH, Osnabr?ck http://www.intevation.de/ Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From marco.fradin at free.fr Thu Sep 25 10:26:09 2008 From: marco.fradin at free.fr (marco.fradin@free.fr) Date: Thu, 25 Sep 2008 10:26:09 +0200 Subject: [Openvas-devel] Compendium Message-ID: <1222331169.48db4b21e2d9c@imp.free.fr> Hi ladies & gentlemen French translation of the compendium has just started under Kile (it works fine now) but that's not the subject. I read the compendium and maybe this will interest you, about openvasd service under fedora for instance. This is what I made for a FC6 : - modify tne original nessus script, name it openvasd (see enclosed), install /etc/init.d/openvasd - tests : * /etc/init.d/openvasd status * /etc/init.d/openvasd start * /etc/init.d/openvasd status * /etc/init.d/openvasd restart - add automatically the service for the different runlevels : chkconfig --add openvasd - Put it on : chkconfig openvasd on - test : service openvasd restart Maybe you've already thought about this, maybe it's an idea to add it in the compendium... It's up to you. Marco (sitepamarco) From marco.fradin at free.fr Thu Sep 25 11:06:13 2008 From: marco.fradin at free.fr (marco.fradin@free.fr) Date: Thu, 25 Sep 2008 11:06:13 +0200 Subject: [Openvas-devel] Trans.: Compendium Message-ID: <1222333573.48db5485b409b@imp.free.fr> Sorry, I forgot the script. ----- Message transf?r? de marco.fradin at free.fr ----- Date?: Thu, 25 Sep 2008 10:26:09 +0200 De?: marco.fradin at free.fr Adresse de retour?:marco.fradin at free.fr Sujet?: Compendium ??: openvas-devel at wald.intevation.org Hi ladies & gentlemen French translation of the compendium has just started under Kile (it works fine now) but that's not the subject. I read the compendium and maybe this will interest you, about openvasd service under fedora for instance. This is what I made for a FC6 : - modify tne original nessus script, name it openvasd (see enclosed), install /etc/init.d/openvasd - tests : * /etc/init.d/openvasd status * /etc/init.d/openvasd start * /etc/init.d/openvasd status * /etc/init.d/openvasd restart - add automatically the service for the different runlevels : chkconfig --add openvasd - Put it on : chkconfig openvasd on - test : service openvasd restart Maybe you've already thought about this, maybe it's an idea to add it in the compendium... It's up to you. Marco (sitepamarco) ----- Fin du message transf?r? ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: openvasd Type: application/octet-stream Size: 1377 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080925/8002bfc5/openvasd.obj From jan-oliver.wagner at intevation.de Thu Sep 25 21:08:24 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 25 Sep 2008 21:08:24 +0200 Subject: [Openvas-devel] start-stop daemon In-Reply-To: <1222331169.48db4b21e2d9c@imp.free.fr> References: <1222331169.48db4b21e2d9c@imp.free.fr> Message-ID: <200809252108.28793.jan-oliver.wagner@intevation.de> Hello Marco, On Thursday 25 September 2008 10:26, marco.fradin at free.fr wrote: > French translation of the compendium has just started under Kile (it works > fine now) but that's not the subject. it was. I changed it :-) > I read the compendium and maybe this will interest you, about openvasd > service under fedora for instance. > This is what I made for a FC6 : > - modify tne original nessus script, name it openvasd (see enclosed), > install /etc/init.d/openvasd > - tests : > * /etc/init.d/openvasd status > * /etc/init.d/openvasd start > * /etc/init.d/openvasd status > * /etc/init.d/openvasd restart > - add automatically the service for the different runlevels : > chkconfig --add openvasd > - Put it on : > chkconfig openvasd on > - test : > service openvasd restart > > Maybe you've already thought about this, maybe it's an idea to add it in > the compendium... It's up to you. you important email reminds me that we were still lacking the start-stop daemon. We should not just add information on it into the openvas-compendium, we should add the start-stop daemon to openvas-server! Of course we should abstract to a .in file to allow for different prefixes. Any takers? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Thu Sep 25 22:26:49 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 25 Sep 2008 22:26:49 +0200 Subject: [Openvas-devel] Planning 1.0-rc1 of OpenVAS Compendium Message-ID: <200809252226.51717.jan-oliver.wagner@intevation.de> Hi, except for a small update for the installation routine and some hints on the 2.0 series, I consider the OpenVAS compendium ready for the 1.0 release. If anyone thinks there a major parts missing or you like to do some proof-reading, please let me know. However, it is clear that the compendium will be an ongoing efford. But we need a point where we can do releases and e.g. create translations (Michael and myself will take care for the german translation). Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From marco.fradin at free.fr Fri Sep 26 21:07:43 2008 From: marco.fradin at free.fr (marco) Date: Fri, 26 Sep 2008 21:07:43 +0200 Subject: [Openvas-devel] start-stop daemon In-Reply-To: <200809252108.28793.jan-oliver.wagner@intevation.de> References: <1222331169.48db4b21e2d9c@imp.free.fr> <200809252108.28793.jan-oliver.wagner@intevation.de> Message-ID: <200809262107.44245.marco.fradin@free.fr> Hi ladies and gentlemen, An answer to Machine and "I don't remember who talks about this on IRC because tonight intevation's internet service is temporarily unavailable" ;-). On debian Ubuntu (8.04 Hardy) for instance : - make a /etc/init.d/openvasd or something like that -there's an example /etc/init.d/skeleton- (it's certainly already done for Ubuntu 8.10 Intrepid) - to automatically create the links in the different runlevels : # update-rc.d openvasd defaults - start the service : # /etc/init.d/openvasd start Maybe it's an idea to let each distro team do this, maybe it's good to write it in the compendium for those who compile from the source, maybe there's a way to "alienize" (see alien http://linux.die.net/man/1/alien), it's up to you. Sorry to everyone, I should have told you that I know Fedora, Ubuntu, RedHawk... Actually on this one, Kubuntu realtime 64 bit : Linux TUX-II-RELOAD 2.6.24-19-rt #1 SMP PREEMPT RT Wed Aug 20 20:13:12 UTC 2008 x86_64 GNU/Linux Be strong, Marco (sitepamarco) Le Thursday 25 September 2008 21:08:24 Jan-Oliver Wagner, vous avez ?crit?: > Hello Marco, > > On Thursday 25 September 2008 10:26, marco.fradin at free.fr wrote: > > French translation of the compendium has just started under Kile (it > > works fine now) but that's not the subject. > > it was. I changed it :-) > > > I read the compendium and maybe this will interest you, about openvasd > > service under fedora for instance. > > This is what I made for a FC6 : > > - modify tne original nessus script, name it openvasd (see enclosed), > > install /etc/init.d/openvasd > > - tests : > > * /etc/init.d/openvasd status > > * /etc/init.d/openvasd start > > * /etc/init.d/openvasd status > > * /etc/init.d/openvasd restart > > - add automatically the service for the different runlevels : > > chkconfig --add openvasd > > - Put it on : > > chkconfig openvasd on > > - test : > > service openvasd restart > > > > Maybe you've already thought about this, maybe it's an idea to add it in > > the compendium... It's up to you. > > you important email reminds me that we were still lacking the start-stop > daemon. > > We should not just add information on it into the openvas-compendium, > we should add the start-stop daemon to openvas-server! > > Of course we should abstract to a .in file to allow for different prefixes. > > Any takers? > > Best > > Jan From jan-oliver.wagner at intevation.de Mon Sep 29 11:19:46 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 29 Sep 2008 11:19:46 +0200 Subject: [Openvas-devel] start-stop daemon In-Reply-To: <200809262107.44245.marco.fradin@free.fr> References: <1222331169.48db4b21e2d9c@imp.free.fr> <200809252108.28793.jan-oliver.wagner@intevation.de> <200809262107.44245.marco.fradin@free.fr> Message-ID: <200809291119.50760.jan-oliver.wagner@intevation.de> On Freitag, 26. September 2008, marco wrote: > Maybe it's an idea to let each distro team do this, maybe it's good to write > it in the compendium for those who compile from the source, maybe there's a > way to "alienize" (see alien http://linux.die.net/man/1/alien), it's up to > you. I've learned that the start-stop daemons differ too much for several operating systems. Thus it might be best if we create a "tools" directory in openvas-server and there add the scripts with sensible names so that the users can select the right one for their purposes. Then we can also add a section into the compendium and provide a guide. Comments? Should we go this way? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From timb at nth-dimension.org.uk Mon Sep 29 11:25:46 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 29 Sep 2008 10:25:46 +0100 Subject: [Openvas-devel] start-stop daemon In-Reply-To: <200809291119.50760.jan-oliver.wagner@intevation.de> References: <1222331169.48db4b21e2d9c@imp.free.fr> <200809262107.44245.marco.fradin@free.fr> <200809291119.50760.jan-oliver.wagner@intevation.de> Message-ID: <200809291025.47047.timb@nth-dimension.org.uk> On Monday 29 September 2008 10:19:46 Jan-Oliver Wagner wrote: > I've learned that the start-stop daemons differ too much for several > operating systems. > Thus it might be best if we create a "tools" directory in openvas-server > and there add the scripts with sensible names so that the users > can select the right one for their purposes. > Then we can also add a section into the compendium and provide > a guide. They generallly need to go in a location specific to the packaging format, for example for Debian and derivatives, it is under packaging/debian/openvas-server. Cheers, Tim -- Tim Brown From c_edjenguele at yahoo.it Mon Sep 29 11:39:10 2008 From: c_edjenguele at yahoo.it (Christian Eric EDJENGUELE) Date: Mon, 29 Sep 2008 09:39:10 +0000 (GMT) Subject: [Openvas-devel] start-stop daemon Message-ID: <855595.25182.qm@web26006.mail.ukl.yahoo.com> yes in fact depends whatever the system uses bsd-style (master configuration file /etc/rc.conf, the script are store in /etc/rc.d directory... )or Sys-V init script (is the traditional init system under Linux. It has the central configuration file /etc/inittab. Sys-V-Init distinguishs between different system status, the so called "`runlevels"' /etc/rc.2/ for run level 2?and so on...) ?--- Christian Eric Edjenguele IT Security Software Developer & Researcher tel. +39 3408580513 View my linkedin profile: http://www.linkedin.com/in/edjenguele My blog: http://www.edjenguele.blogspot.com ----- Messaggio originale ----- Da: Jan-Oliver Wagner A: openvas-devel at wald.intevation.org Inviato: Luned? 29 settembre 2008, 11:19:46 Oggetto: Re: [Openvas-devel] start-stop daemon On Freitag, 26. September 2008, marco wrote: > Maybe it's an idea to let each distro team do this, maybe it's good to write > it in the compendium for those who compile from the source, maybe there's a > way to "alienize" (see alien http://linux.die.net/man/1/alien), it's up to > you. I've learned that the start-stop daemons differ too much for several operating systems. Thus it might be best if we create a "tools" directory in openvas-server and there add the scripts with sensible names so that the users can select the right one for their purposes. Then we can also add a section into the compendium and provide a guide. Comments? Should we go this way? Best ??? Jan -- Dr. Jan-Oliver Wagner? ? ? ? ? ? ? ? ? ? ? ? Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998? ? ? ? ? ? http://www.intevation.de/ 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 __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From jan-oliver.wagner at intevation.de Mon Sep 29 12:04:42 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 29 Sep 2008 12:04:42 +0200 Subject: [Openvas-devel] start-stop daemon In-Reply-To: <200809291025.47047.timb@nth-dimension.org.uk> References: <1222331169.48db4b21e2d9c@imp.free.fr> <200809291119.50760.jan-oliver.wagner@intevation.de> <200809291025.47047.timb@nth-dimension.org.uk> Message-ID: <200809291204.45796.jan-oliver.wagner@intevation.de> On Montag, 29. September 2008, Tim Brown wrote: > On Monday 29 September 2008 10:19:46 Jan-Oliver Wagner wrote: > > > I've learned that the start-stop daemons differ too much for several > > operating systems. > > Thus it might be best if we create a "tools" directory in openvas-server > > and there add the scripts with sensible names so that the users > > can select the right one for their purposes. > > Then we can also add a section into the compendium and provide > > a guide. > > They generallly need to go in a location specific to the packaging format, for > example for Debian and derivatives, it is under > packaging/debian/openvas-server. This is also an option. I leave it to the people who care for these scripts to place them where it makes most sense. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From timb at nth-dimension.org.uk Mon Sep 29 13:24:58 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Mon, 29 Sep 2008 12:24:58 +0100 Subject: [Openvas-devel] Symlink attacks against fwrite/fread/file_open functions Message-ID: <200809291224.58595.timb@nth-dimension.org.uk> Whilst having a look at Vlatko's locking code for ike-scan.nasl I realised that there is a problem in how the fwrite, fread and file_open NASL functions (and quite possibly others) behave. Because they simply open the requested file without any checks, it is possible to carry out symlink attacks against these functions. I have attached a patch which should I believe resolve the issue but I welcome comments before I commit as to whether a) it resolves the issue correctly and b) whether it will have unwanted side effects. Cheers, Tim -- Tim Brown -------------- next part -------------- A non-text attachment was scrubbed... Name: symlink-fix.diff Type: text/x-diff Size: 4746 bytes Desc: not available Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080929/7ad56b61/symlink-fix.bin