Greetings fellow nginx-devs,
It looks to me as if an attacker could force the server to use up a large
amount of resources doing ngx_http_regex_exec if the server were to be
configured with a relatively large number of regex server_names.
I would appreciate any ideas on the topic, especially suggestions as to how
some form of caching could be implemented for the responses, so that the
server didn't have to execute the ngx_http_regex_exec on subsequent
requests.
2375 for (i = 0; i < virtual_names->nregex; i++) {
2376
2377 n = ngx_http_regex_exec(r, sn[i].regex, host);
2378
2379 if (n == NGX_DECLINED) {
2380 continue;
2381 }
2382
2383 if (n == NGX_OK) {
2384 *cscfp = sn[i].server;
2385 return NGX_OK;
2386 }
2387
2388 return NGX_ERROR;
2389 }
./src/http/ngx_http_request.c
Regards,
Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20240130/b2ff5ff1/attachment.htm>
Hello!
On Tue, Jan 30, 2024 at 10:28:23AM +0200, Clima Gabriel wrote:
> Greetings fellow nginx-devs,
> It looks to me as if an attacker could force the server to use up a large
> amount of resources doing ngx_http_regex_exec if the server were to be
> configured with a relatively large number of regex server_names.
> I would appreciate any ideas on the topic, especially suggestions as to how
> some form of caching could be implemented for the responses, so that the
> server didn't have to execute the ngx_http_regex_exec on subsequent
> requests.
Not using "large number of regex server_names" might be the best
solution available here. Requests are not required to be to the
same virtual server, and caching won't generally work.
--
Maxim Dounin
http://mdounin.ru/