From pluknet на nginx.com Wed May 29 15:11:04 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:11:04 +0400 Subject: nginx-1.27.0 Message-ID: Изменения в nginx 1.27.0 29.05.2024 *) Безопасность: при использовании HTTP/3 обработка специально созданной QUIC-сессии могла приводить к падению рабочего процесса, отправке клиенту содержимого памяти рабочего процесса на системах с MTU больше 4096 байт, а также потенциально могла иметь другие последствия (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). Спасибо Nils Bars из CISPA. *) Добавление: директивы proxy_limit_rate, fastcgi_limit_rate, scgi_limit_rate и uwsgi_limit_rate поддерживают переменные. *) Исправление: уменьшено потребление памяти для долгоживущих запросов, если используются директивы gzip, gunzip, ssi, sub_filter или grpc_pass. *) Исправление: nginx не собирался gcc 14, если использовался параметр --with-atomic. Спасибо Edgar Bonet. *) Исправления в HTTP/3. -- Sergey Kandaurov From pluknet на nginx.com Wed May 29 15:11:09 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:11:09 +0400 Subject: nginx-1.26.1 Message-ID: Изменения в nginx 1.26.1 29.05.2024 *) Безопасность: при использовании HTTP/3 обработка специально созданной QUIC-сессии могла приводить к падению рабочего процесса, отправке клиенту содержимого памяти рабочего процесса на системах с MTU больше 4096 байт, а также потенциально могла иметь другие последствия (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). Спасибо Nils Bars из CISPA. *) Исправление: уменьшено потребление памяти для долгоживущих запросов, если используются директивы gzip, gunzip, ssi, sub_filter или grpc_pass. *) Исправление: nginx не собирался gcc 14, если использовался параметр --with-atomic. Спасибо Edgar Bonet. *) Исправление: в HTTP/3. -- Sergey Kandaurov From pluknet на nginx.com Wed May 29 15:11:14 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 29 May 2024 19:11:14 +0400 Subject: nginx security advisory (CVE-2024-31079, CVE-2024-32760, CVE-2024-34161, CVE-2024-35200) Message-ID: <28C39CE9-6926-4322-8B11-7325B0981FED@nginx.com> Hello! В реализации HTTP/3 в nginx были обнаружены четыре проблемы, которые позволяют атакующему с помощью специально созданной QUIC-сессии вызвать падение рабочего процесса (CVE-2024-31079, CVE-2024-32760, CVE-2024-35200), отправку клиенту части содержимого памяти рабочего процесса на системах с MTU больше 4096 байт (CVE-2024-34161), а также потенциально могут иметь другие последствия (CVE-2024-31079, CVE-2024-32760). Проблемам подвержен nginx, если он собран с экспериментальным модулем ngx_http_v3_module (по умолчанию не собирается) и в конфигурационном файле используется параметр quic директивы listen. Проблемам подвержен nginx 1.25.0-1.25.5, 1.26.0. Проблемы исправлены в nginx 1.27.0, 1.26.1. Спасибо Nils Bars из CISPA. -- Sergey Kandaurov From jd на artdesign.ru Wed May 29 17:53:26 2024 From: jd на artdesign.ru (Vladimir Sopot) Date: Wed, 29 May 2024 20:53:26 +0300 Subject: merge_slashes In-Reply-To: <7E2C1C99-D3E5-4BA2-9AC9-98599D113295@nginx.com> References: <278BFB58-BB1B-430E-89D0-393BE6691FAF@artdesign.ru> <7E2C1C99-D3E5-4BA2-9AC9-98599D113295@nginx.com> Message-ID: И как быть, если мне в одном из серверов необходимо иметь два подряд идущих слэша? Это purge для кэша, который зависит от cookies пользователя, которые, естественным образом могут быть пустыми. > On 24 Apr 2024, at 19:24, Roman Arutyunyan wrote: > > Добрый день, > >> On 16 Apr 2024, at 11:41 PM, Vladimir Sopot > wrote: >> >> Здравствуйте! >> >> Есть примерно такой упрощённый конфиг и при обращении к some.local////////some.html merge_slashes не работает. Если в первом сервере убрать merge_slashes off, то всё работает нормально и во втором сервере. >> Почему так? nginx version: nginx/1.25.3 > > На момент парсинга строки запроса, nginx еще не знает о том, какой виртуальный сервер будет выбран и использует настройки дефолтного. > > Если вы включите ssl, то ситуация будет другой. > >> >> http { >> merge_slashes on; >> } >> >> server { >> listen 127.0.0.1:80 default_server; >> server_name 127.0.0.1 _ ""; >> >> merge_slashes off; >> allow 127.0.0.1; >> deny all; >> >> location /nginx_status { >> stub_status on; >> } >> >> …. много location >> >> } >> >> server { >> listen *:80; >> server_name some.local; >> >> …. много location >> >> } >> >> Best, VS >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru > > ---- > Roman Arutyunyan > arut на nginx.com > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From arut на nginx.com Thu May 30 14:36:02 2024 From: arut на nginx.com (Roman Arutyunyan) Date: Thu, 30 May 2024 18:36:02 +0400 Subject: merge_slashes In-Reply-To: References: <278BFB58-BB1B-430E-89D0-393BE6691FAF@artdesign.ru> <7E2C1C99-D3E5-4BA2-9AC9-98599D113295@nginx.com> Message-ID: Добрый день, > On 29 May 2024, at 9:53 PM, Vladimir Sopot wrote: > > И как быть, если мне в одном из серверов необходимо иметь два подряд идущих слэша? Это purge для кэша, который зависит от cookies пользователя, которые, естественным образом могут быть пустыми. Самый простой способ - использовать TLS с SNI. В таком случае выбор сервера будет происходить на этапе хендшейка TLS. Теоретически можно изменить поведение nginx таким образом, чтобы при указании полного uri в строке запроса выбор сервера происходил до обработки uri, и это вам поможет. Но это требует осторожности и анализа возможных последствий. И в этом случае marge_slashes будет работать по-разному в строке запроса и в заголовке Host, что тоже не очень хорошо. > >> On 24 Apr 2024, at 19:24, Roman Arutyunyan wrote: >> >> Добрый день, >> >>> On 16 Apr 2024, at 11:41 PM, Vladimir Sopot > wrote: >>> >>> Здравствуйте! >>> >>> Есть примерно такой упрощённый конфиг и при обращении к some.local////////some.html merge_slashes не работает. Если в первом сервере убрать merge_slashes off, то всё работает нормально и во втором сервере. >>> Почему так? nginx version: nginx/1.25.3 >> >> На момент парсинга строки запроса, nginx еще не знает о том, какой виртуальный сервер будет выбран и использует настройки дефолтного. >> >> Если вы включите ssl, то ситуация будет другой. >> >>> >>> http { >>> merge_slashes on; >>> } >>> >>> server { >>> listen 127.0.0.1:80 default_server; >>> server_name 127.0.0.1 _ ""; >>> >>> merge_slashes off; >>> allow 127.0.0.1; >>> deny all; >>> >>> location /nginx_status { >>> stub_status on; >>> } >>> >>> …. много location >>> >>> } >>> >>> server { >>> listen *:80; >>> server_name some.local; >>> >>> …. много location >>> >>> } >>> >>> Best, VS >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru на nginx.org >>> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> ---- >> Roman Arutyunyan >> arut на nginx.com >> >> >> >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ---- Roman Arutyunyan arut на nginx.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From jd на jdwuzhere.ru Thu May 30 15:49:39 2024 From: jd на jdwuzhere.ru (jd на jdwuzhere.ru) Date: Thu, 30 May 2024 18:49:39 +0300 Subject: merge_slashes In-Reply-To: References: Message-ID: Вложение в формате HTML было извлечено… URL: