Mailing List Archive

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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
On Sunday 31 August 2008 21:15:27 nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
"Michel Arboi" wrote:
> On Sunday 31 August 2008 21:15:27 nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
On Sat, 13 Sep 2008 15:15:27 -0400
nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
"Michel Arboi" wrote:
> On Sat, 13 Sep 2008 15:15:27 -0400
> nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
On Sep 15, 2008, at 6:10 AM, nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers
Re: Unpredictable behavior of uninitialized named arguments [ In reply to ]
"Nicolas Pouvesle" wrote:
> On Sep 15, 2008, at 6:10 AM, nnposter@users.sourceforge.net 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@list.nessus.org
http://mail.nessus.org/mailman/listinfo/plugins-writers