Mailing List Archive: Nessus: plugins

Unpredictable behavior of uninitialized named arguments

Index | Next | Previous | View Threaded

nnposter at users

Aug 31, 2008, 12:15 PM

Post #1 of 7 (2384 views)
Permalink

Unpredictable behavior of uninitialized named arguments

Named function arguments exhibit a questionable behavior in that when not specified in the call they behave as if they were undeclared variables, i.e. they will have values from higher calling contexts. According to the NASL2 Reference Manual they should instead behave like local variables. Consider the following code:

function func_one (x)
{
local_var y;
# x is optional with a default value of 11
y=x;
if (isnull(x)) y=11;
display('func_one y="'+y+'"\n');
return 0;
}

function func_two ()
{
return func_one();
}

function func_three ()
{
local_var x;
x=22;
return func_two();
}

func_three();

Here the expected output is:

func_one y="11"

because func_two() calls func_one() without specifying named argument "x" but the real output is:

func_one y="22"

and the reason is that it just happens that func_three() is using "x" as its own local variable.

This behavior has been observed in Nessus 2.2.11. If this is not a bug but a feature then the implication is that all named arguments must be always specified in the function call because their values would be otherwise unpredictable. Unfortunately several included functions, such as der_decode() in kerberos_func.inc, are coded (and called) in a way that collides with the observed named argument behavior. In summary, there is a bug either in the NASL interpreter or in the included functions.

Cheers,
nnposter
_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

mikhail at nessus

Sep 2, 2008, 4:59 AM

Post #2 of 7 (2268 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

On Sunday 31 August 2008 21:15:27 nnposter [at] users wrote:
> Named function arguments exhibit a questionable behavior in that when not
> specified in the call they behave as if they were undeclared variables,
> i.e. they will have values from higher calling contexts.

This has always been the behavior in NASL2.
This was changed in Nessus3.

_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

nnposter at users

Sep 13, 2008, 12:15 PM

Post #3 of 7 (2228 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

"Michel Arboi" wrote:
> On Sunday 31 August 2008 21:15:27 nnposter [at] users wrote:
> > Named function arguments exhibit a questionable behavior in that when not
> > specified in the call they behave as if they were undeclared variables,
> > i.e. they will have values from higher calling contexts.
>
> This has always been the behavior in NASL2.
> This was changed in Nessus3.

I understand that the development is focusing on 3.x but are there any chances of getting it fixed? Either way? As it stands now most of the X.509 functions are broken in 2.x.

Cheers,
nnposter
_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

mikhail at nessus

Sep 14, 2008, 7:16 AM

Post #4 of 7 (2228 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

On Sat, 13 Sep 2008 15:15:27 -0400
nnposter [at] users wrote:

> I understand that the development is focusing on 3.x but are there
> any chances of getting it fixed? Either way?

This is not a bug, why should it be "fixed"?
IIRC, I added some code which printed a warning if a variable was found
in an upper context, but I don't remember if it is present in any 2.2
release.

> As it stands now most of the X.509 functions are broken in 2.x.

What do you mean by "broken"?
_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

nnposter at users

Sep 14, 2008, 9:10 PM

Post #5 of 7 (2230 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

"Michel Arboi" wrote:
> On Sat, 13 Sep 2008 15:15:27 -0400
> nnposter [at] users wrote:
>
> > I understand that the development is focusing on 3.x but are there
> > any chances of getting it fixed? Either way?
>
> This is not a bug, why should it be "fixed"?

As I already said in the original message some of the included functions do not take this behavior into account and are broken under 2.x. See below for an example.

> IIRC, I added some code which printed a warning if a variable was found
> in an upper context, but I don't remember if it is present in any 2.2
> release.
>
> > As it stands now most of the X.509 functions are broken in 2.x.
>
> What do you mean by "broken"?

As an example, der_decode() from kerberos_func.inc looks like this:

function der_decode (data, pos)
{
...
if (isnull (pos))
j = 0;
else
j = pos;
...
}

This function is called by a number of parse_XXX() functions from x509_func.inc without specifying parameter "pos", i.e. relying on pos=0 by default. These functions are in turn called by other functions, such as parse_publickey_info() or parse_tbs_certificate(), that have their own "pos". This higher-up "pos" is then erroneously used by der_decode().

Makes sense?

Cheers,
nnposter
_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

npouvesle at tenablesecurity

Sep 15, 2008, 6:13 AM

Post #6 of 7 (2227 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

On Sep 15, 2008, at 6:10 AM, nnposter [at] users wrote:
>
>> IIRC, I added some code which printed a warning if a variable was
>> found
>> in an upper context, but I don't remember if it is present in any 2.2
>> release.
>>
>>> As it stands now most of the X.509 functions are broken in 2.x.
>>
>> What do you mean by "broken"?
>
> As an example, der_decode() from kerberos_func.inc looks like this:
>
> function der_decode (data, pos)
> {
> ...
> if (isnull (pos))
> j = 0;
> else
> j = pos;
> ...
> }
>
> This function is called by a number of parse_XXX() functions from
> x509_func.inc without specifying parameter "pos", i.e. relying on
> pos=0 by default. These functions are in turn called by other
> functions, such as parse_publickey_info() or
> parse_tbs_certificate(), that have their own "pos". This higher-up
> "pos" is then erroneously used by der_decode().

ssl_ciphers.nasl and x509_func.inc have been developed to replace
ssl_ciphers.nes starting with Nessus 3.2.1 :

if ( NASL_LEVEL < 3208 ) exit(0);

So x509_func.inc is not intended to work with Nessus 2.

Nicolas

_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

nnposter at users

Sep 16, 2008, 6:41 AM

Post #7 of 7 (2214 views)
Permalink

Re: Unpredictable behavior of uninitialized named arguments [In reply to]

"Nicolas Pouvesle" wrote:
> On Sep 15, 2008, at 6:10 AM, nnposter [at] users wrote:
> >
> >> IIRC, I added some code which printed a warning if a variable was
> >> found
> >> in an upper context, but I don't remember if it is present in any 2.2
> >> release.
> >>
> >>> As it stands now most of the X.509 functions are broken in 2.x.
> >>
> >> What do you mean by "broken"?
> >
> > As an example, der_decode() from kerberos_func.inc looks like this:
> >
> > function der_decode (data, pos)
> > {
> > ...
> > if (isnull (pos))
> > j = 0;
> > else
> > j = pos;
> > ...
> > }
> >
> > This function is called by a number of parse_XXX() functions from
> > x509_func.inc without specifying parameter "pos", i.e. relying on
> > pos=0 by default. These functions are in turn called by other
> > functions, such as parse_publickey_info() or
> > parse_tbs_certificate(), that have their own "pos". This higher-up
> > "pos" is then erroneously used by der_decode().
>
>
> ssl_ciphers.nasl and x509_func.inc have been developed to replace
> ssl_ciphers.nes starting with Nessus 3.2.1 :
>
> if ( NASL_LEVEL < 3208 ) exit(0);
>
> So x509_func.inc is not intended to work with Nessus 2.

It seems that by simply renaming these higher-up local "pos"
variables I was able to make x509_func.inc work under 2.x. Is there
a reason not to implement this change? (I will be happy to provide
a patch.)

A second question is regarding kerberos_func.inc: The origin of the
problem is really the use of optional parameters in der_decode() from
kerberos_func.inc so should we assume that kerberos_func.inc is also
not intended for 2.x?

Cheers,
nnposter
_______________________________________________
Plugins-writers mailing list
Plugins-writers [at] list
http://mail.nessus.org/mailman/listinfo/plugins-writers

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads