Closed karlffox closed 2 years ago
As researched in https://github.com/greenbone/gvmd/issues/1667 this seems to be coming from a limitation in the musl libc of Alpine related to this:
X{820}
It seems that there is a limitation in the regex library used on Alpine which can't handle such a huge number of repetitions in {}
.
Maybe some one having such an Alpine setup can try something like e.g. the following:
(X{82}){10}
https://regexper.com/#%28X%7B82%7D%29%7B10%7D
which could work around this limitation.
We are currently working on a new Debian version on the dev
branch, if you have a workaround this limitation of alpine, then please fork and submit a pull request.
A workaround would be required to be submitted to the Greenbone feed side. If some one is able to test and confirm the previously mentioned suggestion i'm happy to push a fix on Greenbone feed side.
Will do a patch for the src and test it once I have time.
Thank you.
Von meinem iPhone gesendet
Am 12.10.2021 um 17:23 schrieb cfi-gb @.***>:
A workaround would be required to be submitted to the Greenbone feed side. If some one is able to test and confirm the previously mentioned suggestion i'm happy to push a fix on Greenbone feed side.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.
I just updated my ticket with Greenbone, suggesting making the X{820} -> (X{82}){10} change to their plugin. I have implemented a filter to my Greenbone plugin feed that does exactly that edit, and it does indeed prevent the error message. I have no way to test whether it is actually working properly, though.
I consider this issue closed. Thank you for providing me what I needed.
Karl
@karlffox can you add the ticket link in this issue?
As researched in https://github.com/greenbone/gvmd/issues/1667 this seems to be coming from a limitation in the musl libc of Alpine related to this:
X{820}
It seems that there is a limitation in the regex library used on Alpine which can't handle such a huge number of repetitions in
{}
.Maybe some one having such an Alpine setup can try something like e.g. the following:
(X{82}){10}
https://regexper.com/#%28X%7B82%7D%29%7B10%7D
which could work around this limitation.
https://regexper.com/#%28X%7B82%7D%29%7B10%7D%20X%7B820%7D
But this would not be the same result!
Or do I'm currently see this wrong?
The regex should work the same way:
Basically X{820}
says that X
needs to be included 820 times in the response.
The same should work for (X{82}){10}
because it says X
should be included 82 times ((X{82})
in the response multiplied by 10 ({10}
).
Below is a reproducing .nasl script, maybe some one with an Alpine docker installation and having access to openvas-nasl
in that environment can check that:
res = "Cookie: c1=" + crap( 820 ) + "; path=/; ";
res += '\n400 Bad Request';
res += '\nSize of a request header field exceeds server limit';
# nb: The default regex
if(res && "400 Bad Request" >< res &&
res =~ "Cookie: c[0-9]=X{820}; path=/;" &&
"Size of a request header field exceeds server limit" >< res)
display("Default regex works / matches");
# nb: Workaround regex for Alpine
if(res && "400 Bad Request" >< res &&
res =~ "Cookie: c[0-9]=(X{82}){10}; path=/;" &&
"Size of a request header field exceeds server limit" >< res)
display("Workaround regex for Alpine works / matches");
This can be launched like e.g.:
openvas-nasl -X regex.nasl
and gives the following on my Debian system:
lib nasl-Message: 10:52:38.646: Default regex works / matches
lib nasl-Message: 10:52:38.647: Workaround regex for Alpine works / matches
and on Alpine it probably throws the previously mentioned error for the first regex but the second string should be included.
Describe the bug The GVM plugin
throws the following error every time it is run from the securecompliance/gvm:21.4.3-v1-data container:
I filed this with Greenbone and they sent the following reply:
To Reproduce Steps to reproduce the behavior:
Expected behavior The regular expression should be parsed and the plugin should complete without error.
Host Device: Host:
Image in use:
Additional context The code in secpod_apache_http_srv_cookie_info_disc_vuln.nasl that fails: