From goran.licina at lss.hr  Sat Aug  1 14:03:19 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Sat, 1 Aug 2009 14:03:19 +0200
Subject: [Openvas-plugins] macosx_version.nasl
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE31D@vlasta.lss-net.lss.hr>
	<4A735AE3.80106@securityspace.com>
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE343@vlasta.lss-net.lss.hr>

Hi, Thomas!

> -----Original Message-----
> From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-
> plugins-bounces at wald.intevation.org] On Behalf Of Thomas Reinke
> Sent: Friday, July 31, 2009 10:58 PM
> To: openvas-plugins at wald.intevation.org
> Subject: Re: [Openvas-plugins] macosx_version.nasl
> 
> The only thing that catches my attention above is the dynamic nature of
> the "rls" value set into the kb.  While the above is simple and clean
> in
> that it probably catches ALL possible release values, it reports
> successful login and detection across all release variables, even if
> one
> is found that is unsupported
> 
> Then there's the fact because we don't control the value, if some
> sort of point value system is added into the release number, it will
> break local security checks that are hardcoded to referencing something
> similar. An example is debian - the release file might indicate
> rls "5.0" or "5.0.2", but both are "DEB5.0" from the perspective of
> all of the local security checks.
> 
> I'd suggest a specific check for the release numbers within a known
> set of "legitimate" values that we support as per the local security
> checks that use the value, and only set the kb and generate the note
> if the rls value falls within that legitimate set.
> 

Thanks for you suggestions.

We think we should support version format 10.X.Y for our plugins (at least
macosx_version.nasl plugin uses this format) where X is major release and
Y are minor releases. Here is our solution:

if ("Darwin" >< uname)
{
     rls = ssh_cmd(socket:sock, cmd:"cat -v -t /System/Library/ CoreServices/SystemVersion.plist | egrep '10' | tail -n 1 | sed  s/'\^I<string>'// | sed s/'<\/string>'//");
     if (eregmatch(string:rls, pattern:"10\.[0-9]+\.[0-9]+", icase:1)  == TRUE) {
	rls = "Mac OS X "+rls;
     	set_kb_item(name: "ssh/login/release", value:rls);
     	security_note(data:string("We are able to login and detect that you are running ", rls));
     	}
     exit(0);	
}

Any comments?

Regards,

Goran

From goran.licina at lss.hr  Sun Aug  2 15:25:37 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Sun, 2 Aug 2009 15:25:37 +0200
Subject: [Openvas-plugins] Work on missing deps
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE345@vlasta.lss-net.lss.hr>

Hi!

Just for info, we are working on following plugins:

ms_telnet_overflow.nasl 
xoops_detect.nasl
photopost_detect.nasl

These are resolving unmet dependencies for:

xoops_myheader_url_xss.nasl
xoops_viewtopic_xss.nasl
photopost_sql_injection.nasl

Please inform us if someone is already working on these, 
or functionalities these plugins provide are already
done in some other plugin we didn't notice.

Thanks.

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb

From bchandra at secpod.com  Mon Aug  3 06:47:11 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Mon, 3 Aug 2009 10:17:11 +0530
Subject: [Openvas-plugins] Work on missing deps
In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C0EE345@vlasta.lss-net.lss.hr>
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE345@vlasta.lss-net.lss.hr>
Message-ID: <8B4677FF062746A1BFB5F320D6EF6CB9@bchandra>

Hello Goran,

We have just started on xoops_detect.nasl. If you haven't already started on
that, we'll complete that. The rest are fine. 

Thanks,
Chandra. 


-----Original Message-----
From: openvas-plugins-bounces at wald.intevation.org
[mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Goran
Licina
Sent: Sunday, August 02, 2009 6:56 PM
To: openvas-plugins at wald.intevation.org
Subject: [Openvas-plugins] Work on missing deps

Hi!

Just for info, we are working on following plugins:

ms_telnet_overflow.nasl 
xoops_detect.nasl
photopost_detect.nasl

These are resolving unmet dependencies for:

xoops_myheader_url_xss.nasl
xoops_viewtopic_xss.nasl
photopost_sql_injection.nasl

Please inform us if someone is already working on these, 
or functionalities these plugins provide are already
done in some other plugin we didn't notice.

Thanks.

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb
_______________________________________________
Openvas-plugins mailing list
Openvas-plugins at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins


From goran.licina at lss.hr  Mon Aug  3 10:49:39 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Mon, 3 Aug 2009 10:49:39 +0200
Subject: [Openvas-plugins] Work on missing deps
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE345@vlasta.lss-net.lss.hr>
	<8B4677FF062746A1BFB5F320D6EF6CB9@bchandra>
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE352@vlasta.lss-net.lss.hr>

Hi Chandra!

> -----Original Message-----
> From: Chandrashekhar B [mailto:bchandra at secpod.com]
> Sent: Monday, August 03, 2009 6:47 AM
> To: Goran Li?ina; openvas-plugins at wald.intevation.org
> Subject: RE: [Openvas-plugins] Work on missing deps
> 
> Hello Goran,
> 
> We have just started on xoops_detect.nasl. If you haven't already
> started on
> that, we'll complete that. The rest are fine.

Ok. We'll work on webapp_detect.nasl instead.

Regards,

Goran

From Jan-Oliver.Wagner at greenbone.net  Fri Aug  7 14:25:33 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Fri, 7 Aug 2009 14:25:33 +0200
Subject: [Openvas-plugins] Missing deps and missing incs: Streamlining and
	pushing effords
Message-ID: <200908071425.33975.Jan-Oliver.Wagner@greenbone.net>

Hi,

many missing depedencies and missing include files
have been resolved already, but still a number of issues are open.

I'd like to have this a bit steamlined and pushed with
the following ideas. Please let me know what you think.
Also, it would be great to have a volunteer to take
care of the coordination of this task. Anyone willing
to spend time until the last missing NASL is resolved?
(the coordinator should also take care of high quality
resolving, ie. that no functionality is lost or rationale/explanation
is provided in case functionality is dropped).

* the status of missing-deps.txt, missing-deps-per-file.txt
   and missing-deps-most-wanted.txt
    needs to be updated.

* it would be cool to have a file "missing_nasl.txt" similar to
   "cve_current.txt" that lists any missing dependency and
   missing include where people can add their name to state
   they work on it. The rest is marked "looking for a developer to take".
 
* Some scripts have dependencies to a number of vendor specific
   issues (eg. for many macosx, for many solaris, for several redhat).
   I really wonder why this need to be this way. An analysis would be
   appreciated. Too me it looks like a broken concept.

* Our top most wanted dep is webmirror.nasl.
   I've seen GPL ones in old GPL feed tar balls.

All the best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck
AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver 
Wagner

From goran.licina at lss.hr  Fri Aug  7 23:38:32 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Fri, 7 Aug 2009 23:38:32 +0200
Subject: [Openvas-plugins] macosx_version.nasl
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE31D@vlasta.lss-net.lss.hr><4A735AE3.80106@securityspace.com>
	<8A02A3DF683DEE42BE73187F4CA4444C0EE343@vlasta.lss-net.lss.hr>
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE39E@vlasta.lss-net.lss.hr>

> Thanks for you suggestions.
> 
> We think we should support version format 10.X.Y for our plugins (at
> least
> macosx_version.nasl plugin uses this format) where X is major release
> and
> Y are minor releases. Here is our solution:
> 
> if ("Darwin" >< uname)
> {
>      rls = ssh_cmd(socket:sock, cmd:"cat -v -t /System/Library/
> CoreServices/SystemVersion.plist | egrep '10' | tail -n 1 | sed
> s/'\^I<string>'// | sed s/'<\/string>'//");
>      if (eregmatch(string:rls, pattern:"10\.[0-9]+\.[0-9]+", icase:1)
> == TRUE) {
> 	rls = "Mac OS X "+rls;
>      	set_kb_item(name: "ssh/login/release", value:rls);
>      	security_note(data:string("We are able to login and detect that
> you are running ", rls));
>      	}
>      exit(0);
> }
> 
> Any comments?
> 
> Regards,
> 
> Goran

Hi!

We didn't get any feedback on this subject. Is there anything more we should correct
or is this solution fine?

Best regards,

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb



From lists at securityspace.com  Sat Aug  8 00:06:39 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Fri, 07 Aug 2009 18:06:39 -0400
Subject: [Openvas-plugins] macosx_version.nasl
In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C0EE39E@vlasta.lss-net.lss.hr>
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE31D@vlasta.lss-net.lss.hr><4A735AE3.80106@securityspace.com>
	<8A02A3DF683DEE42BE73187F4CA4444C0EE343@vlasta.lss-net.lss.hr>
	<8A02A3DF683DEE42BE73187F4CA4444C0EE39E@vlasta.lss-net.lss.hr>
Message-ID: <4A7CA56F.6030809@securityspace.com>

Sorry for the non-responsiveness.  I've taken a look at some
old macosx tests we have access to and how the updates are
applicable to different release numbers.  What you have
here is fine.

Thomas

Goran Li?ina wrote:
>> Thanks for you suggestions.
>>
>> We think we should support version format 10.X.Y for our plugins (at
>> least
>> macosx_version.nasl plugin uses this format) where X is major release
>> and
>> Y are minor releases. Here is our solution:
>>
>> if ("Darwin" >< uname)
>> {
>>      rls = ssh_cmd(socket:sock, cmd:"cat -v -t /System/Library/
>> CoreServices/SystemVersion.plist | egrep '10' | tail -n 1 | sed
>> s/'\^I<string>'// | sed s/'<\/string>'//");
>>      if (eregmatch(string:rls, pattern:"10\.[0-9]+\.[0-9]+", icase:1)
>> == TRUE) {
>> 	rls = "Mac OS X "+rls;
>>      	set_kb_item(name: "ssh/login/release", value:rls);
>>      	security_note(data:string("We are able to login and detect that
>> you are running ", rls));
>>      	}
>>      exit(0);
>> }
>>
>> Any comments?
>>
>> Regards,
>>
>> Goran
> 
> Hi!
> 
> We didn't get any feedback on this subject. Is there anything more we should correct
> or is this solution fine?
> 
> Best regards,
> 
> Goran Licina
> --
> Laboratory for Systems and Signals
> Department of Electronic Systems and Information Processing
> Faculty of Electrical Engineering and Computing
> University of Zagreb
> 
> 


From jan-oliver.wagner at intevation.de  Mon Aug 10 12:45:19 2009
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Mon, 10 Aug 2009 12:45:19 +0200
Subject: [Openvas-plugins] toolcheck NASL script: please test
Message-ID: <200908101245.19303.jan-oliver.wagner@intevation.de>

Hi,

we've written a small NASL script that looks for
presence of scanner tools.
The idea is to have
* a summary on missing installed tools
* the ability to not start scripts that would cause
   errors anyway (via mandatory_keys).

Please try it out and let us know.
If OK, I will commit it to SVN and will make
the script part of the Feed.

All the best

Jan

-- 
Dr. Jan-Oliver Wagner | ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
# OpenVAS Vulnerability Test
# $Id$
# Description: Initializing routine for checking presence of helper tools
#
# Authors:
# Jan-Oliver Wagner <Jan-Oliver.Wagner at greenbone.net>
# Felix Wolfsteller <felix.wolfsteller at intevation.de>
#
# Copyright:
# Copyright (c) 2009 Greenbone Networks GmbH, http://www.greenbone.net
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2
# (or any later version), as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
#

if(description)
{
 script_id(810000);
 script_version("$Revision$");

 script_name("Availability of scanner helper tools");

 desc = "
This routine checks for the presence of various tools that
support the scan engine and also tests the version of the scan
engine itself. If some tools are not accessible for the
scan engine, one or more NVTs could not be executed properly.

The consequence might be that certain vulnerabilities are missed
because respective tests are not performed.
";

 script_description(desc);

 script_summary("Check for presence of tools that support scanning");

 script_category(ACT_INIT);

 script_copyright("Copyright (C) 2009 Greenbone Networks GmbH");
 script_family("General");

 script_add_preference(name:"Perform tool check", type:"checkbox", value:"yes");

 exit(0);
}

# Silent exit if no check to perform
perform_check = script_get_preference("Perform tool check");
if (perform_check == "no")
  exit(0);

include ("version_func.inc");

all_tools_available = TRUE;

summary = "
The following tools are not accessible for the scan server.
Please contact the responsible administrator for the
OpenVAS scan engine to make the missing tool(s) available.
";

#
# Test for presence of supported stable OpenVAS Scan Server
#

# Attention: NESSUS_VERSION is the NASL library version, not the server version

# TODO: Replace NESSUS_VERSION by OPENVAS_SCANSERVER_VERSION once 2.0 is retired
if (!version_is_greater_equal(version: NESSUS_VERSION, test_version: "1.0.0")){
  summary = summary + "
Tool:   OpenVAS Scan Server 1.0.x
Effect: You are not using a supported stable version of OpenVAS Scan Server.
        It is highly recommended to upgrade your server installation!
        NVTs might fail to execute partially or even entirely. This
        could even happend without further notice and it could happen
        for a large number of NVTs.
";
  all_tools_available = FALSE;
}

#
# Test for presence of current stable OpenVAS Scan Server
#

# TODO: Replace NESSUS_VERSION by OPENVAS_SCANSERVER_VERSION once 2.0 is retired
if (!version_is_greater_equal(version: NESSUS_VERSION, test_version: "2.0.0")){
  summary = summary + "
Tool:   OpenVAS Scan Server 2.0.x
Effect: You are not using the current stable version of OpenVAS Scan Server.
        It is highly suggested to upgrade your server installation.
        Some NVTs will report warnings into server log files.
";
  all_tools_available = FALSE;
}

#
# Test for presence of latest current stable OpenVAS Scan Server
#

# TODO: Activate this once anything older than 2.0.3 is retired
# and replace X.Y.Z with latest version
# The reason that this is deactivated for the time being is that
# NESSUS_VERSION returns the version of openvas-libnasl, not of
# openvas-server.
#if (!version_is_greater_equal(version: OPENVAS_SCANSERVER_VERSION, test_version: "X.Y.Z")){
#  summary = summary + "
#Tool:   OpenVAS Scan Server X.Y.Z
#Effect: You are not using the very latest stable version of OpenVAS Scan Server.
#        The very latest release might have fixed bugs or in other ways
#        been improved.
#        It is suggested to upgrade your server installation.
#";
#  all_tools_available = FALSE;
#}

#
# Test for presence of Nmap
#

if ( find_in_path("nmap") ){
  set_kb_item(name: "Tools/Present/nmap", value: TRUE);
} else {
  set_kb_item(name: "Tools/Missing/nmap", value: TRUE);
  summary = summary + "
Tool:   nmap
Effect: Port scanning with nmap will not be available
        in the port scanners selection.
";
  all_tools_available = FALSE;
}

#
# Test for presence of Ovaldi
#

sufficient_openvas_found = FALSE;
sufficient_ovaldi_found = FALSE;

# First test for the minimum OpenVAS Scan Server release.
# For older releases, OVAL support won't work nicely anyway.
# The whole test for minimum openvas version can be removed
# once OpenVAS 2.0 is deprecated.

# TODO: Replace NESSUS_VERSION by OPENVAS_SCANSERVER_VERSION once 2.0 is retired
# Note: this is a trick. Actually 2.0.2 is the libnasl version.
# Thus in case someone installed this libnasl, but NOT the openvas-server 2.0.3
# it will lead to false assumption of presence of sufficient server.
# However, this is unlikely to happen.
if (version_is_greater_equal(version: NESSUS_VERSION, test_version: "2.0.2")){
  sufficient_openvas_found = TRUE;
}

if (find_in_path("ovaldi")){
  ovaldi_out = pread(cmd: "ovaldi", argv: make_list("ovaldi", "-h"));
  foreach line(split(ovaldi_out)){
    v = eregmatch(string: line, pattern: 'Version: ([0-9.]*) Build: ([0-9.]*)');
    if (! isnull(v)){
      found_version = v[1] + '.';
      found_version = found_version + v[2];
      summary = summary + found_version;
      if (version_is_greater_equal (version:found_version,
                                    test_version: "5.5.23")){
        set_kb_item(name: "Tools/Present/ovaldi", value: TRUE);
        sufficient_ovaldi_found = TRUE;
        break;
      }
    }
  }
}


#
# Attention, the order of the next two checks is imporant.
# By setting "Tools/(Missing|Present)/ovaldi", we pretend a missing ovaldi in
# case of an openvas server that does not support oval nicely (enough)!
#
if (!sufficient_ovaldi_found) {
  set_kb_item(name: "Tools/Missing/ovaldi", value: TRUE);
  set_kb_item(name: "Tools/Present/ovaldi", value: FALSE);
  summary = summary + "
Tool:   ovaldi 5.5.23 or newer
Effect: No NVTs of family 'OVAL definitions' will be executed.
        This family is only visible in case your installation
        includes OVAL files.
";
  all_tools_available = FALSE;
}
# Attention, see note above
if (!sufficient_openvas_found) {
  set_kb_item(name: "Tools/Missing/ovaldi", value: TRUE);
  set_kb_item(name: "Tools/Present/ovaldi", value: FALSE);
  summary = summary + "
Tool:   OpenVAS Scan Server 2.0.3 or newer
Effect: No NVTs of family 'OVAL definitions' will be executed.
        This family is only visible in case your installation
        includes OVAL files and a sufficiently new version of
        the tool ovaldi is installed.
";
}

#
# Send final summary as log information
#

if (all_tools_available == FALSE)
  log_message(port: 0, data: summary);
else
  log_message(port: 0, data: "
All checks for presense of scanner tools were successful.
This means they are found and are sufficiently up-to-date.");

exit(0);

From goran.licina at lss.hr  Fri Aug 14 10:30:15 2009
From: goran.licina at lss.hr (Goran Licina)
Date: Fri, 14 Aug 2009 10:30:15 +0200
Subject: [Openvas-plugins] Work on missing deps
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE345@vlasta.lss-net.lss.hr>
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0394DA@vlasta.lss-net.lss.hr>

Hi!

Also working on smb_nativelanman.nasl (resolving unmet dependency for
samba_arbitrary_file_access.nasl).

Regards,

Goran Licina

-----Original Message-----
From: openvas-plugins-bounces at wald.intevation.org on behalf of Goran Licina
Sent: Sun 02/08/2009 15:25
To: openvas-plugins at wald.intevation.org
Subject: [Openvas-plugins] Work on missing deps
 
Hi!

Just for info, we are working on following plugins:

ms_telnet_overflow.nasl 
xoops_detect.nasl
photopost_detect.nasl

These are resolving unmet dependencies for:

xoops_myheader_url_xss.nasl
xoops_viewtopic_xss.nasl
photopost_sql_injection.nasl

Please inform us if someone is already working on these, 
or functionalities these plugins provide are already
done in some other plugin we didn't notice.

Thanks.

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb
_______________________________________________
Openvas-plugins mailing list
Openvas-plugins at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090814/824c1080/attachment.html

From Jan-Oliver.Wagner at greenbone.net  Mon Aug 17 09:06:48 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Mon, 17 Aug 2009 09:06:48 +0200
Subject: [Openvas-plugins] toolcheck NASL script: please test
In-Reply-To: <200908101245.19303.jan-oliver.wagner@intevation.de>
References: <200908101245.19303.jan-oliver.wagner@intevation.de>
Message-ID: <200908170906.48874.Jan-Oliver.Wagner@greenbone.net>

On Monday 10 August 2009 12:45:19 Jan-Oliver Wagner wrote:
> we've written a small NASL script that looks for
> presence of scanner tools.
> The idea is to have
> * a summary on missing installed tools
> * the ability to not start scripts that would cause
>    errors anyway (via mandatory_keys).
>
> Please try it out and let us know.
> If OK, I will commit it to SVN and will make
> the script part of the Feed.

its comitted now and will soon appear in the feed.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck
AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver 
Wagner


From Merlon at gmx.net  Wed Aug 19 08:06:14 2009
From: Merlon at gmx.net (Merlon@gmx.net)
Date: Wed, 19 Aug 2009 08:06:14 +0200
Subject: [Openvas-plugins] To use before commiting new plugins
Message-ID: <20090819060614.177400@gmx.net>

Hello all,

so this mail is due to the fact that some developers have commited things having old i18 stuff inside. To commit clear scripts with new standard (no english inside) this script is brought to you.

Make following changes and go to directory where the new nasl scripts located. Notice there should be the new plugins only. When having them into the same dir as where all located, seperate them into an extra directory.

apply_remove_english=1
wdir=""

Start the script and all done for commiting new plugins without i18 stuff.

Thanks

Markus

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_v22
Type: application/octet-stream
Size: 3029 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20090819/424fa226/patch_v22.obj

From Jan-Oliver.Wagner at greenbone.net  Mon Aug 24 11:25:43 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Mon, 24 Aug 2009 11:25:43 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
Message-ID: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>

Hi,

I stumbled (again) across the question how we should treat
the results of NVTs like os_fingerprint.nasl which
tries to guess some information (here the OS)
and adds this to the KB.
It also sends a security_note about the result.

IMHO this should only be a log_message() as the OS
type as such has not relation to security status.

Other scripts may use the KB entries and report about
OS's that e.g. are not supported by vendor anymore.

Any opinions about this?

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460
Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

From mime at gmx.de  Mon Aug 24 13:34:45 2009
From: mime at gmx.de (Michael Meyer)
Date: Mon, 24 Aug 2009 13:34:45 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <20090824113445.GA3106@komma-nix.de>

*** Jan-Oliver Wagner <Jan-Oliver.Wagner at greenbone.net> wrote:
> I stumbled (again) across the question how we should treat
> the results of NVTs like os_fingerprint.nasl which
> tries to guess some information (here the OS)
> and adds this to the KB.
> It also sends a security_note about the result.
> 
> IMHO this should only be a log_message() as the OS
> type as such has not relation to security status.

When scanning an entire Network, the installed Operating Systems 
could be an interesting Information. IMHO. ;-)

I would prefer the use of 'report_verbosity' for such NVTs. So the
user can then make the decision himself whether he wants to see such
Informations or not. Im using 'report_verbosity' in all of my "Service
Detection' NVTs. If 'report_verbosity' is set to 'Quiet' these NVTs
will not report about found Software. Only security related stuff is
reported in this case.

I dont't like to hide informations collected by OpenVAS unless the
user has configured to hide them.

Micha

From Jan-Oliver.Wagner at greenbone.net  Tue Aug 25 09:23:29 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Tue, 25 Aug 2009 09:23:29 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <20090824113445.GA3106@komma-nix.de>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<20090824113445.GA3106@komma-nix.de>
Message-ID: <200908250923.29949.Jan-Oliver.Wagner@greenbone.net>

Hello Michael,

On Monday 24 August 2009 13:34:45 Michael Meyer wrote:
> *** Jan-Oliver Wagner <Jan-Oliver.Wagner at greenbone.net> wrote:
> > I stumbled (again) across the question how we should treat
> > the results of NVTs like os_fingerprint.nasl which
> > tries to guess some information (here the OS)
> > and adds this to the KB.
> > It also sends a security_note about the result.
> >
> > IMHO this should only be a log_message() as the OS
> > type as such has not relation to security status.
>
> When scanning an entire Network, the installed Operating Systems
> could be an interesting Information. IMHO. ;-)

Indeed.

> I would prefer the use of 'report_verbosity' for such NVTs. So the
> user can then make the decision himself whether he wants to see such
> Informations or not. Im using 'report_verbosity' in all of my "Service
> Detection' NVTs. If 'report_verbosity' is set to 'Quiet' these NVTs
> will not report about found Software. Only security related stuff is
> reported in this case.

I don't think the "report_verbosity" feature is the way to go.
The drawback of this concept is that you only have one flag
for all NVTs. If you like to have details from NVT A, but only rough
information from NVT B, this might not work in some cases.

I guess that the Nessus developers introduced "report_verbosity"
to circumvent the lack of a log and debug level.
But OpenVAS has a log and debug level.

> I dont't like to hide informations collected by OpenVAS unless the
> user has configured to hide them.

Agreed. But we need a approach that can work more fine-grained.
It is IMHO better to get down the collection of OS to log and
have other NVTs take care of systematic reporting about OS
from the given KB entries.
This way we serve both needs, information on OS for other
NVTs  and verbosity.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck
AG Osnabr?ck, HR B 202460 | Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver 
Wagner

From mime at gmx.de  Tue Aug 25 13:30:06 2009
From: mime at gmx.de (Michael Meyer)
Date: Tue, 25 Aug 2009 13:30:06 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908250923.29949.Jan-Oliver.Wagner@greenbone.net>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<20090824113445.GA3106@komma-nix.de>
	<200908250923.29949.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <20090825113006.GA3515@komma-nix.de>

Hello Jan,

*** Jan-Oliver Wagner <Jan-Oliver.Wagner at greenbone.net> wrote:
> On Monday 24 August 2009 13:34:45 Michael Meyer wrote:
> > *** Jan-Oliver Wagner <Jan-Oliver.Wagner at greenbone.net> wrote:
 
> > I would prefer the use of 'report_verbosity' for such NVTs. So the
> > user can then make the decision himself whether he wants to see such
> > Informations or not. Im using 'report_verbosity' in all of my "Service
> > Detection' NVTs. If 'report_verbosity' is set to 'Quiet' these NVTs
> > will not report about found Software. Only security related stuff is
> > reported in this case.
> 
> I don't think the "report_verbosity" feature is the way to go.
> The drawback of this concept is that you only have one flag
> for all NVTs. If you like to have details from NVT A, but only rough
> information from NVT B, this might not work in some cases.

Hmm...do we realy need more options than 'report' and 'not report'?
Which are necessary too? Maybe i missed something...

> I guess that the Nessus developers introduced "report_verbosity"
> to circumvent the lack of a log and debug level.
> But OpenVAS has a log and debug level.

Who reads logs? IMHO, most people will only see what the Client shows.

> > I dont't like to hide informations collected by OpenVAS unless the
> > user has configured to hide them.
> 
> Agreed. But we need a approach that can work more fine-grained.
> It is IMHO better to get down the collection of OS to log and
> have other NVTs take care of systematic reporting about OS
> from the given KB entries.
> This way we serve both needs, information on OS for other
> NVTs  and verbosity.

Again: Who reads logfiles? ;-)

Micha

From bchandra at secpod.com  Tue Aug 25 14:06:37 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Tue, 25 Aug 2009 17:36:37 +0530
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <034BC77320244EAABB5E74037516750D@bchandra>

Hello,

-----Original Message-----
From: openvas-plugins-bounces at wald.intevation.org
[mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Jan-Oliver
Wagner
Sent: Monday, August 24, 2009 2:56 PM
To: openvas-plugins at wald.intevation.org
Subject: [Openvas-plugins] network information: Security Note or Log?

> Hi,

> I stumbled (again) across the question how we should treat
> the results of NVTs like os_fingerprint.nasl which
> tries to guess some information (here the OS)
> and adds this to the KB.
> It also sends a security_note about the result.

> IMHO this should only be a log_message() as the OS
> type as such has not relation to security status.

I think all discovered information should be in the report, so
security_note() is appropriate in this case. log_message() should only be
used to log information such as plugins's inability to perform something,
error messages etc.,

The discovered information is always useful to analyze the effectiveness of
the report, not everyone looks at logs.

Thanks,
Chandra.


From Jan-Oliver.Wagner at greenbone.net  Tue Aug 25 14:40:04 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Tue, 25 Aug 2009 14:40:04 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <034BC77320244EAABB5E74037516750D@bchandra>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<034BC77320244EAABB5E74037516750D@bchandra>
Message-ID: <200908251440.05543.Jan-Oliver.Wagner@greenbone.net>

On Dienstag, 25. August 2009, Chandrashekhar B wrote:
> -----Original Message-----
> > I stumbled (again) across the question how we should treat
> > the results of NVTs like os_fingerprint.nasl which
> > tries to guess some information (here the OS)
> > and adds this to the KB.
> > It also sends a security_note about the result.
> 
> > IMHO this should only be a log_message() as the OS
> > type as such has not relation to security status.
> 
> I think all discovered information should be in the report, so
> security_note() is appropriate in this case. log_message() should only be
> used to log information such as plugins's inability to perform something,
> error messages etc.,
> 
> The discovered information is always useful to analyze the effectiveness of
> the report, not everyone looks at logs.

I agree in principle.

But yet again: Should the NVTs that do collect information
into the KB report on their own Security-level message? Isn't it a better
design to have other scripts report on such information.

The significant difference is that eg.  NVTs can depend on os_fingerprint
to use their results and a independent NVT can report the OS - thus allowing
to run even NVTs that need OS without getting tons of messages about NVTs
while flexible to siwth on the OS-Reporter NVT whenever wished.

In the scenario you describe: If I want some NVTs to consider OS, then I am
automatically forced to handle the OS security messages. IMHO sooner or later
this concept will cause headache in the form of false positives management or
other way to surpress unrequested secrity-levelled information.

The more we discuss this, the more I am getting convinced we
should _in general_ downgrade any such KB-feeder script to log in
order to achieve a clean design on  reporting ...

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460
Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

From goran.licina at lss.hr  Tue Aug 25 15:03:18 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Tue, 25 Aug 2009 15:03:18 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net><034BC77320244EAABB5E74037516750D@bchandra>
	<200908251440.05543.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE51F@vlasta.lss-net.lss.hr>

Hi!

> -----Original Message-----
> From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-
> plugins-bounces at wald.intevation.org] On Behalf Of Jan-Oliver Wagner
> Sent: Tuesday, August 25, 2009 2:40 PM
> To: openvas-plugins at wald.intevation.org
> Subject: Re: [Openvas-plugins] network information: Security Note or
> Log?
> 
> On Dienstag, 25. August 2009, Chandrashekhar B wrote:
> > -----Original Message-----
> > > I stumbled (again) across the question how we should treat
> > > the results of NVTs like os_fingerprint.nasl which
> > > tries to guess some information (here the OS)
> > > and adds this to the KB.
> > > It also sends a security_note about the result.
> >
> > > IMHO this should only be a log_message() as the OS
> > > type as such has not relation to security status.
> >
> > I think all discovered information should be in the report, so
> > security_note() is appropriate in this case. log_message() should
> only be
> > used to log information such as plugins's inability to perform
> something,
> > error messages etc.,
> >
> > The discovered information is always useful to analyze the
> effectiveness of
> > the report, not everyone looks at logs.
> 
> I agree in principle.
> 
> But yet again: Should the NVTs that do collect information
> into the KB report on their own Security-level message? Isn't it a
> better
> design to have other scripts report on such information.
> 
> The significant difference is that eg.  NVTs can depend on
> os_fingerprint
> to use their results and a independent NVT can report the OS - thus
> allowing
> to run even NVTs that need OS without getting tons of messages about
> NVTs
> while flexible to siwth on the OS-Reporter NVT whenever wished.

IMHO it is a good idea to have independent NVT to report OS version because
there are different methods and NVTs that could report OS version. There could
be one script that reads OS version info provided by various plugins from KB
and reports the most reliable one.

Perhaps, os_fingerprint plugin use ICMP method to determine OS version, but
that method is not as reliable as some local check which directly reads version
from system. IMO, in that case only version reported by local check should be 
in report.

Also, if there is only one plugin reporting OS version on report level, users
can easily uncheck that plugin if they don't want OS version in report. On 
the other hand, NVTs that need OS version info  would still be able to work
normally.

Regards,

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb


From bchandra at secpod.com  Tue Aug 25 15:06:06 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Tue, 25 Aug 2009 18:36:06 +0530
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908251440.05543.Jan-Oliver.Wagner@greenbone.net>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net><034BC77320244EAABB5E74037516750D@bchandra>
	<200908251440.05543.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <FD5B5FB7E2744F4681BA5102DE150E21@bchandra>

>> I think all discovered information should be in the report, so
>> security_note() is appropriate in this case. log_message() should only be
>> used to log information such as plugins's inability to perform something,
>> error messages etc.,
>> 
>> The discovered information is always useful to analyze the effectiveness
of
>> the report, not everyone looks at logs.

> I agree in principle.

> But yet again: Should the NVTs that do collect information
> into the KB report on their own Security-level message? Isn't it a better
> design to have other scripts report on such information.

security_warning/security_hole is generally used for reporting
vulnerabilities and security_note is always used to dump some info which is
generally useful to assess the report. I don't think there are Plugins that
use security_note to report vulnerabilities.

Thanks,
Chandra.


From timb at openvas.org  Tue Aug 25 22:16:21 2009
From: timb at openvas.org (Tim Brown)
Date: Tue, 25 Aug 2009 21:16:21 +0100
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <FD5B5FB7E2744F4681BA5102DE150E21@bchandra>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<200908251440.05543.Jan-Oliver.Wagner@greenbone.net>
	<FD5B5FB7E2744F4681BA5102DE150E21@bchandra>
Message-ID: <200908252116.24133.timb@openvas.org>

On Tuesday 25 August 2009 14:06:06 Chandrashekhar B wrote:
> >> I think all discovered information should be in the report, so
> >> security_note() is appropriate in this case. log_message() should only
> >> be used to log information such as plugins's inability to perform
> >> something, error messages etc.,
> >>
> >> The discovered information is always useful to analyze the effectiveness
>
> of
>
> >> the report, not everyone looks at logs.
> >
> > I agree in principle.
> >
> > But yet again: Should the NVTs that do collect information
> > into the KB report on their own Security-level message? Isn't it a better
> > design to have other scripts report on such information.
>
> security_warning/security_hole is generally used for reporting
> vulnerabilities and security_note is always used to dump some info which is
> generally useful to assess the report. I don't think there are Plugins that
> use security_note to report vulnerabilities.

We had a pretty long chat about this on IRC today 
(http://www.linux.hr/openvas/archive/index.php?d=2009-08-25 starts at about 
14:00)... the upshot is that I'm going to work on a draft CR for this...  
Mostly because if we're going to make a change, I'm interested in seeing it 
done right.

Tim
-- 
Tim Brown
<mailto:timb at openvas.org>
<http://www.openvas.org/>

From Jan-Oliver.Wagner at greenbone.net  Wed Aug 26 13:06:33 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Wed, 26 Aug 2009 13:06:33 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <20090825113006.GA3515@komma-nix.de>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<200908250923.29949.Jan-Oliver.Wagner@greenbone.net>
	<20090825113006.GA3515@komma-nix.de>
Message-ID: <200908261306.35155.Jan-Oliver.Wagner@greenbone.net>

On Dienstag, 25. August 2009, Michael Meyer wrote:
> > > I dont't like to hide informations collected by OpenVAS unless the
> > > user has configured to hide them.
> > 
> > Agreed. But we need a approach that can work more fine-grained.
> > It is IMHO better to get down the collection of OS to log and
> > have other NVTs take care of systematic reporting about OS
> > from the given KB entries.
> > This way we serve both needs, information on OS for other
> > NVTs ?and verbosity.
> 
> Again: Who reads logfiles? 

we do have a log message class in OpenVAS (in contrast to Nessus).
So, it is not as complicated as ssh'ing to the server. You just can review
the logs in your OpenVAS Client.

But it is the wrong question ;-)

"helper-nasls" IMHO should report into KB and make a log-entry.
"reporting nasls" should use a security message to inform.

The first type of nasls is sometimes pulled into execution as
a dependency. The second is more  or less explicitely selected by the user.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460
Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

From goran.licina at lss.hr  Wed Aug 26 13:25:20 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Wed, 26 Aug 2009 13:25:20 +0200
Subject: [Openvas-plugins] cvs_pserver_heap_overflow.nasl
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE53F@vlasta.lss-net.lss.hr>

Hello!

We started working on cvs_pserver_heap_overflow.nasl missing dependency. 
This plugin provides CVS version to plugins that are dependant and reports
heap overflow vulnerability according to discovered version number.

However, it is also dependant of cvs_public_pserver.nasl plugin, so we 
are gonna work on this one too. We thought to move version detection 
from cvs_pserver_heap_overflow.nasl to cvs_public_pserver.nasl plugin, since
it is more logical to have it there.

This should require to change dependencies for:

cvs_file_existence_info_weak.nasl
cvs_malformed_entry_lines_flaw.nasl

from cvs_pserver_heap_overflow.nasl to cvs_public_pserver.nasl.

Any comments/suggestions on this?

Thanks,

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb

From bchandra at secpod.com  Wed Aug 26 15:49:35 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Wed, 26 Aug 2009 19:19:35 +0530
Subject: [Openvas-plugins] cvs_pserver_heap_overflow.nasl
In-Reply-To: <8A02A3DF683DEE42BE73187F4CA4444C0EE53F@vlasta.lss-net.lss.hr>
References: <8A02A3DF683DEE42BE73187F4CA4444C0EE53F@vlasta.lss-net.lss.hr>
Message-ID: <3A980C3504D24DFE818E9BCD47BF2318@bchandra>

Hello Goran,

-----Original Message-----
From: openvas-plugins-bounces at wald.intevation.org
[mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Goran
Licina
Sent: Wednesday, August 26, 2009 4:55 PM
To: openvas-plugins at wald.intevation.org
Subject: [Openvas-plugins] cvs_pserver_heap_overflow.nasl

> Hello!

> We started working on cvs_pserver_heap_overflow.nasl missing dependency. 
> This plugin provides CVS version to plugins that are dependant and reports
> heap overflow vulnerability according to discovered version number.

> However, it is also dependant of cvs_public_pserver.nasl plugin, so we 
> are gonna work on this one too. We thought to move version detection 
> from cvs_pserver_heap_overflow.nasl to cvs_public_pserver.nasl plugin, >
since
> it is more logical to have it there.

> This should require to change dependencies for:

> cvs_file_existence_info_weak.nasl
> cvs_malformed_entry_lines_flaw.nasl

> from cvs_pserver_heap_overflow.nasl to cvs_public_pserver.nasl.

> Any comments/suggestions on this?


There's cvs_detect.nasl, may be we could update this plugin to include the
KB items set by cvs_pserver_heap_overflow.nasl and cvs_public_pserver.nasl
and then update,

cvs_file_existence_info_weak.nasl
cvs_malformed_entry_lines_flaw.nasl 

to include cvs_detect.nasl.

Thanks,
Chandra. 


From goran.licina at lss.hr  Wed Aug 26 16:18:39 2009
From: goran.licina at lss.hr (=?iso-8859-2?Q?Goran_Li=E8ina?=)
Date: Wed, 26 Aug 2009 16:18:39 +0200
Subject: [Openvas-plugins] cvs_pserver_heap_overflow.nasl
Message-ID: <8A02A3DF683DEE42BE73187F4CA4444C0EE560@vlasta.lss-net.lss.hr>

Hi Chandra!

> -----Original Message-----
> From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-
> plugins-bounces at wald.intevation.org] On Behalf Of Chandrashekhar B
> Sent: Wednesday, August 26, 2009 3:50 PM
> To: Goran Li?ina; openvas-plugins at wald.intevation.org
> Subject: Re: [Openvas-plugins] cvs_pserver_heap_overflow.nasl
> 
> Hello Goran,
> 
> [...]
> 
> 
> There's cvs_detect.nasl, may be we could update this plugin to include
> the
> KB items set by cvs_pserver_heap_overflow.nasl and
> cvs_public_pserver.nasl
> and then update,
> 
> cvs_file_existence_info_weak.nasl
> cvs_malformed_entry_lines_flaw.nasl
> 
> to include cvs_detect.nasl.
> 

I think this is a good idea. We'll work on cvs_detect.nasl to include
additional functionalities and write necessary KB items, and provide
patch. 

However, it is still necessary to make cvs_pserver_heap_overflow.nasl
since it reports important vulnerability, so we'll do that too.

Regards,

Goran Licina
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb

From Jan-Oliver.Wagner at greenbone.net  Thu Aug 27 10:24:24 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Thu, 27 Aug 2009 10:24:24 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908252116.24133.timb@openvas.org>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<FD5B5FB7E2744F4681BA5102DE150E21@bchandra>
	<200908252116.24133.timb@openvas.org>
Message-ID: <200908271024.25787.Jan-Oliver.Wagner@greenbone.net>

On Dienstag, 25. August 2009, Tim Brown wrote:
> We had a pretty long chat about this on IRC today 
> (http://www.linux.hr/openvas/archive/index.php?d=2009-08-25 starts at about 
> 14:00)... the upshot is that I'm going to work on a draft CR for this...  
> Mostly because if we're going to make a change, I'm interested in seeing it 
> done right.

a CR is a good idea. I am looking forward to it.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460
Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

From Jan-Oliver.Wagner at greenbone.net  Thu Aug 27 10:27:24 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Thu, 27 Aug 2009 10:27:24 +0200
Subject: [Openvas-plugins] Missing deps and missing incs: Streamlining
	and pushing effords
In-Reply-To: <200908071425.33975.Jan-Oliver.Wagner@greenbone.net>
References: <200908071425.33975.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200908271027.25554.Jan-Oliver.Wagner@greenbone.net>

Hello,

no one to volunteer for this?

On Freitag, 7. August 2009, Jan-Oliver Wagner wrote:
> Hi,
> 
> many missing depedencies and missing include files
> have been resolved already, but still a number of issues are open.
> 
> I'd like to have this a bit steamlined and pushed with
> the following ideas. Please let me know what you think.
> Also, it would be great to have a volunteer to take
> care of the coordination of this task. Anyone willing
> to spend time until the last missing NASL is resolved?
> (the coordinator should also take care of high quality
> resolving, ie. that no functionality is lost or rationale/explanation
> is provided in case functionality is dropped).
> 
> * the status of missing-deps.txt, missing-deps-per-file.txt
>    and missing-deps-most-wanted.txt
>     needs to be updated.
> 
> * it would be cool to have a file "missing_nasl.txt" similar to
>    "cve_current.txt" that lists any missing dependency and
>    missing include where people can add their name to state
>    they work on it. The rest is marked "looking for a developer to take".
>  
> * Some scripts have dependencies to a number of vendor specific
>    issues (eg. for many macosx, for many solaris, for several redhat).
>    I really wonder why this need to be this way. An analysis would be
>    appreciated. Too me it looks like a broken concept.
> 
> * Our top most wanted dep is webmirror.nasl.
>    I've seen GPL ones in old GPL feed tar balls.
> 
> All the best
> 
> 	Jan
> 



-- 
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 202460
Gesch?ftsf?hrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

From felix.wolfsteller at intevation.de  Thu Aug 27 10:54:05 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 27 Aug 2009 10:54:05 +0200
Subject: [Openvas-plugins] network information: Security Note or Log?
In-Reply-To: <200908271024.25787.Jan-Oliver.Wagner@greenbone.net>
References: <200908241125.45084.Jan-Oliver.Wagner@greenbone.net>
	<200908252116.24133.timb@openvas.org>
	<200908271024.25787.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200908271054.05361.felix.wolfsteller@intevation.de>

On Thursday 27 August 2009 10:24:24 Jan-Oliver Wagner wrote:
> On Dienstag, 25. August 2009, Tim Brown wrote:
> > We had a pretty long chat about this on IRC today
> > (http://www.linux.hr/openvas/archive/index.php?d=2009-08-25 starts at
> > about 14:00)... the upshot is that I'm going to work on a draft CR for
> > this... Mostly because if we're going to make a change, I'm interested in
> > seeing it done right.
>
> a CR is a good idea. I am looking forward to it.

Me too, tim, hurry up! ;)
Holding back my ideas atm.
And I dont believe a single CR is enough for that...

--felix

-- 
Felix Wolfsteller |  ++49-541-335 08 3451  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner