From nl.srinivas at gmail.com  Tue Nov  3 17:28:54 2009
From: nl.srinivas at gmail.com (Srinivasa NL)
Date: Tue, 3 Nov 2009 21:58:54 +0530
Subject: [Openvas-devel] openvasd -S option
In-Reply-To: <6D4075D0BD12499C94D2ECB346F6CC96@bchandra>
References: <CA9167E6C9DB4A169D7FBE6D3B7939A8@bchandra>
	<200909041616.30311.Jan-Oliver.Wagner@greenbone.net>
	<8C169CEBED3A4D22ADB50916E9E997E2@geoffPC>
	<200909041542.17925.timb@openvas.org>
	<6D4075D0BD12499C94D2ECB346F6CC96@bchandra>
Message-ID: <8b85ec440911030828u4ecd170cv4cccc265796d1902@mail.gmail.com>

Hi,
  I am reopening the -S option issue.
I am still not clear about the purpose of -S option. The addresses supplied
along with -S option are "randomly" chosen and the sever binds to that
chosen address. I don't know how this is useful when server is multi-homed
or you want to spoof address to get around firewalls.Also I haven't really
checked whether the connection goes through when you give "any" legal ipv4
address.
Kind Regards,
Srinivas.


On Fri, Sep 4, 2009 at 8:26 PM, Chandrashekhar B <bchandra at secpod.com>wrote:

> -----Original Message-----
> From: openvas-devel-bounces at wald.intevation.org
> [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Tim Brown
> Sent: Friday, September 04, 2009 8:12 PM
> To: openvas-devel at wald.intevation.org
> Cc: 'Jan-Oliver Wagner'
> Subject: Re: [Openvas-devel] openvasd -S option
>
> On Friday 04 September 2009 15:35:57 Geoff Galitz wrote:
> >> Changing the source IP is frequently used for IDS evasion and spoofing
> the
> >> address of another system or network to get around firewall rules.
> >> Typically the spoofing does not work so well with TCP connections, but
> is
> >> more effective with UDP scans.  If the scanner was on the same local
> >> network as the target the TCP spoofed scan would stand a better chance
> of
> >> success (since the MAC address would still be intact).
> >>
> >> I think it would be useful to retain this feature.  It is good for
> auditing
> >> firewall and IDS systems.
>
> > Also useful it you have a multi homed machine and want to force traffic
> down a
> > specific interface irrespective of routes.
>
>
> This looks to be the real purpose!
>
> Chandra.
>
> _______________________________________________
> 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/20091103/f179f220/attachment.htm

From ckuerste at gmx.ch  Wed Nov  4 10:26:25 2009
From: ckuerste at gmx.ch (Christian Kuersteiner)
Date: Wed, 04 Nov 2009 16:26:25 +0700
Subject: [Openvas-devel] OpenVAS and Web App Security
In-Reply-To: <4ADD7F5A.4080203@gmx.ch>
References: <4ADD7F5A.4080203@gmx.ch>
Message-ID: <4AF148C1.3050201@gmx.ch>

Christian Kuersteiner wrote:
> Hi,
> 
> On another note I saw in the Devconf minutes that one step is to support 
> virtual hosts scanning. If someone could give me some pointers to start 
> with or maybe is already working on it? If some of this discussion 
> should be rather in the plugins list feel free to move it there since I 
> was unsure if the most changes would be in the code base or rather in 
> the plugins itself.
> 
> Thanks and best Regards,
> 
> Christian

Hi again,

I had a look again about the support of virtual host scanning. As the 
decision at DevCon2 was made that virtual hosts should be entered 
manually and not discovered I was thinking about the format.

An entry would look like this:
ip_address [virtual domain name1, virtual domain name2, ...]

The format could be used in the target textbox as well in the target 
file. I would prefer to have an easier possibility in the client to 
enter targets manually (have e.g. an own dialog to enter a target and 
list all the targets afterwards) but I think this would be another 
discussion and more gui related.

What do you think about this?

Christian

From timb at openvas.org  Wed Nov  4 11:05:22 2009
From: timb at openvas.org (Tim Brown)
Date: Wed, 4 Nov 2009 10:05:22 +0000
Subject: [Openvas-devel] OpenVAS and Web App Security
In-Reply-To: <4AF148C1.3050201@gmx.ch>
References: <4ADD7F5A.4080203@gmx.ch> <4AF148C1.3050201@gmx.ch>
Message-ID: <200911041005.24426.timb@openvas.org>

On Wednesday 04 November 2009 09:26:25 Christian Kuersteiner wrote:

> Hi again,
>
> I had a look again about the support of virtual host scanning. As the
> decision at DevCon2 was made that virtual hosts should be entered
> manually and not discovered I was thinking about the format.
>
> An entry would look like this:
> ip_address [virtual domain name1, virtual domain name2, ...]
>
> The format could be used in the target textbox as well in the target
> file. I would prefer to have an easier possibility in the client to
> enter targets manually (have e.g. an own dialog to enter a target and
> list all the targets afterwards) but I think this would be another
> discussion and more gui related.

A function to add to the list would be very useful, there are quite a few 
plugins that can / or could extract hostname data.  But yes, broadly speaking 
that seems like a reasonable strategy.

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

From geoff at galitz.org  Wed Nov  4 12:08:22 2009
From: geoff at galitz.org (Geoff Galitz)
Date: Wed, 04 Nov 2009 03:08:22 -0800
Subject: [Openvas-devel] Target selection [was: Web App Security]
Message-ID: <10686.1257332902@sonic.net>

 

? 

On a related note, I am considering using onecmdb as a datastore for
network and application data and then adding functions to OpenVAS to
extract data from onecmdb to identify targets and services for scanning. It
is part of my quest for an integrated solution (which also includes service
monitoring). 

 I'm curious if anyone else has played with this? 

-geoff

 ----------------------------------------- 
 Geoff Galitz 
 Blankenheim, Germany 
 http://www.galitz.org 

 On Wed 04/11/09 11:05 , "Tim Brown" timb at openvas.org sent:
  On Wednesday 04 November 2009 09:26:25 Christian Kuersteiner wrote:

 > Hi again,
 >
 > I had a look again about the support of virtual host scanning. As the
 > decision at DevCon2 was made that virtual hosts should be entered
 > manually and not discovered I was thinking about the format.
 >
 > An entry would look like this:
 > ip_address [virtual domain name1, virtual domain name2, ...]
 >
 > The format could be used in the target textbox as well in the target
 > file. I would prefer to have an easier possibility in the client to
 > enter targets manually (have e.g. an own dialog to enter a target and
 > list all the targets afterwards) but I think this would be another
 > discussion and more gui related.

 A function to add to the list would be very useful, there are quite a few

 plugins that can / or could extract hostname data. But yes, broadly
speaking 
 that seems like a reasonable strategy.

 Tim
 -- 
 Tim Brown

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091104/a1ec2f93/attachment.html

From bchandra at secpod.com  Wed Nov  4 12:24:27 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Wed, 4 Nov 2009 16:54:27 +0530
Subject: [Openvas-devel] openvasd -S option
In-Reply-To: <8b85ec440911030828u4ecd170cv4cccc265796d1902@mail.gmail.com>
References: <CA9167E6C9DB4A169D7FBE6D3B7939A8@bchandra>
	<200909041616.30311.Jan-Oliver.Wagner@greenbone.net>
	<8C169CEBED3A4D22ADB50916E9E997E2@geoffPC>
	<200909041542.17925.timb@openvas.org>
	<6D4075D0BD12499C94D2ECB346F6CC96@bchandra>
	<8b85ec440911030828u4ecd170cv4cccc265796d1902@mail.gmail.com>
Message-ID: <AC85F401A6154263BBC31975C2A7931C@bchandra>

Hello,
 
I have tested giving a valid IP address to -S, and the source address
remains the actual IP address and not the given. So, not really sure about
the purpose of -S.

Thanks,
Chandra.


>	From: Srinivasa NL [mailto:nl.srinivas at gmail.com] 
>	Sent: Tuesday, November 03, 2009 9:59 PM
>	To: Chandrashekhar B
>	Cc: Tim Brown; openvas-devel at wald.intevation.org; Jan-Oliver Wagner
>	Subject: Re: [Openvas-devel] openvasd -S option
>	
>	
>	Hi,
>	  I am reopening the -S option issue.
>	I am still not clear about the purpose of -S option. The addresses
supplied along with > -S option are "randomly" chosen and the sever binds to
that chosen address. I don't know >>> how >this is useful when server is
multi-homed or you want to spoof address to get around > firewalls.Also I
haven't really checked whether the connection goes through when you give >
"any" legal ipv4 address.
	

		-----Original Message-----
		From: openvas-devel-bounces at wald.intevation.org
		
		[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf
Of Tim Brown
		Sent: Friday, September 04, 2009 8:12 PM
		To: openvas-devel at wald.intevation.org
		Cc: 'Jan-Oliver Wagner'
		Subject: Re: [Openvas-devel] openvasd -S option
		
		
		On Friday 04 September 2009 15:35:57 Geoff Galitz wrote:
		>> Changing the source IP is frequently used for IDS evasion
and spoofing
		the
		>> address of another system or network to get around
firewall rules.
		>> Typically the spoofing does not work so well with TCP
connections, but is
		>> more effective with UDP scans.  If the scanner was on the
same local
		>> network as the target the TCP spoofed scan would stand a
better chance of
		>> success (since the MAC address would still be intact).
		>>
		>> I think it would be useful to retain this feature.  It is
good for
		auditing
		>> firewall and IDS systems.
		
		> Also useful it you have a multi homed machine and want to
force traffic
		down a
		> specific interface irrespective of routes.
		
		
		
		This looks to be the real purpose!
		
		Chandra.
		

		_______________________________________________
		Openvas-devel mailing list
		Openvas-devel at wald.intevation.org
	
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
		




From geoff at galitz.org  Wed Nov  4 12:36:38 2009
From: geoff at galitz.org (Geoff Galitz)
Date: Wed, 04 Nov 2009 03:36:38 -0800
Subject: [Openvas-devel] openvasd -S option
Message-ID: <19670.1257334598@sonic.net>

 

Here is a quote from the old nessusd man page: 

---------------------------------------------------------------------------------------------
 ____ Force the source IP of the connections established by Nessus to __
checks need to fully establish a connection to the remote host. This option
is only useful if you have a multi-homed machine with multiple public IP
addresses that you would like to use instead of the default one. Example : 
will make  establish connections with a source IP of one among those listed
above. For this setup to work, the host running nessusd should have
multiple NICs with these IP addresses set 

----------------------------------------------------------------------------------------------

Experimenting with -S without those multiple NICs would probably yield
inconclusive results. 

-geoff 

 ----------------------------------------- 
 Geoff Galitz 
 Blankenheim, Germany 
 http://www.galitz.org 

 On Wed 04/11/09 12:24 , "Chandrashekhar B" bchandra at secpod.com sent:
  Hello,

 I have tested giving a valid IP address to -S, and the source address
 remains the actual IP address and not the given. So, not really sure
about
 the purpose of -S.

 Thanks,
 Chandra.

 > From: Srinivasa NL [nl.srinivas at gmail.com] 
 > Sent: Tuesday, November 03, 2009 9:59 PM
 > To: Chandrashekhar B
 > Cc: Tim Brown; openvas-devel at wald.intevation.org; Jan-Oliver Wagner
 > Subject: Re: [Openvas-devel] openvasd -S option
 > 
 > 
 > Hi,
 > I am reopening the -S option issue.
 > I am still not clear about the purpose of -S option. The addresses
 supplied along with > -S option are "randomly" chosen and the sever binds
to
 that chosen address. I don't know >>> how >this is useful when server is
 multi-homed or you want to spoof address to get around > firewalls.Also I
 haven't really checked whether the connection goes through when you give
>
 "any" legal ipv4 address.

 -----Original Message-----
 From: openvas-devel-bounces at wald.intevation.org

 [openvas-devel-bounces at wald.intevation.org] On Behalf
 Of Tim Brown
 Sent: Friday, September 04, 2009 8:12 PM
 To: openvas-devel at wald.intevation.org
 Cc: 'Jan-Oliver Wagner'
 Subject: Re: [Openvas-devel] openvasd -S option

 On Friday 04 September 2009 15:35:57 Geoff Galitz wrote:
 >> Changing the source IP is frequently used for IDS evasion
 and spoofing
 the
 >> address of another system or network to get around
 firewall rules.
 >> Typically the spoofing does not work so well with TCP
 connections, but is
 >> more effective with UDP scans. If the scanner was on the
 same local
 >> network as the target the TCP spoofed scan would stand a
 better chance of
 >> success (since the MAC address would still be intact).
 >>
 >> I think it would be useful to retain this feature. It is
 good for
 auditing
 >> firewall and IDS systems.

 > Also useful it you have a multi homed machine and want to
 force traffic
 down a
 > specific interface irrespective of routes.

 This looks to be the real purpose!

 Chandra.

 _______________________________________________
 Openvas-devel mailing list
 Openvas-devel at wald.intevation.org

 _______________________________________________
 Openvas-devel mailing list
 Openvas-devel at wald.intevation.org

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091104/f52705ba/attachment.htm

From timb at openvas.org  Wed Nov  4 13:13:41 2009
From: timb at openvas.org (Tim Brown)
Date: Wed, 4 Nov 2009 12:13:41 +0000
Subject: [Openvas-devel] openvasd -S option
Message-ID: <200911041213.44917.timb@openvas.org>

On Wednesday 04 November 2009 11:36:38 Geoff Galitz wrote:
> Here is a quote from the old nessusd man page:
>
> ---------------------------------------------------------------------------
>------------------ ____ Force the source IP of the connections established
> by Nessus to __ checks need to fully establish a connection to the remote
> host. This option is only useful if you have a multi-homed machine with
> multiple public IP addresses that you would like to use instead of the
> default one. Example : will make  establish connections with a source IP of
> one among those listed above. For this setup to work, the host running
> nessusd should have multiple NICs with these IP addresses set
>
> ---------------------------------------------------------------------------
>-------------------
>
> Experimenting with -S without those multiple NICs would probably yield
> inconclusive results.

Totally agree.  This is not about spoofing, this is about selecting the right 
source IP address if you have something like eth0, eth0:1, eth0:2 set up.  If 
it doesn't work in this circumstance then it is broken and needs to be fixed.

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

From nl.srinivas at gmail.com  Thu Nov  5 07:47:59 2009
From: nl.srinivas at gmail.com (Srinivasa NL)
Date: Thu, 5 Nov 2009 12:17:59 +0530
Subject: [Openvas-devel] openvasd -S option
In-Reply-To: <200911041149.25857.timb@machine.org.uk>
References: <19670.1257334598@sonic.net>
	<200911041149.25857.timb@machine.org.uk>
Message-ID: <8b85ec440911042247p7794fcd7g71be9856085c46a@mail.gmail.com>

Hello Geoff,
  Thanks a lot for the clarification
Kind Regards,
Srinivas.

On Wed, Nov 4, 2009 at 5:19 PM, Tim Brown <timb at machine.org.uk> wrote:

> On Wednesday 04 November 2009 11:36:38 Geoff Galitz wrote:
> > Here is a quote from the old nessusd man page:
> >
> >
> ---------------------------------------------------------------------------
> >------------------ ____ Force the source IP of the connections established
> > by Nessus to __ checks need to fully establish a connection to the remote
> > host. This option is only useful if you have a multi-homed machine with
> > multiple public IP addresses that you would like to use instead of the
> > default one. Example : will make  establish connections with a source IP
> of
> > one among those listed above. For this setup to work, the host running
> > nessusd should have multiple NICs with these IP addresses set
> >
> >
> ---------------------------------------------------------------------------
> >-------------------
> >
> > Experimenting with -S without those multiple NICs would probably yield
> > inconclusive results.
>
> Totally agree.  This is not about spoofing, this is about selecting the
> right
> source IP address if you have something like eth0, eth0:1, eth0:2 set up.
>  If
> it doesn't work in this circumstance then it is broken and needs to be
> fixed.
>
> Tim
> --
> Tim Brown
> <mailto:timb at machine.org.uk>
> <http://www.machine.org.uk/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091105/5c20f19a/attachment.htm

From michael.wiegand at intevation.de  Fri Nov  6 15:36:58 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Fri, 6 Nov 2009 15:36:58 +0100
Subject: [Openvas-devel] Timeout for ACT_SCANNER
Message-ID: <20091106143658.GD28627@intevation.de>

Hello,

As you may or may not know, NVTs in the category ACT_SCANNER (mainly
Port Scanner) are currently exempt from the global NVT timeout.

This means that NVTs in that category will not be aborted by the OpenVAS
scanner even if they run longer than the set global timeout. This can
lead to problems if a NVTs in ACT_SCANNER fails to quit on its own since
the rest of the NVTs will wait for the port scanners to finish their
job. This can cause scans to hang indefinitely and requires manual
killing of the "stuck" child processes in the worst case.

As Michael Meyer discovered, it is indeed possible to set individual
timeouts for the NVTs in ACT_SCANNER which will be obeyed. So those NVTs
are not completely exempt from timeouts, they just seem to ignore the
global one.

I don't quite understand the reason behind this exemption; I can
understand applying a different timeout for scanners since they might
need more time, but no timeout at all seems like asking for trouble. But
it might have been good for something, so if somebody would like to
explain the reasoning to me, please do.

If you are curious, the code where the timeout is disabled is in the
plugin_launch() function in openvas-scanner/openvassd/pluginlaunch.c in
the current SVN.

If there is no reason why this should stay as it is, I would propose
either applying the global timeout to NVTs in ACT_SCANNER as well or, as
suggested by Jan-Oliver, introducing a new preference as the timeout for
this particular category.

Let me know what you think. I'll even volunteer to write the change
request! :)

Regards,

Michael

-- 
Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de
Neuer Graben 17, 49074 Osnabr?ck, Germany   |    AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091106/55382abd/attachment.pgp

From lists at securityspace.com  Fri Nov  6 23:25:33 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Fri, 06 Nov 2009 17:25:33 -0500
Subject: [Openvas-devel] Timeout for ACT_SCANNER
In-Reply-To: <20091106143658.GD28627@intevation.de>
References: <20091106143658.GD28627@intevation.de>
Message-ID: <4AF4A25D.9020907@securityspace.com>

I believe the issue here is the wildly diverse range of
sensible timeouts for ACT_SCANNER NVTs. For one NVT, it
may make sense to have a 1-2 minute timeout. For the
next, 1-2 hours. For the next, 1-2 days.  It makes
absolutely no sense to force a 1-2 day timeout for something
that takes at most 1-2 minutes.

Consider a number of examples:

1) Customer scans UDP ports on an old (not sure if limit
    still applies to new) Solaris box.  The effective rate
    limitation is 1 port every 2 seconds (ugh - or was it
    2 ports every 1 second).  Thus, a UDP scan, to be reliable
    will take a very long time.

