Escape string between double quotes

Vulnerability Tests
1

Hi all,

I noticed that some VTs try to build a string that contains escape strings but using double quotes, which then does not be interpreted as expected.

For example, following is some lines of code from the VT sw_apc_default_telnet_credentials.nasl:

if( "American Power Conversion" >< recv || "Network Management Card" >< recv) {
  report += "\n\n" + cred + ":" + creds[cred] + "\n";
  vuln = TRUE;
}
2

For anything passed to log_message() it shouldn’t matter if single or double quotes are used as GVM is able to handle both cases accordingly.

1 Like
3

Hi @cfi, I reported this because I noticed some outputs containing the double quotes literally without being interpreted. I’m not sure if it always happens. I’ll test more and respond back to you later.

2 Likes
4

Mhhh, there might be the chance that something changed in our software stack since the creation of that VT back then in 2015 related to the interpretation of these strings (all recent/newer VTs are usually using single quotes).

Happy to hear about your additional testing results, afterwards we could still update that VT in question to use single quotes for consistency / style reasons :+1:

1 Like
5

Hi there, I tested and confirmed that escape strings in between double quotes are not to be interpreted.

Here is the test code:

str1 = 'Line1\nLine2\nLine3';
str2 = "Line1\nLine2\nLine3";
port = 0;
display( 'str1:' );
security_message( port:port, data:str1 );
display( 'str2:' );
security_message( port:port, data:str2 );

Here is the output:

lib  nasl-Message: 11:11:43.467: str1: 
Line1
Line2
Line3
lib  nasl-Message: 11:11:43.467: str2: 
Line1\nLine2\nLine3

The VT sw_apc_default_telnet_credentials.nasl is just an example, I noticed that there are some other VTs that place escape strings in between double quotes like this.

6

Thanks a lot for your additional effort.

I noticed that the output looks like one from openvas-nasl which is not always behaving the same like doing a “full” scan / having an output how it ends up in the final report presented to the user.

Thus i did an own test on a 21.4.6 setup with a slight modified test case which had added the following to the very beginning of find_service.nasl:

str1 = 'str1: Line1\nLine2\nLine3';
str2 = "str2: Line1\nLine2\nLine3";
display( str1 );
security_message( port:0, data:str1 );
display( str2 );
security_message( port:0, data:str2 );

with the following outcome below.

openvas.log:

lib  nasl:MESSAGE:2023-02-11 09h55.18 utc:15049: str1: Line1
Line2
Line3
lib  nasl:MESSAGE:2023-02-11 09h55.18 utc:15049: str2: Line1
Line2
Line3

GUI / GSA:

Screenshot_2023-02-11_11-04-49
Screenshot_2023-02-11_11-04-491809Ă—755 78.3 KB

PDF report:

Screenshot_2023-02-11_11-07-59
Screenshot_2023-02-11_11-07-59542Ă—897 22.3 KB

Conclusion:

My takeaway from this is that while the VT in question could make use of single instead of double quotes it is not absolutely mandatory:

The data is represented correctly in most cases and only security_message() seems to behave a little bit differently when used via openvas-nasl (which would be something to discuss outside of the Vulnerability Tests category and with the responsible team working on the scanner component).

1 Like