OpenVAS is throwing this regex error

Vulnerability Tests
1

I’m getting hundreds of these in my gvm/openvas.log file using the latest securecompliance/gvm docker container (gvmd 21.4.3, ospd-openvas 21.4.2/21.4.0):

lib nasl:MESSAGE:2021-09-20 16h36.25 utc:4470: 4470 nasl_exec: bad regex at or near line 93
lib nasl:MESSAGE:2021-09-20 16h41.00 utc:11405: 11405(/var/lib/openvas/plugins/2012/secpod_apache_http_srv_cookie_info_disc_vuln.nasl:0) Line 93: Cannot compile regex: Cookie: c[0-9]=X{820}; path=/; (error 10: Invalid contents of {})

2

AFAICT this is a limitation of the regex library used by the scanner host (in this case Alpine linux running within the docker container or more specifically the mus libc of Alpine). See the following discussion for more background info:

Currently there are a few options:

  1. switching the underlying operating system to a Debian / Ubuntu based system where this doesn’t occur
  2. ignoring the log entries as that limitation of musl libc is only affecting a VT from 2012
  3. a third party patch (tested on Alpine and Debian) by the community (posted at https://community.greenbone.net/c/vulnerability-tests/7) to work around this limitation on the regex library side of Apline (if this is possible at all) while keeping compatibility with our reference system (which is Debian).
1 Like
3

Posting this link as a cross-reference:

4

The maintainer of the regex library in Alpine Linux that throws this error suggested that the iterator count of 820 is too large for their implementation. He suggested changing

X{820}

to

(X{82}){10}

which I have briefly tested and which does not display errors. Perhaps the plugin can be modified in this way.

Thanks,

Karl

5

There might be a misunderstanding, at least the suggestion for the regex in https://github.com/Secure-Compliance-Solutions-LLC/GVM-Docker/issues/288#issuecomment-940853663 came from my side.

Nonetheless thanks a lot for the additional testing. I would need to have at least some additional / more throughout testing from some using Alpine to confirm that the workaround is working correctly before pushing it into the feed. I will add some notes how the testing can be done on the issue linked above in a few minutes.