2) find_service - may take multiple seconds (e.g. 5) to
    identify a port.  How long should find_service be allowed
    to run?  What if it finds 5 open ports?  50 open ports?
    5000 open ports?

You're right in the middle of the ugly area of what makes
it difficult to set up an effective scanner.  You trade off
accuracy for reasonable running time.  The only problem is,
only the customer really knows what this is.  Because of
this, it makes most sense (IMHO) to default to accuracy
(leaving the timeouts open-ended), and allow the user to
implement a timeout if and when it truly becomes necessary
for a given network being tested.

Thomas

Michael Wiegand wrote:
> Hello,
> 
> As you may or may not know, NVTs in the category ACT_SCANNER (mainly
> Port Scanner) are currently exempt from the global NVT timeout.
> 
> This means that NVTs in that category will not be aborted by the OpenVAS
> scanner even if they run longer than the set global timeout. This can
> lead to problems if a NVTs in ACT_SCANNER fails to quit on its own since
> the rest of the NVTs will wait for the port scanners to finish their
> job. This can cause scans to hang indefinitely and requires manual
> killing of the "stuck" child processes in the worst case.
> 
> As Michael Meyer discovered, it is indeed possible to set individual
> timeouts for the NVTs in ACT_SCANNER which will be obeyed. So those NVTs
> are not completely exempt from timeouts, they just seem to ignore the
> global one.
> 
> I don't quite understand the reason behind this exemption; I can
> understand applying a different timeout for scanners since they might
> need more time, but no timeout at all seems like asking for trouble. But
> it might have been good for something, so if somebody would like to
> explain the reasoning to me, please do.
> 
> If you are curious, the code where the timeout is disabled is in the
> plugin_launch() function in openvas-scanner/openvassd/pluginlaunch.c in
> the current SVN.
> 
> If there is no reason why this should stay as it is, I would propose
> either applying the global timeout to NVTs in ACT_SCANNER as well or, as
> suggested by Jan-Oliver, introducing a new preference as the timeout for
> this particular category.
> 
> Let me know what you think. I'll even volunteer to write the change
> request! :)
> 
> Regards,
> 
> Michael
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openvas-devel mailing list
> Openvas-devel at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-devel


From bchandra at secpod.com  Sat Nov  7 07:58:03 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Sat, 7 Nov 2009 12:28:03 +0530
Subject: [Openvas-devel] Timeout for ACT_SCANNER
In-Reply-To: <4AF4A25D.9020907@securityspace.com>
References: <20091106143658.GD28627@intevation.de>
	<4AF4A25D.9020907@securityspace.com>
Message-ID: <C789169409C34F6788AECB31886E885E@bchandra>


Hello,

I think the reason for timeout being ignored for ACT_SCANNER plugins is an
assumption that port scanning is the first step without which service
scanning etc cannot proceed. 

find_service depends on the KB items set by the port scanners. What's the
point timing out those plugins if preliminary step isn't complete. 

On the other hand, I agree they can't go on indefinitely, so a user defined
timeout would be good as suggested by Jan and Thomas. Rest of the plugins
that depend on port scanners output will anyway die for KB items not being
available. 

I had also seen sometimes back that scanning goes on forever for hosts that
aren't reachable unless the scanning is aborted manually, a different
timeout (shorter one) may be required for such plugins that set host
dead/alive KB's.

Thanks,
Chandra.
 

> -----Original Message-----
> From: openvas-devel-bounces at wald.intevation.org 
> [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf 
> Of Thomas Reinke
> Sent: Saturday, November 07, 2009 3:56 AM
> To: OpenVAS Development List
> Subject: Re: [Openvas-devel] Timeout for ACT_SCANNER
> 
> I believe the issue here is the wildly diverse range of 
> sensible timeouts for ACT_SCANNER NVTs. For one NVT, it may 
> make sense to have a 1-2 minute timeout. For the next, 1-2 
> hours. For the next, 1-2 days.  It makes absolutely no sense 
> to force a 1-2 day timeout for something that takes at most 
> 1-2 minutes.
> 
> Consider a number of examples:
> 
> 1) Customer scans UDP ports on an old (not sure if limit
>     still applies to new) Solaris box.  The effective rate
>     limitation is 1 port every 2 seconds (ugh - or was it
>     2 ports every 1 second).  Thus, a UDP scan, to be reliable
>     will take a very long time.
> 
> 2) find_service - may take multiple seconds (e.g. 5) to
>     identify a port.  How long should find_service be allowed
>     to run?  What if it finds 5 open ports?  50 open ports?
>     5000 open ports?
> 
> You're right in the middle of the ugly area of what makes it 
> difficult to set up an effective scanner.  You trade off 
> accuracy for reasonable running time.  The only problem is, 
> only the customer really knows what this is.  Because of 
> this, it makes most sense (IMHO) to default to accuracy 
> (leaving the timeouts open-ended), and allow the user to 
> implement a timeout if and when it truly becomes necessary 
> for a given network being tested.
> 
> Thomas
> 
> Michael Wiegand wrote:
> > Hello,
> > 
> > As you may or may not know, NVTs in the category 
> ACT_SCANNER (mainly 
> > Port Scanner) are currently exempt from the global NVT timeout.
> > 
> > This means that NVTs in that category will not be aborted by the 
> > OpenVAS scanner even if they run longer than the set global 
> timeout. 
> > This can lead to problems if a NVTs in ACT_SCANNER fails to quit on 
> > its own since the rest of the NVTs will wait for the port 
> scanners to 
> > finish their job. This can cause scans to hang indefinitely and 
> > requires manual killing of the "stuck" child processes in 
> the worst case.
> > 
> > As Michael Meyer discovered, it is indeed possible to set 
> individual 
> > timeouts for the NVTs in ACT_SCANNER which will be obeyed. So those 
> > NVTs are not completely exempt from timeouts, they just 
> seem to ignore 
> > the global one.
> > 
> > I don't quite understand the reason behind this exemption; I can 
> > understand applying a different timeout for scanners since 
> they might 
> > need more time, but no timeout at all seems like asking for 
> trouble. 
> > But it might have been good for something, so if somebody 
> would like 
> > to explain the reasoning to me, please do.
> > 
> > If you are curious, the code where the timeout is disabled is in the
> > plugin_launch() function in 
> openvas-scanner/openvassd/pluginlaunch.c 
> > in the current SVN.
> > 
> > If there is no reason why this should stay as it is, I 
> would propose 
> > either applying the global timeout to NVTs in ACT_SCANNER 
> as well or, 
> > as suggested by Jan-Oliver, introducing a new preference as the 
> > timeout for this particular category.
> > 
> > Let me know what you think. I'll even volunteer to write the change 
> > request! :)
> > 
> > Regards,
> > 
> > Michael
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > 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


From bchandra at secpod.com  Sat Nov  7 11:17:47 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Sat, 7 Nov 2009 15:47:47 +0530
Subject: [Openvas-devel] openvasd -S option
In-Reply-To: <200911041213.44917.timb@openvas.org>
References: <200911041213.44917.timb@openvas.org>
Message-ID: <01A5E5166ACF438C8DF9BFDD90D5F409@bchandra>

Hello,

I tested with multiple interfaces and seems to work OK, tested in
combination with -a option. The only issue that was leading to confusion was
the port scanner modules (openvas_tcp_scanner.c), which are NOT setting the
source addr given by -S, so part of the traffic still goes as the primary
source address.

Thanks for the tip!

Thanks,
Chandra.


> -----Original Message-----
> From: Tim Brown [mailto:timb at openvas.org] 
> Sent: Wednesday, November 04, 2009 5:44 PM
> To: openvas-devel at wald.intevation.org; geoff at galitz.org
> Cc: 'Srinivasa NL'; Chandrashekhar B; 'Jan-Oliver Wagner'
> Subject: Re: [Openvas-devel] openvasd -S option
> 
> On Wednesday 04 November 2009 11:36:38 Geoff Galitz wrote:
> > Here is a quote from the old nessusd man page:
> >
> > 
> >-------------------------------------------------------------
> ----------
> >----
> >------------------ ____ Force the source IP of the connections 
> >established  by Nessus to __ checks need to fully establish a 
> >connection to the remote  host. This option is only useful 
> if you have 
> >a multi-homed machine with  multiple public IP addresses 
> that you would 
> >like to use instead of the  default one. Example : will make 
>  establish 
> >connections with a source IP of  one among those listed 
> above. For this 
> >setup to work, the host running  nessusd should have 
> multiple NICs with 
> >these IP addresses set
> >
> > 
> >-------------------------------------------------------------
> ----------
> >----
> >-------------------
> >
> > Experimenting with -S without those multiple NICs would 
> probably yield 
> > inconclusive results.
> 
> Totally agree.  This is not about spoofing, this is about 
> selecting the right source IP address if you have something 
> like eth0, eth0:1, eth0:2 set up.  If it doesn't work in this 
> circumstance then it is broken and needs to be fixed.
> 
> Tim
> --
> Tim Brown
> <mailto:timb at openvas.org>
> <http://www.openvas.org/>


From timb at machine.org.uk  Wed Nov  4 12:49:19 2009
From: timb at machine.org.uk (Tim Brown)
Date: Wed, 4 Nov 2009 11:49:19 +0000
Subject: [Openvas-devel] openvasd -S option
In-Reply-To: <19670.1257334598@sonic.net>
References: <19670.1257334598@sonic.net>
Message-ID: <200911041149.25857.timb@machine.org.uk>

On Wednesday 04 November 2009 11:36:38 Geoff Galitz wrote:
> Here is a quote from the old nessusd man page:
>
> ---------------------------------------------------------------------------
>------------------ ____ Force the source IP of the connections established
> by Nessus to __ checks need to fully establish a connection to the remote
> host. This option is only useful if you have a multi-homed machine with
> multiple public IP addresses that you would like to use instead of the
> default one. Example : will make  establish connections with a source IP of
> one among those listed above. For this setup to work, the host running
> nessusd should have multiple NICs with these IP addresses set
>
> ---------------------------------------------------------------------------
>-------------------
>
> Experimenting with -S without those multiple NICs would probably yield
> inconclusive results.

Totally agree.  This is not about spoofing, this is about selecting the right 
source IP address if you have something like eth0, eth0:1, eth0:2 set up.  If 
it doesn't work in this circumstance then it is broken and needs to be fixed.

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

From openvas-bugs at wald.intevation.org  Mon Nov  9 07:36:51 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Mon,  9 Nov 2009 07:36:51 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1167=5D_Typos_in_n?=
	=?utf-8?q?ot-enough-BPFs_message?=
Message-ID: <20091109063651.10E01861EAAB@pyrosoma.intevation.org>

Bugs item #1167, was opened at 2009-11-08 23:36
Status: Open
Priority: 3
Submitted By: Ryan Schmidt (ryandesign)
Assigned to: Nobody (None)
Summary: Typos in not-enough-BPFs message 
Architecture: None
Resolution: None
Severity: trivial
Version: v2.0.4
Component: openvas-libraries
Operating System: MacOS X
Product: OpenVAS
Hardware: Macintosh
URL: 


Initial Comment:
When installing openvas-libraries on Mac OS X (Snow Leopard), the following message is printed:

-----------------------------------------
*** You appear to be running a BPF-enabled operating system.
(BPF stands for 'Berkeley Packet Filter')

BPFs are used to capture incoming packets without using the operating system.
OpenVAS uses those for some of its security checks and port scanners.

However, you seem to not have enough bpfs, (we recommand that you get about
100 of them) so OpenVAS might miss some hosts or produce inaccurate port scans.

If you can not create more bpfs, there once was a feature 'enable-bpf-sharing'
which has been removed (see OpenVAS Change Reuqest 5). Please report on the
OpenVAS Mailing Lists if this causes a problem to you.
Please read README.BPF before continuing
-----------------------------------------

There are two typos in this message:

recommand => recommend
Reuqest => Request


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1167&group_id=29

From openvas-bugs at wald.intevation.org  Mon Nov  9 13:09:28 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Mon,  9 Nov 2009 13:09:28 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1168=5D_ping=5Fhos?=
	=?utf-8?q?t=2Enasl?=
Message-ID: <20091109120928.A3B64865F4A6@pyrosoma.intevation.org>

Bugs item #1168, was opened at 2009-11-09 12:09
Status: Open
Priority: 3
Submitted By: Michael Meyer (mime)
Assigned to: Nobody (None)
Summary: ping_host.nasl 
Architecture: None
Resolution: None
Severity: normal
Version: None
Component: openvas-plugins
Operating System: All
Product: OpenVAS
Hardware: All
URL: 


Initial Comment:
Michael Wiegand reported a problem with ping_host.nasl while scanning a Windows XP Host.

The Windows XP host is up and a ping succeed but ping_host.nasl mark this host as dead.

ping_host.nasl using two different ways to try to detect if a host is up.

1: send a ICMP (ICMP_ECHO_REQUEST) by using send_packet() with active pcap filter.

2: tcp_ping() from openvas-libraries/nasl/nasl_packet_forgery.c. tcp_ping() using pcap as well.

At the moment this problem was only seen if the openvas-scanner is running on a XEN-Node. 

While scanning a few hundred hosts, a lot of plugins, which make use of send_packet(), are killed by openvas-scanner because timeout was reached. See the list at http://pastebin.com/m905b2ea. This openvas-scanner also runs on a XEN-Node.

So, there maybe exist a problem with openvas+pcap+xen.

ping_host.nasl has now been modified, to not longer mark hosts as dead by default. You must explicitly enable this feature.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1168&group_id=29

From ckuerste at gmx.ch  Tue Nov 10 05:42:26 2009
From: ckuerste at gmx.ch (Christian Kuersteiner)
Date: Tue, 10 Nov 2009 11:42:26 +0700
Subject: [Openvas-devel] vhost patch (part 1)
Message-ID: <4AF8EF32.6090006@gmx.ch>

Hello,

I created a small patch for the OpenVAS Client to allow entering of 
virtual hosts in the format ip[vhost1,vhost2]. It should work both in 
gui and cli mode.
The next part will be to group the report accordingly.

Please feel free to comment or commit it :-)

BR,

Christian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vhost.patch
Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091110/49ebd524/vhost.asc

From felix.wolfsteller at intevation.de  Tue Nov 10 08:50:34 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Tue, 10 Nov 2009 08:50:34 +0100
Subject: [Openvas-devel] Timeout for ACT_SCANNER
In-Reply-To: <20091106143658.GD28627@intevation.de>
References: <20091106143658.GD28627@intevation.de>
Message-ID: <200911100850.34960.felix.wolfsteller@intevation.de>

On Friday 06 November 2009 15:36:58 Michael Wiegand wrote:
> As you may or may not know, NVTs in the category ACT_SCANNER (mainly
> Port Scanner) are currently exempt from the global NVT timeout.
>
> Let me know what you think. I'll even volunteer to write the change
> request! :)

Whatever solution we seek here, imho it is important to communicate the case 
where execution of an NVT was stopped due to a timeout. Atm this can only be 
found out by looking at the logs and only if a certain config element is set 
to yes (log_whole_attack, i think).
I think sending a log or debug message to the client would be the easiest 
solution, using the mechanisms that are already there. I looked into it a 
while ago and failed to do so, though.

-- felix



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

From felix.wolfsteller at intevation.de  Tue Nov 10 09:40:59 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Tue, 10 Nov 2009 09:40:59 +0100
Subject: [Openvas-devel] vhost patch (part 1)
In-Reply-To: <4AF8EF32.6090006@gmx.ch>
References: <4AF8EF32.6090006@gmx.ch>
Message-ID: <200911100940.59307.felix.wolfsteller@intevation.de>

Hi Christian,
thanks for the patch.
Looks good to me, except for style (refer to
http://www.openvas.org/compendium/source-code-style-guide.html) and three 
memleaks, if i am not mistaken:
  (1) (translate_vhost) variable "temp" was not freed.
  (2) (target_file_to_list) "ret" lost.
  (3) (target_translate) "s_wo_white" lost.
Also, in that file, usage of char* and gchar* is mixed, which should generally 
be avoided. I did not make any changes to that (neither did you, it was like 
that before).

I was about to commit a modified version of your changes, but did not 
want/could not test. The patch is attached, please review.

Feel free to join http://wald.intevation.org/projects/openvas/ and request 
commit rights.

enjoy
-- felix

On Tuesday 10 November 2009 05:42:26 Christian Kuersteiner wrote:
> Hello,
>
> I created a small patch for the OpenVAS Client to allow entering of
> virtual hosts in the format ip[vhost1,vhost2]. It should work both in
> gui and cli mode.
> The next part will be to group the report accordingly.
>
> Please feel free to comment or commit it :-)
>
> BR,
>
> Christian


-- 
Felix Wolfsteller |  ++49 541 335083-783  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vhost_rev1.patch
Type: text/x-diff
Size: 2104 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091110/d496a014/vhost_rev1.bin

From felix.wolfsteller at intevation.de  Tue Nov 10 09:52:06 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Tue, 10 Nov 2009 09:52:06 +0100
Subject: [Openvas-devel] vhost patch (part 1)
In-Reply-To: <200911100940.59307.felix.wolfsteller@intevation.de>
References: <4AF8EF32.6090006@gmx.ch>
	<200911100940.59307.felix.wolfsteller@intevation.de>
Message-ID: <200911100952.07132.felix.wolfsteller@intevation.de>

Updated attached patch, line 206 now reads:
efree (&ret);
-- felix

On Tuesday 10 November 2009 09:40:59 Felix Wolfsteller wrote:
> Hi Christian,
> thanks for the patch.
> Looks good to me, except for style (refer to
> http://www.openvas.org/compendium/source-code-style-guide.html) and three
> memleaks, if i am not mistaken:
>   (1) (translate_vhost) variable "temp" was not freed.
>   (2) (target_file_to_list) "ret" lost.
>   (3) (target_translate) "s_wo_white" lost.
> Also, in that file, usage of char* and gchar* is mixed, which should
> generally be avoided. I did not make any changes to that (neither did you,
> it was like that before).
>
> I was about to commit a modified version of your changes, but did not
> want/could not test. The patch is attached, please review.
>
> Feel free to join http://wald.intevation.org/projects/openvas/ and request
> commit rights.
>
> enjoy
> -- felix
>
> On Tuesday 10 November 2009 05:42:26 Christian Kuersteiner wrote:
> > Hello,
> >
> > I created a small patch for the OpenVAS Client to allow entering of
> > virtual hosts in the format ip[vhost1,vhost2]. It should work both in
> > gui and cli mode.
> > The next part will be to group the report accordingly.
> >
> > Please feel free to comment or commit it :-)
> >
> > BR,
> >
> > Christian


-- 
Felix Wolfsteller |  ++49 541 335083-783  |  http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vhost_rev2.patch
Type: text/x-diff
Size: 2105 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091110/7e2081f6/vhost_rev2-0001.bin

From ckuerste at gmx.ch  Tue Nov 10 10:39:47 2009
From: ckuerste at gmx.ch (Christian Kuersteiner)
Date: Tue, 10 Nov 2009 16:39:47 +0700
Subject: [Openvas-devel] vhost patch (part 1)
In-Reply-To: <200911100952.07132.felix.wolfsteller@intevation.de>
References: <4AF8EF32.6090006@gmx.ch>	<200911100940.59307.felix.wolfsteller@intevation.de>
	<200911100952.07132.felix.wolfsteller@intevation.de>
Message-ID: <4AF934E3.9090308@gmx.ch>

Looks good to me.

To be honest I was a bit confused about the style too because of the 
mixing in the existing code. So I will stick to the style guide in the 
future.

Thanks

Christian

Felix Wolfsteller wrote:
> Updated attached patch, line 206 now reads:
> efree (&ret);
> -- felix
> 
> On Tuesday 10 November 2009 09:40:59 Felix Wolfsteller wrote:
>> Hi Christian,
>> thanks for the patch.
>> Looks good to me, except for style (refer to
>> http://www.openvas.org/compendium/source-code-style-guide.html) and three
>> memleaks, if i am not mistaken:
>>   (1) (translate_vhost) variable "temp" was not freed.
>>   (2) (target_file_to_list) "ret" lost.
>>   (3) (target_translate) "s_wo_white" lost.
>> Also, in that file, usage of char* and gchar* is mixed, which should
>> generally be avoided. I did not make any changes to that (neither did you,
>> it was like that before).
>>
>> I was about to commit a modified version of your changes, but did not
>> want/could not test. The patch is attached, please review.
>>
>> Feel free to join http://wald.intevation.org/projects/openvas/ and request
>> commit rights.
>>
>> enjoy
>> -- felix
>>
>> On Tuesday 10 November 2009 05:42:26 Christian Kuersteiner wrote:
>>> Hello,
>>>
>>> I created a small patch for the OpenVAS Client to allow entering of
>>> virtual hosts in the format ip[vhost1,vhost2]. It should work both in
>>> gui and cli mode.
>>> The next part will be to group the report accordingly.
>>>
>>> Please feel free to comment or commit it :-)
>>>
>>> BR,
>>>
>>> Christian
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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  Wed Nov 18 16:07:45 2009
From: michael.wiegand at intevation.de (Michael Wiegand)
Date: Wed, 18 Nov 2009 16:07:45 +0100
Subject: [Openvas-devel] Segfault in IPv6 Code
Message-ID: <4B040DC1.804@intevation.de>

Hello,

I was using the most recent SVN versions of openvas-libraries and -scanner
yesterday and discovered a large amount of following messages in my
openvassd.dump during a full scan:
Failed to find interface eth0 mentioned in /proc/net/route

And in my openvassd.messages, some thirty messages indicating segmentation
faults in NVTs:
[27687] SIGSEGV occured !
[30820] Process 27687 seems to have died too early
[30820] process_internal_msg for jolt2.nasl returned -1

I suspected the source in openvas-libraries/misc/pcap.c since the message in
openvassd.dump seemed to originate there. Sure enough, when I reverted both
-libraries and -scanner to SVN revision 5827 (before the latest big changes to
the file in the course of the IPv6 patch), the messages were gone.

Together with Michael Meyer I debugged the issue and discovered that the issue
seems to be indeed in pcap.c and can be reproduced consistently with:
openvas-nasl -X -t <target> /your/path/to/jolt2.nasl

At least on my machine; the segfault does not seem to show up everywhere. FWIW,
I'm running openvas-scanner as a non-root user in an IPv4 network.

I have attached a backtrace of the segfault and both logs; there core issue
seems to be v6_routethrough() trying to memcpy a null pointer on line 1222 of
pcap.c.

Let me know if you need more information, I'm looking forward to a bugfix. ;)

Regards,

Michael

-- 
Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - www.intevation.de
Neuer Graben 17, 49074 Osnabr?ck, Germany   |    AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdb-ipv6-jolt2.nasl-backtrace.txt
Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091118/639e3cc9/gdb-ipv6-jolt2.nasl-backtrace-0001.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openvassd.dump
Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091118/639e3cc9/openvassd-0001.pot
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openvassd.messages
Url: http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091118/639e3cc9/openvassd-0001.asc

From lists at securityspace.com  Wed Nov 18 17:54:17 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Wed, 18 Nov 2009 11:54:17 -0500
Subject: [Openvas-devel] Assigned script OID ranges
Message-ID: <4B0426B9.9060003@securityspace.com>

Currently we are assigned the 50,000-69,999 range of script IDs
within OpenVAS.  Does anyone have an issue with the 70,000-79,999
range being assigned to SecuritySpace?  We are currently projecting
exhausting the current assigned ID range sometime in late
2010.

See http://www.openvas.org/openvas-oids.html
for the current assigned ranges.

Thomas


From felix.wolfsteller at intevation.de  Thu Nov 19 09:40:10 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Thu, 19 Nov 2009 09:40:10 +0100
Subject: [Openvas-devel] OID range 7NNNN assigned to SecuritySpace
In-Reply-To: <4B0426B9.9060003@securityspace.com>
References: <4B0426B9.9060003@securityspace.com>
Message-ID: <200911190940.10757.felix.wolfsteller@intevation.de>

On Wednesday 18 November 2009 17:54:17 Thomas Reinke wrote:
> Currently we are assigned the 50,000-69,999 range of script IDs
> within OpenVAS.  Does anyone have an issue with the 70,000-79,999
> range being assigned to SecuritySpace?  We are currently projecting
> exhausting the current assigned ID range sometime in late
> 2010.
Sure thing. Glad to hear the need for more OIDs.

http://www.openvas.org/openvas-oids.html is updated now.

-- felix

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

From bchandra at secpod.com  Thu Nov 19 18:46:22 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Thu, 19 Nov 2009 23:16:22 +0530
Subject: [Openvas-devel] Segfault in IPv6 Code
In-Reply-To: <4B040DC1.804@intevation.de>
References: <4B040DC1.804@intevation.de>
Message-ID: <9A7FFE383B164D0392FAC72B113C682C@bchandra>

Hello Michael,

I wasn't able to reproduce in my setup with running openvas-scanner as a
non-root user. I see these messages in openvassd.dump,

Failed to find interface eth0 mentioned in /proc/net/route

Can you enable TCPIP_DEBUGGING and let us know if the value is NULL and if
you add a NULL check, does it solve the problem? I am suspecting something
specific to the system IP address config or the route entries.

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, November 18, 2009 8:38 PM
> To: OpenVAS Development Mailing List
> Subject: [Openvas-devel] Segfault in IPv6 Code
> 
> Hello,
> 
> I was using the most recent SVN versions of openvas-libraries 
> and -scanner yesterday and discovered a large amount of 
> following messages in my openvassd.dump during a full scan:
> Failed to find interface eth0 mentioned in /proc/net/route
> 
> And in my openvassd.messages, some thirty messages indicating 
> segmentation faults in NVTs:
> [27687] SIGSEGV occured !
> [30820] Process 27687 seems to have died too early [30820] 
> process_internal_msg for jolt2.nasl returned -1
> 
> I suspected the source in openvas-libraries/misc/pcap.c since 
> the message in openvassd.dump seemed to originate there. Sure 
> enough, when I reverted both -libraries and -scanner to SVN 
> revision 5827 (before the latest big changes to the file in 
> the course of the IPv6 patch), the messages were gone.
> 
> Together with Michael Meyer I debugged the issue and 
> discovered that the issue seems to be indeed in pcap.c and 
> can be reproduced consistently with:
> openvas-nasl -X -t <target> /your/path/to/jolt2.nasl
> 
> At least on my machine; the segfault does not seem to show up 
> everywhere. FWIW, I'm running openvas-scanner as a non-root 
> user in an IPv4 network.
> 
> I have attached a backtrace of the segfault and both logs; 
> there core issue seems to be v6_routethrough() trying to 
> memcpy a null pointer on line 1222 of pcap.c.
> 
> Let me know if you need more information, I'm looking forward 
> to a bugfix. ;)
> 
> Regards,
> 
> Michael
> 
> --
> Michael Wiegand | OpenPGP: D7D049EC | Intevation GmbH - 
> www.intevation.de
> Neuer Graben 17, 49074 Osnabr?ck, Germany   |    AG 
> Osnabr?ck, HR B 18998
> Gesch?ftsf?hrer: Frank Koormann,  Bernhard Reiter,  Dr. 
> Jan-Oliver Wagner
> 


From bitdealer at gmail.com  Thu Nov 19 19:00:16 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Thu, 19 Nov 2009 19:00:16 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
Message-ID: <200911191900.16614.bitdealer@gmail.com>

Hi guys.

I put your openvas-libraries beta 6 on OBS and the result aint that good:

1. using "--disable-static" makes the build fail:
http://wald.intevation.org/tracker/index.php?func=detail&amp;aid=1125&amp;group_id=29&amp;atid=220

2. Please look at
https://build.opensuse.org/package/show?package=openvas-
libraries&amp;project=security%3Aopenvas%3AUNSTABLE

The bottom line is that:

1. Every x86_64 build fails because the stuff is put into /usr/lib
instead of /usr/lib64

2. All Mandriva builds fail because:

libtool: link: i586-mandriva-linux-gnu-gcc -shared -Wl,--as-needed
.libs/hg_utils.o .libs/hg_add_hosts.o .libs/hg_subnet.o
.libs/hg_filter.o .libs/hosts_gatherer.o .libs/hg_debug.o
.libs/hg_dns_axfr.o -Wl,--as-needed -Wl,--no-undefined -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -lutil
-lnsl -lpcap /usr/lib/libgnutls.so -L/usr/lib /usr/lib/libtasn1.so -lz
-lresolv /usr/lib/libgcrypt.so /usr/lib/libgpg-error.so -Wl,-soname
-Wl,libopenvas_hg.so.3 -o .libs/libopenvas_hg.so.3.0.0
.libs/hg_add_hosts.o: In function `hg_add_host_with_options':
/home/abuild/rpmbuild/BUILD/openvas-
libraries-3.0.0.beta6/hg/hg_add_hosts.c:545:
undefined reference to `convipv4toipv4mappedaddr'

3. all openSUSE builds fail because the automatic code checks have a
problem with your code:

I: A function overflows or underflows an array access. This could be a
real error,
but occasionaly this condition is also misdetected due to loop
unrolling or strange pointer
handling. So this is warning only, please review.
W: openvas-libraries arraysubscript bpf_share.c:47

I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
W: openvas-libraries strict-aliasing-punning pcap.c:353
E: openvas-libraries 64bit-portability-issue network.c:1179

I: Statement is overflowing a buffer
E: openvas-libraries bufferoverflow
/usr/src/packages/BUILD/openvas-libraries-3.0.0.beta6/nasl/nasl_socket.c:256
E: openvas-libraries bufferoverflow hg_utils.c:104

Please be so kind to review those parts.

Last but not least I needed the attached patch, which I would like to
ask you to review and apply to trunk if it is fine to get it compiled.

The nasl/CMakeLists.txt part is necessary to build it on openSUSE 11.2
which uses as-needed and the base/CMakeLists.txt part was for Mandriva
albeight it still fails later with the error shown above.

regards,
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openvas-libraries-3.0.0.beta6-compile.patch
Type: text/x-patch
Size: 1724 bytes
Desc: not available
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20091119/670f3cb8/openvas-libraries-3.0.0.beta6-compile.bin

From lists at securityspace.com  Thu Nov 19 19:01:19 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Thu, 19 Nov 2009 13:01:19 -0500
Subject: [Openvas-devel] [Openvas-commits] r5894 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
Message-ID: <4B0587EF.6060702@securityspace.com>


> + if(defined_func("script_mandatory_keys"))
> +   script_mandatory_keys("Tools/Present/nmap");
> +
>   exit(0);
>  }


I had looked at this originally and decided against it.

The way the toolcheck nasl runs, if the "Perform tool
check" preference is set to no, none of the Tools/*
keys will be set, having the effect of disabling
scripts relying on these tools.  I'm not convinced
that this is correct behaviour.

I believe (although I might be mistaken) that
toolcheck is an advisory report, by default enabled,
to let one know that there are additional tools
that one could install to improve scanner functionality.
I don't think it was intended as a setting to turn off
all supplementary tools.

In other words, if we want to rely on Tools/* keys,
we need to change the toolcheck nasl script to
check for tools, ALWAYS populate keys, and only report
based on the preference setting.    Then, and only
then, is it ok to make various scripts dependent on the
tools/* keys.

Thomas


From Jan-Oliver.Wagner at greenbone.net  Thu Nov 19 21:19:34 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Thu, 19 Nov 2009 21:19:34 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911191900.16614.bitdealer@gmail.com>
References: <200911191900.16614.bitdealer@gmail.com>
Message-ID: <200911192119.34693.Jan-Oliver.Wagner@greenbone.net>

Hi Stephan,

On Thursday 19 November 2009 19:00:16 Stephan Kleine wrote:
> I put your openvas-libraries beta 6 on OBS and the result aint that good:
>...

thanks for starting to get OpenVAS 3.0 to OBS!

We'll try to resolve the identified issues.

Once we have openvas-libraries packages for at least one of the platforms,
it would be nice to add openvas-scanner and openvas-client as well.
So that we can identify problems as early as possible.

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 bitdealer at gmail.com  Fri Nov 20 03:07:27 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Fri, 20 Nov 2009 03:07:27 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911192119.34693.Jan-Oliver.Wagner@greenbone.net>
References: <200911191900.16614.bitdealer@gmail.com>
	<200911192119.34693.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200911200307.27430.bitdealer@gmail.com>

On Thursday 19 November 2009 21:19:34 Jan-Oliver Wagner wrote:
> thanks for starting to get OpenVAS 3.0 to OBS!
> 
> We'll try to resolve the identified issues.
> 
> Once we have openvas-libraries packages for at least one of the platforms,
> it would be nice to add openvas-scanner and openvas-client as well.
> So that we can identify problems as early as possible.

I build -client and -scanner there as well and filed some bugs for the stuff I 
run into.

Currently all builds except Fedora 10 & 11 i586 fail for one reason or 
another.

See 
https://build.opensuse.org/project/show?project=security%3Aopenvas%3AUNSTABLE 
for the details.

Regards,
Stephan

From Jan-Oliver.Wagner at greenbone.net  Fri Nov 20 10:13:17 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Fri, 20 Nov 2009 10:13:17 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911200307.27430.bitdealer@gmail.com>
References: <200911191900.16614.bitdealer@gmail.com>
	<200911192119.34693.Jan-Oliver.Wagner@greenbone.net>
	<200911200307.27430.bitdealer@gmail.com>
Message-ID: <200911201013.19260.Jan-Oliver.Wagner@greenbone.net>

On Freitag, 20. November 2009, Stephan Kleine wrote:
> On Thursday 19 November 2009 21:19:34 Jan-Oliver Wagner wrote:
> > thanks for starting to get OpenVAS 3.0 to OBS!
> > 
> > We'll try to resolve the identified issues.
> > 
> > Once we have openvas-libraries packages for at least one of the platforms,
> > it would be nice to add openvas-scanner and openvas-client as well.
> > So that we can identify problems as early as possible.
> 
> I build -client and -scanner there as well and filed some bugs for the stuff I 
> run into.

great!

> Currently all builds except Fedora 10 & 11 i586 fail for one reason or 
> another.

we will take care of these.

Have you noticed that for the 3.0 series there are two optional modules
"openvas-administrator" and "openvas-manager"?
I am not aware of any RPM packages for these. However they are plain
cmake based and maybe this helps to get RPMs easily?

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  Fri Nov 20 10:21:35 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Fri, 20 Nov 2009 10:21:35 +0100
Subject: [Openvas-devel] [Openvas-commits] r5894 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <4B0587EF.6060702@securityspace.com>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
	<4B0587EF.6060702@securityspace.com>
Message-ID: <200911201021.36668.Jan-Oliver.Wagner@greenbone.net>

Hi Thomas,

On Donnerstag, 19. November 2009, Thomas Reinke wrote:
> 
> > + if(defined_func("script_mandatory_keys"))
> > +   script_mandatory_keys("Tools/Present/nmap");
> > +
> >   exit(0);
> >  }
> 
> 
> I had looked at this originally and decided against it.
> 
> The way the toolcheck nasl runs, if the "Perform tool
> check" preference is set to no, none of the Tools/*
> keys will be set, having the effect of disabling
> scripts relying on these tools.  I'm not convinced
> that this is correct behaviour.
> 
> I believe (although I might be mistaken) that
> toolcheck is an advisory report, by default enabled,
> to let one know that there are additional tools
> that one could install to improve scanner functionality.
> I don't think it was intended as a setting to turn off
> all supplementary tools.

the original idea is that it is not only advisory.
The concept of mandatory keys allows to
prevent launch of scripts that can not at all
return anything useful if the precondition is not met.
Like a nmap scan of no nmap available.

Why is this important? We want only a single check
for the nmap binary and version. Not 4000 in case
4000 IPs are scanned. This is to be multiplied with the
number of tools/versions and with the scripts using them.

A positive side effect is also that the reports have
the single statement that e.g. no nmap scripts
are executed instead of 4000 entries that nmap
was not found.
 
> In other words, if we want to rely on Tools/* keys,
> we need to change the toolcheck nasl script to
> check for tools, ALWAYS populate keys, and only report
> based on the preference setting.    Then, and only
> then, is it ok to make various scripts dependent on the
> tools/* keys.

the mandatory keys feature can only consider presence,
not values. If toolcheck.nasl would set values we are back
to 4000 nmap trials.


What exactly is the harm done by toolcheck and mandatory_keys?


Best

	Jan

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

From felix.wolfsteller at intevation.de  Fri Nov 20 12:03:15 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 20 Nov 2009 12:03:15 +0100
Subject: [Openvas-devel] [Openvas-commits] r5894 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <4B0587EF.6060702@securityspace.com>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
	<4B0587EF.6060702@securityspace.com>
Message-ID: <200911201203.15870.felix.wolfsteller@intevation.de>

I can follow your argument.

Optimally, a nasl command "script_require_tool (tool, version_expr)", called 
e.g. like script_require_tool ("nmap", ">2") would do what we want.

For now, I support your suggestion to add a preference to toolcheck.nasl, 
whether it should report the findings or not, and always execute it.

-- felix

On Thursday 19 November 2009 19:01:19 Thomas Reinke wrote:
> > + if(defined_func("script_mandatory_keys"))
> > +   script_mandatory_keys("Tools/Present/nmap");
> > +
> >   exit(0);
> >  }
>
> I had looked at this originally and decided against it.
>
> The way the toolcheck nasl runs, if the "Perform tool
> check" preference is set to no, none of the Tools/*
> keys will be set, having the effect of disabling
> scripts relying on these tools.  I'm not convinced
> that this is correct behaviour.
>
> I believe (although I might be mistaken) that
> toolcheck is an advisory report, by default enabled,
> to let one know that there are additional tools
> that one could install to improve scanner functionality.
> I don't think it was intended as a setting to turn off
> all supplementary tools.
>
> In other words, if we want to rely on Tools/* keys,
> we need to change the toolcheck nasl script to
> check for tools, ALWAYS populate keys, and only report
> based on the preference setting.    Then, and only
> then, is it ok to make various scripts dependent on the
> tools/* keys.
>
> Thomas
>
> _______________________________________________
> Openvas-commits mailing list
> Openvas-commits at wald.intevation.org
> http://lists.wald.intevation.org/mailman/listinfo/openvas-commits


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

From felix.wolfsteller at intevation.de  Fri Nov 20 12:14:42 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 20 Nov 2009 12:14:42 +0100
Subject: [Openvas-devel] [Openvas-commits] r5894 - in
	trunk/openvas-plugins: . scripts
In-Reply-To: <200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
	<4B0587EF.6060702@securityspace.com>
	<200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200911201214.42768.felix.wolfsteller@intevation.de>

On Friday 20 November 2009 10:21:35 Jan-Oliver Wagner wrote:
> On Donnerstag, 19. November 2009, Thomas Reinke wrote:
> > The way the toolcheck nasl runs, if the "Perform tool
> > check" preference is set to no, none of the Tools/*
> > keys will be set, having the effect of disabling
> > scripts relying on these tools.  I'm not convinced
> > that this is correct behaviour.
> >
> > I believe (although I might be mistaken) that
> > toolcheck is an advisory report, by default enabled,
> > to let one know that there are additional tools
> > that one could install to improve scanner functionality.
> > I don't think it was intended as a setting to turn off
> > all supplementary tools.
>
> What exactly is the harm done by toolcheck and mandatory_keys?

No harm done, if toolchecks "Perform Toolcheck" preference is set to "yes".
If "Perform Toolcheck" is set to "no", no nvts will be launched that require 
external tools checked by toolchek + mandatory keys.

-- felix

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

From lists at securityspace.com  Fri Nov 20 17:23:26 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Fri, 20 Nov 2009 11:23:26 -0500
Subject: [Openvas-devel] [Openvas-commits] r5894 -
 in	trunk/openvas-plugins: . scripts
In-Reply-To: <200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>	<4B0587EF.6060702@securityspace.com>
	<200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <4B06C27E.7040204@securityspace.com>

Jan-Oliver Wagner wrote:
> Hi Thomas,
> 
> On Donnerstag, 19. November 2009, Thomas Reinke wrote:
>>> + if(defined_func("script_mandatory_keys"))
>>> +   script_mandatory_keys("Tools/Present/nmap");
>>> +
>>>   exit(0);
>>>  }
>>
>> I had looked at this originally and decided against it.
>>
>> The way the toolcheck nasl runs, if the "Perform tool
>> check" preference is set to no, none of the Tools/*
>> keys will be set, having the effect of disabling
>> scripts relying on these tools.  I'm not convinced
>> that this is correct behaviour.
>>
>> I believe (although I might be mistaken) that
>> toolcheck is an advisory report, by default enabled,
>> to let one know that there are additional tools
>> that one could install to improve scanner functionality.
>> I don't think it was intended as a setting to turn off
>> all supplementary tools.
> 
> the original idea is that it is not only advisory.
> The concept of mandatory keys allows to
> prevent launch of scripts that can not at all
> return anything useful if the precondition is not met.
> Like a nmap scan of no nmap available.
> 
> Why is this important? We want only a single check
> for the nmap binary and version. Not 4000 in case
> 4000 IPs are scanned. This is to be multiplied with the
> number of tools/versions and with the scripts using them.

Agreed.

> 
> A positive side effect is also that the reports have
> the single statement that e.g. no nmap scripts
> are executed instead of 4000 entries that nmap
> was not found.

I agree this is a good thing.

>  
>> In other words, if we want to rely on Tools/* keys,
>> we need to change the toolcheck nasl script to
>> check for tools, ALWAYS populate keys, and only report
>> based on the preference setting.    Then, and only
>> then, is it ok to make various scripts dependent on the
>> tools/* keys.
> 
> the mandatory keys feature can only consider presence,
> not values. If toolcheck.nasl would set values we are back
> to 4000 nmap trials.
> 
> 
> What exactly is the harm done by toolcheck and mandatory_keys?

Ok...scenario -- I run 20 reports a day. Each report says
"You are missing ovaldi and nikto".  I get it. I'm missing
those two.  So I turn off the "Perform tool check".
Those annoying messages go away. Great.  But now, despite the
fact that I have nmap on my system, all nmap functionality
has gone away as well, despite it being available.

Solution #1:
Change the preference to "Disable use of 3rd party tools
such as nmap" or some such thing to avoid misunderstanding
what the setting is. Because that's what it is doing right now.
And that's the misunderstanding I had.

Solution #2:
As per your comment that it is not advisory, change toolcheck.nasl
to ALWAYS run, and provide users with a way of disabling the
reporting from toolcheck.nasl if they already are perfectly aware
of what tools they have installed on their scanner and don't want
to see those messages.

Personally, I like the second solution better. I don't see a
reason for the preference setting as it is currenty is - I don't
know of a good reason to NOT run toolcheck.nasl, but I can see
good reasons to suppress the reporting that toolcheck.nasl does.

Thomas



From lists at securityspace.com  Fri Nov 20 18:13:13 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Fri, 20 Nov 2009 12:13:13 -0500
Subject: [Openvas-devel] [Openvas-commits] r5894 -
 in	trunk/openvas-plugins: . scripts
In-Reply-To: <4B06C27E.7040204@securityspace.com>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>	<4B0587EF.6060702@securityspace.com>	<200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
	<4B06C27E.7040204@securityspace.com>
Message-ID: <4B06CE29.9030001@securityspace.com>


>> Why is this important? We want only a single check
>> for the nmap binary and version. Not 4000 in case
>> 4000 IPs are scanned. This is to be multiplied with the
>> number of tools/versions and with the scripts using them.
> 
> Agreed.

Actually, I believe I'm wrong having agreed here.
The script will run once for each and every IP address,
no?  So alerts that you are missing a given tool will
show up multiple times, in your example, 4000 times,
I believe, once for each IP address.

All you save is the fact that if different scripts
use the same tool, you can avoid redundant checks
for the existence of the same tool (such as nmap).

Which gets back to, run toolcheck.nasl always, and
have the ability to turn off reporting messages to
avoid cluttering reports with stuff a user doesn't
want to see.

Thomas

From Jan-Oliver.Wagner at greenbone.net  Fri Nov 20 20:26:23 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Fri, 20 Nov 2009 20:26:23 +0100
Subject: [Openvas-devel] toolcheck
In-Reply-To: <4B06C27E.7040204@securityspace.com>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>
	<200911201021.36668.Jan-Oliver.Wagner@greenbone.net>
	<4B06C27E.7040204@securityspace.com>
Message-ID: <200911202026.23451.Jan-Oliver.Wagner@greenbone.net>

Thomas,

On Friday 20 November 2009 17:23:26 Thomas Reinke wrote:
> > What exactly is the harm done by toolcheck and mandatory_keys?
> 
> Ok...scenario -- I run 20 reports a day. Each report says
> "You are missing ovaldi and nikto".  I get it. I'm missing
> those two.  So I turn off the "Perform tool check".
> Those annoying messages go away. Great.  But now, despite the
> fact that I have nmap on my system, all nmap functionality
> has gone away as well, despite it being available.

You are right! I forgot about this option, I have it always active.
 
> Solution #1:
> Change the preference to "Disable use of 3rd party tools
> such as nmap" or some such thing to avoid misunderstanding
> what the setting is. Because that's what it is doing right now.
> And that's the misunderstanding I had.
> 
> Solution #2:
> As per your comment that it is not advisory, change toolcheck.nasl
> to ALWAYS run, and provide users with a way of disabling the
> reporting from toolcheck.nasl if they already are perfectly aware
> of what tools they have installed on their scanner and don't want
> to see those messages.
> 
> Personally, I like the second solution better. I don't see a
> reason for the preference setting as it is currenty is - I don't
> know of a good reason to NOT run toolcheck.nasl, but I can see
> good reasons to suppress the reporting that toolcheck.nasl does.

Fully agreed from my side. We should get rid of that option.
I guess it is a remains of the very first version where we did
not want to disturb people with the new toolcheck.
Today it seems is has proven and even must be there
to have correct and efficient scans.

Any argument to raise why we should not have toolcheck always
be executed?

Note for NASL writers, that it is a good idea to set toolcheck.nasl
as a dependency in case script_mandatory_keys uses results of it.

However, it is still possible to configure scans in a way that
toolcheck is not executed and thus the problem occurs which
Thomas described.

Best

	Jan

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

From lists at securityspace.com  Sat Nov 21 07:01:25 2009
From: lists at securityspace.com (Thomas Reinke)
Date: Sat, 21 Nov 2009 01:01:25 -0500
Subject: [Openvas-devel] toolcheck
In-Reply-To: <200911202026.23451.Jan-Oliver.Wagner@greenbone.net>
References: <20091119083639.42AEE852DDDE@pyrosoma.intevation.org>	<200911201021.36668.Jan-Oliver.Wagner@greenbone.net>	<4B06C27E.7040204@securityspace.com>
	<200911202026.23451.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <4B078235.50600@securityspace.com>

Jan-Oliver Wagner wrote:

> Note for NASL writers, that it is a good idea to set toolcheck.nasl
> as a dependency in case script_mandatory_keys uses results of it.

Shouldn't be necessary, actually.  The script is an ACT_INIT script,
which according to documentation, is executed before other categories,
so the dependency setting should not be necessary.

Thomas

From felix.wolfsteller at intevation.de  Mon Nov 23 10:40:32 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Mon, 23 Nov 2009 10:40:32 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911191900.16614.bitdealer@gmail.com>
References: <200911191900.16614.bitdealer@gmail.com>
Message-ID: <200911231040.32491.felix.wolfsteller@intevation.de>

Hi Stephan
Thanks for your effort and patience.
I started looking into the issues reported by you.

On Thursday 19 November 2009 19:00:16 Stephan Kleine wrote:
> 3. all openSUSE builds fail because the automatic code checks have a
> problem with your code:
>
> I: A function overflows or underflows an array access. This could be a
> real error,
> but occasionaly this condition is also misdetected due to loop
> unrolling or strange pointer
> handling. So this is warning only, please review.
> W: openvas-libraries arraysubscript bpf_share.c:47
>
> I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
> W: openvas-libraries strict-aliasing-punning pcap.c:353
> E: openvas-libraries 64bit-portability-issue network.c:1179
>
> I: Statement is overflowing a buffer
> E: openvas-libraries bufferoverflow
> /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta6/nasl/nasl_socket.c:25
>6 E: openvas-libraries bufferoverflow hg_utils.c:104
>
> Please be so kind to review those parts.
Most of these just confuse me, some are maybe fixed by recent commits of 
chandra.

> Last but not least I needed the attached patch, which I would like to
> ask you to review and apply to trunk if it is fine to get it compiled.
>
> The nasl/CMakeLists.txt part is necessary to build it on openSUSE 11.2
> which uses as-needed and the base/CMakeLists.txt part was for Mandriva
> albeight it still fails later with the error shown above.
I applied the first part of your patch and could not see any issues on my 
environment (committed in rev. 5935, few minutes late for the beta7 release, 
sorry for that).

-- felix


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

From bitdealer at gmail.com  Mon Nov 23 13:21:05 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Mon, 23 Nov 2009 13:21:05 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911231040.32491.felix.wolfsteller@intevation.de>
References: <200911191900.16614.bitdealer@gmail.com>
	<200911231040.32491.felix.wolfsteller@intevation.de>
Message-ID: <200911231321.05928.bitdealer@gmail.com>

On Monday 23 November 2009 10:40:32 Felix Wolfsteller wrote:
> On Thursday 19 November 2009 19:00:16 Stephan Kleine wrote:
> > 3. all openSUSE builds fail because the automatic code checks have a
> > problem with your code:
> >
> > I: A function overflows or underflows an array access. This could be a
> > real error,
> > but occasionaly this condition is also misdetected due to loop
> > unrolling or strange pointer
> > handling. So this is warning only, please review.
> > W: openvas-libraries arraysubscript bpf_share.c:47
> >
> > I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
> > W: openvas-libraries strict-aliasing-punning pcap.c:353
> > E: openvas-libraries 64bit-portability-issue network.c:1179
> >
> > I: Statement is overflowing a buffer
> > E: openvas-libraries bufferoverflow
> > /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta6/nasl/nasl_socket.c:
> >25 6 E: openvas-libraries bufferoverflow hg_utils.c:104
> >
> > Please be so kind to review those parts.
> 
> Most of these just confuse me, some are maybe fixed by recent commits of
> chandra.

One is gone, the rest is still there. Bellow is the output for beta 7:

I: A function overflows or underflows an array access. This could be a real 
error, but occasionaly this condition is also misdetected due to loop 
unrolling or strange pointer handling. So this is warning only, please review.
W: openvas-libraries arraysubscript bpf_share.c:47

I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
W: openvas-libraries strict-aliasing-punning pcap.c:763
E: openvas-libraries 64bit-portability-issue network.c:1179

I: Statement is overflowing a buffer
E: openvas-libraries bufferoverflow /usr/src/packages/BUILD/openvas-
libraries-3.0.0.beta7/nasl/nasl_socket.c:256


Regards,
Stephan

From bchandra at secpod.com  Mon Nov 23 15:30:21 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Mon, 23 Nov 2009 20:00:21 +0530
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <200911231321.05928.bitdealer@gmail.com>
References: <200911191900.16614.bitdealer@gmail.com><200911231040.32491.felix.wolfsteller@intevation.de>
	<200911231321.05928.bitdealer@gmail.com>
Message-ID: <C4673DB5BB134625A404DFF3A6F9AF52@bchandra>


Hello Stephen,



> -----Original Message-----
> From: openvas-devel-bounces at wald.intevation.org 
> [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf 
> Of Stephan Kleine
> Sent: Monday, November 23, 2009 5:51 PM
> To: openvas-devel at wald.intevation.org
> Subject: Re: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
> 
> On Monday 23 November 2009 10:40:32 Felix Wolfsteller wrote:
> > On Thursday 19 November 2009 19:00:16 Stephan Kleine wrote:
> > > 3. all openSUSE builds fail because the automatic code 
> checks have a 
> > > problem with your code:
> > >
> > > I: A function overflows or underflows an array access. 
> This could be 
> > > a real error, but occasionaly this condition is also 
> misdetected due 
> > > to loop unrolling or strange pointer handling. So this is warning 
> > > only, please review.
> > > W: openvas-libraries arraysubscript bpf_share.c:47
> > >
> > > I: Program is likely to break with new gcc. Try 
> -fno-strict-aliasing.
> > > W: openvas-libraries strict-aliasing-punning pcap.c:353
> > > E: openvas-libraries 64bit-portability-issue network.c:1179
> > >
> > > I: Statement is overflowing a buffer
> > > E: openvas-libraries bufferoverflow
> > > 
> /usr/src/packages/BUILD/openvas-libraries-3.0.0.beta6/nasl/nas
> l_socket.c:
> > >25 6 E: openvas-libraries bufferoverflow hg_utils.c:104
> > >
> > > Please be so kind to review those parts.
> > 
> > Most of these just confuse me, some are maybe fixed by 
> recent commits 
> > of chandra.
> 
> One is gone, the rest is still there. Bellow is the output for beta 7:
> 
> I: A function overflows or underflows an array access. This 
> could be a real error, but occasionaly this condition is also 
> misdetected due to loop unrolling or strange pointer 
> handling. So this is warning only, please review.
> W: openvas-libraries arraysubscript bpf_share.c:47
> 
> I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
> W: openvas-libraries strict-aliasing-punning pcap.c:763
> E: openvas-libraries 64bit-portability-issue network.c:1179
> 
> I: Statement is overflowing a buffer
> E: openvas-libraries bufferoverflow /usr/src/packages/BUILD/openvas-
> libraries-3.0.0.beta7/nasl/nasl_socket.c:256

This is committed, please check.

Chandra.



From bitdealer at gmail.com  Mon Nov 23 16:25:58 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Mon, 23 Nov 2009 16:25:58 +0100
Subject: [Openvas-devel] openvas-libraries 3.0.0 beta 6 feedback
In-Reply-To: <C4673DB5BB134625A404DFF3A6F9AF52@bchandra>
References: <200911191900.16614.bitdealer@gmail.com>
	<200911231321.05928.bitdealer@gmail.com>
	<C4673DB5BB134625A404DFF3A6F9AF52@bchandra>
Message-ID: <200911231625.58121.bitdealer@gmail.com>

On Monday 23 November 2009 15:30:21 Chandrashekhar B wrote:
> This is committed, please check.

I tried r5945 and there the one in nasl_socket.c is gone so we are now at:

I: A function overflows or underflows an array access. This could be a real 
error, but occasionaly this condition is also misdetected due to loop 
unrolling or strange pointer handling. So this is warning only, please review.
W: openvas-libraries arraysubscript bpf_share.c:47

I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
W: openvas-libraries strict-aliasing-punning pcap.c:763
E: openvas-libraries 64bit-portability-issue network.c:1179

Regards,
Stephan

From openvas-bugs at wald.intevation.org  Thu Nov 19 23:16:26 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Thu, 19 Nov 2009 23:16:26 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1188=5D_sslui=2Ec?=
	=?utf-8?b?OjM3MjogZXJyb3I6ICdHTlVUTFNfQ1JUX1BSSU5UX0ZVTEwnIHVuZGVj?=
	=?utf-8?q?lared?=
Message-ID: <20091119221626.58BF985D9F67@pyrosoma.intevation.org>

Bugs item #1188, was opened at 2009-11-19 22:16
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: sslui.c:372: error: 'GNUTLS_CRT_PRINT_FULL' undeclared 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-client
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
If I'm not mistaken GNUTLS_CRT_PRINT_FULL was added with gnutls 2.4.0. Please verify this and add a check so it bails during configure if the gnutls library is too old since that's much more user friendly.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1188&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:40:31 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:40:31 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1191=5D_missing_ch?=
	=?utf-8?q?eck_in_configure_for_gnutls?=
Message-ID: <20091120014031.A4D9A85D9F67@pyrosoma.intevation.org>

Bugs item #1191, was opened at 2009-11-20 01:40
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: missing check in configure for gnutls 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-scanner
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
configure is missing a check if gnutls is installed.

Also some other build failed with:
/usr/lib/libopenvas_misc.so: undefined reference to `gnutls_session_enable_compatibility_mode'

so probably gnutls version should be >= 2.0.3

Please verify the required version and add a check to configure.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1191&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:41:16 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:41:16 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1192=5D_missing_ch?=
	=?utf-8?q?eck_in_configure_for_pcap?=
Message-ID: <20091120014116.15F0A85D9F67@pyrosoma.intevation.org>

Bugs item #1192, was opened at 2009-11-20 01:41
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: missing check in configure for pcap 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-scanner
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
configure doesn't check if pcap is installed.

Please add a check.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1192&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:42:09 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:42:09 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1193=5D_missing_ch?=
	=?utf-8?q?eck_in_configure_for_gpgme?=
Message-ID: <20091120014209.2FD5D85D9F67@pyrosoma.intevation.org>

Bugs item #1193, was opened at 2009-11-20 01:42
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: missing check in configure for gpgme 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-scanner
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
configure doesn't check for gpgme so the build later fails with

gcc -shared  .libs/synscan.o  -L/usr/lib -lopenvas_misc -lopenvas_hg -lopenvas_base -lutil -lnsl -lpcap -lgnutls -lresolv -lopenvas_nasl -lopenvas_omp -lgcrypt -lgpgme -lglib-2.0  -march=i386 -mtune=i686 -Wl,-soname -Wl,libsynscan.so.0 -o .libs/libsynscan.so.0.0.0
/usr/bin/ld: cannot find -lgpgme

Please add a check to configure.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1193&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:45:05 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:45:05 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1194=5D_On_64_bit_?=
	=?utf-8?q?libraries_get_installed_into_/usr/lib_instead_of_/usr/li?=
	=?utf-8?q?b64?=
Message-ID: <20091120014505.998FF85D9F67@pyrosoma.intevation.org>

Bugs item #1194, was opened at 2009-11-20 01:45
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: On 64 bit libraries get installed into /usr/lib instead of /usr/lib64 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-libraries
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
misc & hg get installed into /usr/lib64 but nasl, base & omp get put into /usr/lib

Noteworthy is that all wrongly installed libraries use CMake so the error probably is in your CMakeLists.txt's.

If you fix that please mention the revision here because I'm interested in how to fix that with CMake as well.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1194&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:46:25 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:46:25 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1195=5D_hg/hg=5Fad?=
	=?utf-8?q?d=5Fhosts=2Ec=3A545=3A_undefined_reference_to_=60convipv?=
	=?utf-8?q?4toipv4mappedaddr=27?=
Message-ID: <20091120014625.AEF3285D9F67@pyrosoma.intevation.org>

Bugs item #1195, was opened at 2009-11-20 01:46
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: hg/hg_add_hosts.c:545: undefined reference to `convipv4toipv4mappedaddr' 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-libraries
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
All Mandriva builds currently fails with

hg/hg_add_hosts.c:545: undefined reference to `convipv4toipv4mappedaddr'

Please see https://build.opensuse.org/project/show?project=security%3Aopenvas%3AUNSTABLE for the full build logs.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1195&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:48:42 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:48:42 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1196=5D_openvas-li?=
	=?utf-8?q?braries_64bit-portability-issue_network=2Ec=3A1179?=
Message-ID: <20091120014842.7BD9D85D9F67@pyrosoma.intevation.org>

Bugs item #1196, was opened at 2009-11-20 01:48
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: openvas-libraries 64bit-portability-issue network.c:1179 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-libraries
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
The automatic codechecks have a problem with "openvas-libraries 64bit-portability-issue network.c:1179" which prevents the rpms from being created.

Please investigate this.

See https://build.opensuse.org/project/show?project=security%3Aopenvas%3AUNSTABLE for the full build logs.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1196&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:50:18 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:50:18 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1197=5D_openvas-li?=
	=?utf-8?q?braries_bufferoverflow_nasl/nasl=5Fsocket=2Ec=3A256?=
Message-ID: <20091120015018.9248785D9F67@pyrosoma.intevation.org>

Bugs item #1197, was opened at 2009-11-20 01:50
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: openvas-libraries bufferoverflow nasl/nasl_socket.c:256 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-libraries
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
The automatic codechecks have a problem with "openvas-libraries bufferoverflow nasl/nasl_socket.c:256" which prevents the rpms from being created.

Please investigate this.

See https://build.opensuse.org/project/show?project=security%3Aopenvas%3AUNSTABLE for the full build logs.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1197&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:50:49 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:50:49 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1198=5D_openvas-li?=
	=?utf-8?q?braries_bufferoverflow_hg=5Futils=2Ec=3A104?=
Message-ID: <20091120015049.F121085D9F67@pyrosoma.intevation.org>

Bugs item #1198, was opened at 2009-11-20 01:50
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: openvas-libraries bufferoverflow hg_utils.c:104 
Architecture: None
Resolution: None
Severity: None
Version: v3.0-beta
Component: openvas-libraries
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
The automatic codechecks have a problem with "openvas-libraries bufferoverflow hg_utils.c:104" which prevents the rpms from being created.

Please investigate this.

See https://build.opensuse.org/project/show?project=security%3Aopenvas%3AUNSTABLE for the full build logs.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1198&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 02:57:19 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 02:57:19 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1199=5D_Show_the_c?=
	=?utf-8?q?omponent_in_the_bug_page?=
Message-ID: <20091120015719.1263285D9F67@pyrosoma.intevation.org>

Bugs item #1199, was opened at 2009-11-20 01:57
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: Show the component in the bug page 
Architecture: None
Resolution: None
Severity: None
Version: None
Component: None
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
If one files a new bug one can assign a "Component" which is never shown later.

This is somehow confusing if the same issue exists with multiple components since one can't see for which it is filed and for which not.

Please add a field that shows the component in the bug page or even in the bug list.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1199&group_id=29

From openvas-bugs at wald.intevation.org  Fri Nov 20 14:39:47 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Fri, 20 Nov 2009 14:39:47 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1200=5D_OpenVAS-Cl?=
	=?utf-8?q?ient_does_not_retrieve_information_from_LSC_Credentials_?=
	=?utf-8?q?Manager_when_run_in_batch_mode?=
Message-ID: <20091120133947.B8CCF85D9F55@pyrosoma.intevation.org>

Bugs item #1200, was opened at 2009-11-20 14:39
Status: Open
Priority: 3
Submitted By: Robert Veznaver (rveznaver)
Assigned to: Nobody (None)
Summary: OpenVAS-Client does not retrieve information from LSC Credentials Manager when run in batch mode 
Architecture: 64 Bit
Resolution: None
Severity: enhancement
Version: v2.0.5
Component: openvas-client
Operating System: Linux
Product: OpenVAS
Hardware: All
URL: 


Initial Comment:
When running OpenVAS-Client in batch mode using a configuration file which uses SSH keys from LSC Credentials Manager the Local security checks do not run because OpenVAS-Client cannot retrieve SSH key info from LSC Credentials Manager while in batch mode.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1200&group_id=29

From openvas-bugs at wald.intevation.org  Sat Nov 21 10:26:38 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Sat, 21 Nov 2009 10:26:38 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1202=5D_Rules_vali?=
	=?utf-8?q?dation_error?=
Message-ID: <20091121092638.73035865F46E@pyrosoma.intevation.org>

Bugs item #1202, was opened at 2009-11-21 14:56
Status: Open
Priority: 3
Submitted By: Chandrashekhar B (chandra)
Assigned to: Nobody (None)
Summary: Rules validation error 
Architecture: None
Resolution: None
Severity: normal
Version: None
Component: openvas-scanner
Operating System: All
Product: OpenVAS
Hardware: None
URL: 


Initial Comment:
Rules entered in openvassd.rules aren't being properly validated. 

192.168.1.0/24abc is considered as a valid entry. It should reject or show a parse error at the start of the scanner. 

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1202&group_id=29

From openvas-bugs at wald.intevation.org  Tue Nov 24 22:34:52 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Tue, 24 Nov 2009 22:34:52 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1205=5D_=5Bopenvas?=
	=?utf-8?q?-administrator=5D_missing_checks_for_libraries?=
Message-ID: <20091124213452.29F02861EABF@pyrosoma.intevation.org>

Bugs item #1205, was opened at 2009-11-24 21:34
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: [openvas-administrator] missing checks for libraries 
Architecture: None
Resolution: None
Severity: None
Version: None
Component: None
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
In your CMakeLists.txt are checks missing for the following libs:

glib2-devel, libgcrypt, libopnvas-devel, gnutls-devel, libpcap-devel, libgpgme-devel

This results in all kind of strange errors during cmake / make so please add some checks and clear "Lib xyz is required but missing".

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1205&group_id=29

From openvas-bugs at wald.intevation.org  Tue Nov 24 22:52:14 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Tue, 24 Nov 2009 22:52:14 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1206=5D_=5Bopenvas?=
	=?utf-8?q?-administrator=5D_Installation_directories_are_wrong=2E?=
Message-ID: <20091124215214.62896865F4A4@pyrosoma.intevation.org>

Bugs item #1206, was opened at 2009-11-24 21:52
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: [openvas-administrator] Installation directories are wrong. 
Architecture: None
Resolution: None
Severity: None
Version: None
Component: None
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
on Fedora cmake -DCMAKE_INSTALL_PREFIX=%{buildroot}%{_prefix} . results in:

   /usr/bin/openvasad
   /usr/etc/openvas/openvasad_log.conf

cmake -DCMAKE_INSTALL_PREFIX=%{buildroot} . in:

   /bin/openvasad
   /etc/openvas/openvasad_log.conf

and after applying the attached patch (which I'm _not_ sure is the proper solution) it works in Fedora with cmake -DCMAKE_INSTALL_PREFIX=%{buildroot} . but then stuff gets installed into

   /var/tmp/openvas-administrator-0.2.2-build/etc/openvas/openvasad_log.conf
   /var/tmp/openvas-administrator-0.2.2-build/usr/bin/openvasad

(as in it gets installed into %{buildroot}/%{buildroot}/... ).

What I need is a simply way to tell it to install itself bellow %{buildroot} in the same layout it then needs to be bellow / once installed.

Also review the includedir path in the CMakeList since it should be /usr/include, not /include.

Further the libdir path is hardcoded to /usr/lib which shouldn't happen either since most put 64 bit libs into /usr/lib64

E.g. normally stuff is defined like the following:

%_prefix                /usr
%_exec_prefix           %{_prefix}
%_bindir                %{_exec_prefix}/bin
%_sbindir               %{_exec_prefix}/sbin
%_libexecdir            %{_exec_prefix}/libexec
%_datadir               %{_prefix}/share
%_sysconfdir            /etc
%_sharedstatedir        %{_prefix}/com
%_localstatedir         %{_prefix}/var
%_lib                   lib
%_libdir                %{_exec_prefix}/%{_lib}
%_includedir            %{_prefix}/include
%_infodir               %{_datadir}/info
%_mandir                %{_datadir}/man

(on x86_64 %_lib is overridden to lib64) which is prolly how you should define your directories as well (albeight I'm a bit surprised that this is necessary with cmake. Are you sure there isn't a more "natural" way to do it?)

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1206&group_id=29

From openvas-bugs at wald.intevation.org  Tue Nov 24 22:56:03 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Tue, 24 Nov 2009 22:56:03 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1207=5D_=5Bopenvas?=
	=?utf-8?q?-administrator=5D_=25optflags_don=27t_get_used?=
Message-ID: <20091124215603.660A7861EABF@pyrosoma.intevation.org>

Bugs item #1207, was opened at 2009-11-24 21:56
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: [openvas-administrator] %optflags don't get used 
Architecture: None
Resolution: None
Severity: None
Version: None
Component: None
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
Every distro defines a predefined set of compilation flags that get stored in $RPM_OPT_FLAGS but they don't get used during compilation. Instead the flags your hardcoded into your CMakeLists.txt get used.

So either read them out and use them automatically or give me some option for the cmake call to override what compilation flags get used.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1207&group_id=29

From openvas-bugs at wald.intevation.org  Tue Nov 24 23:46:35 2009
From: openvas-bugs at wald.intevation.org (openvas-bugs@wald.intevation.org)
Date: Tue, 24 Nov 2009 23:46:35 +0100 (CET)
Subject: [Openvas-devel] =?utf-8?q?=5Bopenvas-Bugs=5D=5B1208=5D_=5Bopenvas?=
	=?utf-8?q?-manager=5D_missing_checks_for_libraries?=
Message-ID: <20091124224635.7CACA861EABF@pyrosoma.intevation.org>

Bugs item #1208, was opened at 2009-11-24 22:46
Status: Open
Priority: 3
Submitted By: Stephan Kleine (bitshuffler)
Assigned to: Nobody (None)
Summary: [openvas-manager] missing checks for libraries 
Architecture: None
Resolution: None
Severity: None
Version: None
Component: None
Operating System: None
Product: None
Hardware: None
URL: 


Initial Comment:
Checks for the following libraries are missing which results in all kind of strange errors during cmake or make:

glib2-devel, gnutls-devel, libopenvas-devel, libpcap-devel, libgpgme-devel, libuuid-devel

Therefore please add some checks during cmake.

----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=220&aid=1208&group_id=29

From Jan-Oliver.Wagner at greenbone.net  Wed Nov 25 16:56:02 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Wed, 25 Nov 2009 16:56:02 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release candidates
	early dec.
Message-ID: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>

Hello OpenVAS developers,

I'd like to switch over from the 3.0-beta releases to the 3.0-rc release
cycle early december and have the final 3.0.0 at december 18th.

Over here at Greenbone the 3.0-betas work quite reliable. We have
not had any major problems for a while now.  IPv6 needs some tweaks here
and there though.

Thanks to Stephan the packaging aspects are being worked on as well.
At least for the RPM based GNU/Linux distributions.
Even openvas-manager and openvas-administrator seem to have
added to OBS.

No other major flaws were reported for the 3.0 series. So I guess you
are all happy with it ;-)

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 bitdealer at gmail.com  Wed Nov 25 18:30:23 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Wed, 25 Nov 2009 18:30:23 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200911251830.23290.bitdealer@gmail.com>

On Wednesday 25 November 2009 16:56:02 Jan-Oliver Wagner wrote:
> I'd like to switch over from the 3.0-beta releases to the 3.0-rc release
> cycle early december and have the final 3.0.0 at december 18th.

Well, IMHO it is far from RC state. There are known buffer overflows in your 
code in at least 2 packages, on Mandriva nothing builds cause -libraries has 
some linking troubles, -manager & -administrator don't install properly and so 
on.

IMHO you should fix that stuff at least to a point where "not building for 
whatever reason" is the exception, not the rule before considering declaring 
it a RC and then publishing can be enabled and the stuff made available to a 
wider range of testers which then surely leads to another load of reports that 
need to be fixed before release.

That way you at least get a solid release instead of a premature one.

My 0,02$,
Stephan

From timb at openvas.org  Thu Nov 26 01:22:24 2009
From: timb at openvas.org (Tim Brown)
Date: Thu, 26 Nov 2009 00:22:24 +0000
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911251830.23290.bitdealer@gmail.com>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911251830.23290.bitdealer@gmail.com>
Message-ID: <200911260022.27443.timb@openvas.org>

On Wednesday 25 November 2009 17:30:23 Stephan Kleine wrote:
> On Wednesday 25 November 2009 16:56:02 Jan-Oliver Wagner wrote:
> > I'd like to switch over from the 3.0-beta releases to the 3.0-rc release
> > cycle early december and have the final 3.0.0 at december 18th.
>
> Well, IMHO it is far from RC state. There are known buffer overflows in
> your code in at least 2 packages, on Mandriva nothing builds cause
> -libraries has some linking troubles, -manager & -administrator don't
> install properly and so on.
>
> IMHO you should fix that stuff at least to a point where "not building for
> whatever reason" is the exception, not the rule before considering
> declaring it a RC and then publishing can be enabled and the stuff made
> available to a wider range of testers which then surely leads to another
> load of reports that need to be fixed before release.
>
> That way you at least get a solid release instead of a premature one.

Agreed.  RC should be for stableised, builds on common platforms code, and I'm 
yet to see that so far.  I'll try another build on Debian at the weekend and 
see where that leaves us.

Stephan, regarding the overflows, I saw only two reported.. one where sizeof 
was being called on the wrong structure and one where pointer arithmetic 
might be suspect within a loop.  I believe the former has been fixed already 
in trunk, did I miss another one?

I'd also like to squeeze in my work on bindings for libssh before we call a 
halt for OpenVAS 3.0 but that's not a must, just a nice to have.  Lets see 
where we are on Monday morning before we move to a RC.

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

From bitdealer at gmail.com  Thu Nov 26 03:06:02 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Thu, 26 Nov 2009 03:06:02 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911260022.27443.timb@openvas.org>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911251830.23290.bitdealer@gmail.com>
	<200911260022.27443.timb@openvas.org>
Message-ID: <200911260306.02441.bitdealer@gmail.com>

On Thursday 26 November 2009 01:22:24 Tim Brown wrote:
> Stephan, regarding the overflows, I saw only two reported.. one where
>  sizeof was being called on the wrong structure and one where pointer
>  arithmetic might be suspect within a loop.  I believe the former has been
>  fixed already in trunk, did I miss another one?

Sorry Tim, I screwed it up (Felix' new upload for -libaries fixed some). The 
only issue our code checks currently find is in openvas-scanner:

I: Statement is overflowing a buffer
E: openvas-scanner bufferoverflow openvas_tcp_scanner.c:518

I triggered new builds for -libraries and -client, please see 
https://build.opensuse.org/project/monitor?project=security%3Aopenvas%3AUNSTABLE 
for the details.

Regards,
Stephan

From bchandra at secpod.com  Thu Nov 26 05:31:20 2009
From: bchandra at secpod.com (Chandrashekhar B)
Date: Thu, 26 Nov 2009 10:01:20 +0530
Subject: [Openvas-devel] 3.0: Transition from betas to releasecandidates
	early dec.
In-Reply-To: <200911260306.02441.bitdealer@gmail.com>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net><200911251830.23290.bitdealer@gmail.com><200911260022.27443.timb@openvas.org>
	<200911260306.02441.bitdealer@gmail.com>
Message-ID: <B0CC724F34E54813B13CAFF306F7FF7A@bchandra>

Hello Stephen,
 

> -----Original Message-----
> From: openvas-devel-bounces at wald.intevation.org 
> [mailto:openvas-devel-bounces at wald.intevation.org] On Behalf 
> Of Stephan Kleine
> Sent: Thursday, November 26, 2009 7:36 AM
> To: openvas-devel at wald.intevation.org
> Subject: Re: [Openvas-devel] 3.0: Transition from betas to 
> releasecandidates early dec.
> 
> On Thursday 26 November 2009 01:22:24 Tim Brown wrote:
> > Stephan, regarding the overflows, I saw only two reported.. 
> one where  
> > sizeof was being called on the wrong structure and one 
> where pointer  
> > arithmetic might be suspect within a loop.  I believe the 
> former has 
> > been  fixed already in trunk, did I miss another one?
> 
> Sorry Tim, I screwed it up (Felix' new upload for -libaries 
> fixed some). The only issue our code checks currently find is 
> in openvas-scanner:
> 
> I: Statement is overflowing a buffer
> E: openvas-scanner bufferoverflow openvas_tcp_scanner.c:518
> 

This is fixed already, please take the latest code from trunk.


> I triggered new builds for -libraries and -client, please see 
> https://build.opensuse.org/project/monitor?project=security%3A
> openvas%3AUNSTABLE
> for the details.

Chandra.



From Jan-Oliver.Wagner at greenbone.net  Thu Nov 26 10:56:14 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Thu, 26 Nov 2009 10:56:14 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911260022.27443.timb@openvas.org>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911251830.23290.bitdealer@gmail.com>
	<200911260022.27443.timb@openvas.org>
Message-ID: <200911261056.15345.Jan-Oliver.Wagner@greenbone.net>

On Donnerstag, 26. November 2009, Tim Brown wrote:
> Agreed.  RC should be for stableised, builds on common platforms code, and I'm 
> yet to see that so far.  I'll try another build on Debian at the weekend and 
> see where that leaves us.

I've observed the usual problem: as long as versions are "beta" 
the packages are very much hesitating to touch it.

Boldy going ahead with the version number seems to be the
only practical approach to get things moving.

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 bitdealer at gmail.com  Thu Nov 26 11:50:25 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Thu, 26 Nov 2009 11:50:25 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911261056.15345.Jan-Oliver.Wagner@greenbone.net>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911260022.27443.timb@openvas.org>
	<200911261056.15345.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200911261150.25930.bitdealer@gmail.com>

On Thursday 26 November 2009 10:56:14 Jan-Oliver Wagner wrote:
> I've observed the usual problem: as long as versions are "beta"
> the packages are very much hesitating to touch it.
> 
> Boldy going ahead with the version number seems to be the
> only practical approach to get things moving.

I totally agree with you that beta stuff isn't very inviting to test. However, 
fixing the stuff up, ironing out any remaining (build) issues so binaries can 
be provided to all major platforms seems to be more important to me than 
releasing a RC that's mostly only worth to people who are comfortable building 
it from SVN anyways.

Perhaps I'm somehow "oldschool" but IMHO a RC should be in release state so if 
no more issues are found the RC is declared as GA which currently simply can't 
happen for various reasons.

So first fix most if not all found issues so binaries can be made available to 
a wider area of testers and then declare it a RC so people have a good thing 
to test.

Then fix the swamp of bugs that surely comes in and once they are fixed think 
about declaring it a GA so you have a solid one instead or the usual premature 
one (the premature isn't targeted at you but a general observation which is 
even more important since your stuff is a security tool)

My thoughts,
Stephan

From bitdealer at gmail.com  Thu Nov 26 11:58:08 2009
From: bitdealer at gmail.com (Stephan Kleine)
Date: Thu, 26 Nov 2009 11:58:08 +0100
Subject: [Openvas-devel] openvas-manager und openvas-administrator
In-Reply-To: <200911261014.59060.felix.wolfsteller@intevation.de>
References: <200911261014.59060.felix.wolfsteller@intevation.de>
Message-ID: <200911261158.08295.bitdealer@gmail.com>

On Thursday 26 November 2009 10:14:58 Felix Wolfsteller wrote:
> openvas-manager und openvas-administrator sollen idealerweise als
> low-priviledged services unter einem eigenen user laufen. Deswegen
> ist /usr/bin eigentlich das richtige Verzeichnis, init-scripte k?nnen sie
> trotzdem gebrauchen.

No. As long as they are separate services they should run as an unprivileged 
user (that part is right) but a normal user should have no control whatsoever 
about them. All one should be able to do is to connect via some client to them 
and to do ones work.

Therefore they should be in /usr/sbin and _not_ in /usr/bin like it is done 
e.g. for a webserver or e.g. -scanner. As in they normally get turned on and 
off per runlevel via chkconfig without any user intervention.

If you want it user controlled then /usr/bin is the right place but then you 
need no init scripts..

So please fix your install scripts so stuff gets put into /usr/_s_bin, not 
into /usrbin/.

Regards,
Stephan

From Jan-Oliver.Wagner at greenbone.net  Thu Nov 26 12:32:51 2009
From: Jan-Oliver.Wagner at greenbone.net (Jan-Oliver Wagner)
Date: Thu, 26 Nov 2009 12:32:51 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911261150.25930.bitdealer@gmail.com>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911261056.15345.Jan-Oliver.Wagner@greenbone.net>
	<200911261150.25930.bitdealer@gmail.com>
Message-ID: <200911261232.52547.Jan-Oliver.Wagner@greenbone.net>

On Donnerstag, 26. November 2009, Stephan Kleine wrote:
> On Thursday 26 November 2009 10:56:14 Jan-Oliver Wagner wrote:
> > I've observed the usual problem: as long as versions are "beta"
> > the packages are very much hesitating to touch it.
> > 
> > Boldy going ahead with the version number seems to be the
> > only practical approach to get things moving.
> 
> I totally agree with you that beta stuff isn't very inviting to test. However, 
> fixing the stuff up, ironing out any remaining (build) issues so binaries can 
> be provided to all major platforms seems to be more important to me than 
> releasing a RC that's mostly only worth to people who are comfortable building 
> it from SVN anyways.

From the core development point of view it is not so desireable to
have _any_ build issung for the platforms out there resolved before a release
takes place. This could slow down or even stop the innovation cycle.

Of course a good balance needs to be found. Having the tool working only
on the developers preferred platform isn't an option either.
We try to iron out the reported issues very quickly for the packagers.

> Perhaps I'm somehow "oldschool" but IMHO a RC should be in release state so if 
> no more issues are found the RC is declared as GA which currently simply can't 
> happen for various reasons.

well, "oldschool" is to sell the beta to customers and later, maybe, fix the product ;-)

The other "oldschool" (wait for bug-free status before release) has proven to be
suboptimal in practice for most cases. E.g. nmap 5 would not be around and
used if they would not have just released it. Fixing up some things later is OK
to some extend.

> So first fix most if not all found issues so binaries can be made available to 
> a wider area of testers and then declare it a RC so people have a good thing 
> to test.

Whatever "most" means, yes. "all": close to impossible.

> Then fix the swamp of bugs that surely comes in and once they are fixed think 
> about declaring it a GA so you have a solid one instead or the usual premature 
> one (the premature isn't targeted at you but a general observation which is 
> even more important since your stuff is a security tool)

I sincerely hope, the RCs will be tested.
We try our best to solve any properly reported and relevant issue.

Best

	Jan

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

From felix.wolfsteller at intevation.de  Fri Nov 27 12:47:09 2009
From: felix.wolfsteller at intevation.de (Felix Wolfsteller)
Date: Fri, 27 Nov 2009 12:47:09 +0100
Subject: [Openvas-devel] 3.0: Transition from betas to release
	candidates early dec.
In-Reply-To: <200911261056.15345.Jan-Oliver.Wagner@greenbone.net>
References: <200911251656.08605.Jan-Oliver.Wagner@greenbone.net>
	<200911260022.27443.timb@openvas.org>
	<200911261056.15345.Jan-Oliver.Wagner@greenbone.net>
Message-ID: <200911271247.09967.felix.wolfsteller@intevation.de>

Its also difficult to stumble over the news of a new beta if your are not on 
the the openvas-commits mailinglist or watch the homepage or wald VERY 
closely.

We should advertise a beta on freshmeat and/or other channels. Last news there 
(on freshmeat) was in late August. Unfortunately the statistics dont reach 
back that far, but iirc we had around 600 "project clicks" in that days (and 
around ~17 per day since then, with a clear downwards trend). Project/URL 
conversion rate is pretty high (10% i would guess).

-- felix


On Thursday 26 November 2009 10:56:14 Jan-Oliver Wagner wrote:
> On Donnerstag, 26. November 2009, Tim Brown wrote:
> > Agreed.  RC should be for stableised, builds on common platforms code,
> > and I'm yet to see that so far.  I'll try another build on Debian at the
> > weekend and see where that leaves us.
>
> I've observed the usual problem: as long as versions are "beta"
> the packages are very much hesitating to touch it.
>
> Boldy going ahead with the version number seems to be the
> only practical approach to get things moving.
>
> Best
>
> 	Jan


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