Опубликован (https://www.mail-archive.com/announce@httpd.apache.org/...) релиз HTTP-сервера Apache 2.4.41 (выпуск 2.4.40 был пропущен), в котором представлено 23 изменения (http://www.apache.org/dist/httpd/CHANGES_2.4.41) и устранено 6 уязвимостей (http://httpd.apache.org/security/vulnerabilities_24.html).- CVE-2019-10081 (https://www.mail-archive.com/announce@httpd.apache.org/...) - проблема в mod_http2, которая может привести к повреждению памяти при отправке push-запросов на очень ранней стадии. При использовании настройки "H2PushResource" возможна перезапись области памяти в пуле обработки запросов, но проблема ограничена крахом, так как записываемые данные не основываются на информации, полученной от клиента;
- CVE-2019-9517 (https://www.mail-archive.com/announce@httpd.apache.org/...) - подверженность недавно анонсированной (https://www.opennet.me/opennews/art.shtml?num=51279) DoS-уязвимости в реализациях HTTP/2.
Атакующий может исчерпать доступную процессу память и создать большую нагрузку на CPU, открывая скользящее окно HTTP/2 для отправки сервером данных без ограничений, но при этом держа окно TCP закрытым, что не позволяет фактически записать данные в сокет;- CVE-2019-10098 (https://www.mail-archive.com/announce@httpd.apache.org/...) - проблема в mod_rewrite, позволяющая использовать сервер для проброса обращений на другие ресурсы (open redirect). Некоторые настройки mod_rewrite могут привести к пробросу пользвателя на другую ссылку, закодированную с использованием символа перевода строки внутри параметра, используемого в существующим редиректе. Для блокирования проблемы в RegexDefaultOptions можно использовать флаг PCRE_DOTALL, который теперь выставлен по умолчанию;
- CVE-2019-10092 (https://www.mail-archive.com/announce@httpd.apache.org/...) - возможность совершения межсайтового скриптинга на страницах ошибок, выводимых mod_proxy. На данных страницах в ссылке подставляется полученный из запроса URL, в котором атакующий через экранирование символов может подставить произвольный HTML-код;
- CVE-2019-10097 (https://www.mail-archive.com/announce@httpd.apache.org/...) - переполнение стека и разыменование указателя NULL в mod_remoteip, эксплуатируемое через манипуляции с заголовком протокола PROXY. Атака может быть совершена только со стороны используемого в настройках прокси-сервера, а не через запрос клиента;
- CVE-2019-10082 (https://www.mail-archive.com/announce@httpd.apache.org/...) - уязвимость в mod_http2, позволяющая в момент завершения соединения инициировать чтение содержимого из уже освобождённой области памяти (read-after-free).Наиболее заметные изменения, не связанные с безопасностью:
- В mod_proxy_balancer усилена защита от атак XSS/XSRF со стороны узлов, заслуживающих доверия;
- В mod_session добавлена настройка SessionExpiryUpdateInterval для определения интервала обновления времени истечения жизни сеанса/cookie;- Проведена чистка страниц с ошибками, направленная на исключения вывода на данных страницах информации из запросов;
- В mod_http2 обеспечен учёт значения параметра "LimitRequestFieldSize", который раньше действовал только для проверки полей заголовков HTTP/1.1;
- Обеспечено создание конфигурации mod_proxy_hcheck при его использовании в BalancerMember;
- Сокращено потребление памяти в mod_dav при использовании команды PROPFIND над большой коллекцией;- В mod_proxy и mod_ssl решены проблемы с указанием настроек сертификатов и SSL в внутри блока Proxy;
- В mod_proxy разрешено применение настроек SSLProxyCheckPeer* для всех модулей прокси;
- Расширены возможности модуля mod_md (https://httpd.apache.org/docs/2.4/mod/mod_md.html), разработанного (https://www.opennet.me/opennews/art.shtml?num=47403) проектом Let's Encrypt для автоматизации получения и обслуживания сертификатов с использованием протокола ACME (Automatic Certificate Management Environment):
- Добавлена вторая версия протокола ACMEv2 (https://www.opennet.me/opennews/art.shtml?num=48255), которая теперь применяется по умолчанию и использует (https://community.letsencrypt.org/t/acme-v2-scheduled-deprec...) пустые запросы POST вместо GET.
- Добавлена поддержка проверки на базе расширения TLS-ALPN-01 (RFC 7301, Application-Layer Protocol Negotiation), которое используется в HTTP/2.
- Прекращена поддержка метода проверки 'tls-sni-01'.
- Добавлены команды для настройки и разрыва проверки методом 'dns-01'.
- Добавлена поддержка масок в сертификатах при включении проверки на основе DNS ('dns-01').
- Реализован обработчик 'md-status' и страница с состоянием сертификата "https://domain/.httpd/certificate-status".
- Добавлены директивы "MDCertificateFile" и "MDCertificateKeyFile" для настройки параметров доменов через статические файлы (без поддержки автообновления).
- Добавлена директива "MDMessageCmd" для вызова внешних команд при наступлении событий 'renewed', 'expiring' или 'errored'.
- Добавлена директива "MDWarnWindow" для настройки сообщения с предупреждением об истечении времени действия сертификата;URL: https://www.mail-archive.com/announce@httpd.apache.org/...
Новость: https://www.opennet.me/opennews/art.shtml?num=51298
шо, опять что-то не так с прекрасным http2? Ну кто бы мог подумать! (если бы было, чем)
P.S. господа сочувствующие - не трогайте мои минусы, я рад что среди читателей опеннета не все еще потеряно, но если вы выводите статистику в ноль - я лишаюсь удовольствия наблюдать массовый подрыв пуканов.
О Apache не только DoS проблемы еще RCE
где он используется? вроде везде уже nginx
На большинстве серверов, включая совместно с ngnx, который не умеет в динамику.
Apache тоже не умеет в динамику без модулей и бекендов. Или ты CGI считаешь динамикой?
> Apache тоже не умеет в динамику без модулей и бекендов. Или ты
> CGI считаешь динамикой?Apache умеет в модули, особенно в FCGI модуль, его я и называю динамикой!
nginx unit?
> nginx unit?1 nginx != nginx unit
2 nginx unit - не может в статику
3 nginx unit, как я выяснил в одной из новостных веток ngnx, не похож на FactCGI, в том виде в котором он есть сейчас и предназначен как сервер приложений, а не динамическое дополнение, как FastCGI.
Вы его когда-нибудь вообще использовали?
> Вы его когда-нибудь вообще использовали?Нет. Его даже в openSUSE Tumbleweed не завезли чтобы в него "потыкать палочкой".
OpenLiteSpeed умеет в динамику и статику, умеет htaccess шах и мат!
> OpenLiteSpeed умеет в динамику и статику, умеет htaccess шах и мат!Если бы про него ещё кто-то бы слышал кроме Вас.
Причём тут слышал или нет, главное чтобы работу свою выполнял. (Тоже про него не слышал)
в этом и проблема - он может ее и выполняет, но, чую, при некоторых "если". И вот о них-то хотелось бы послушать кого-то, а не быть первым в беге по граблям.
Согласимся, но всегда кто-то должен быть первым. Apache и ngnix тоже когда-то начинали, а первопроходцы на грабли наступали.
у нас тогда выбора не было.
И к тому же было, к кому обратиться. С апачем мне помогал ank@, с nginx нашей конторе помогал Сысоев.А тут - брень, мани-мани... и не факт что за них не выразят озабоченность, по телефону.
> Причём тут слышал или нет, главное чтобы работу свою выполнял. (Тоже про
> него не слышал)А пруфы где что выполняет и какую именно работу?
Отобразить Hello word?
Начасать языком можно что угодно!
расскажите историю успеха, что-ли?
прикольно. Виртуальный хостинг на OpenLiteSpeed
А с каких пор nginx разучился в fcgi? ngx_http_fastcgi_module существует с версии 0.19 или типа того.
Можете по подробнее?
В нём, как и в Apache, можно подключить wraper php, и получить аналог связки Apache + PHP via FastCGI?
Я никогда не видел такой конфигурации и не слышал про неё. Обычно nginx или прокси апача или nginx + php-frm.
Илюша, у тебя в голове опять какая-то каша. Для справок: fpm расшифровывается как "fastcgi process manager", и никакого другого fcgi-интерфейса к php сто лет уже нет.Похоже, ты просто не в курсе, что такое fastcgi, что такое - cgi, и что Слава КПСС вообще не человек. Почитай уже, пожалуйста, хоть викивракию по теме, а потом уже задавай вопросы.
Возможно, они у тебя в процессе отпадут сами.
> Для справок: fpm расшифровывается как "fastcgi process manager"
> никакого другого fcgi-интерфейса к php сто лет уже нет.zypper se php7-f*
php7-fastcgi | Модуль PHP7 FastCGI
php7-fpm | Модуль PHP7 менеджера процессов FastCGI> Похоже, ты просто не в курсе
Похоже Вы не в курсе чем отличается FastCGI через врапер веб-сервера, за управление которого отвечает веб-сервер и fpm, где веб сервер отдаёт только статику и ничего не знает о php, который сам обрабатывает себя на отдельном демоне.
И то и то FastCGI, не спорю, но реализованы они совершено по разному.
> Похоже Вы не в курсе чем отличается FastCGI через врапер веб-сервера,в курсе. Это не fastcgi - вообще.
Это безнадежно устаревшая гнилая технология, тяжкое наследие времен, когда разработчики пехепе пыжились-пыжылись, но так и не осилили полноценную поддержку этого протокола.
(оно в таком виде даже "запускалось", только для работы было непригодно)собственно, никем кроме пехепе такой уродливый комбайн не использовался, и я в принципе удивлен что suse каким-то образом все еще ухитряется его собрать (он там сто лет как поломан. за полной ненужностью)
Апач - никуда не годный менеджер процессов. Ему бы за своими кое-как уследить. Не надо нагружать его еще и совершенно несвойственной ему деятельностью. php-fpm с этой задачей справляется несравнимо лучше.
> где веб сервер отдаёт только статику и ничего не знает о php,
он _знает_ о php ровно то, что надо знать веб-серверу - как передать ему параметры запроса и как получить ответ. И работает это через mod_proxy_fcgi, а не через mod_fcgi, порождение спящего разума.
Оно примерно так же "эффективно" и "надежно" как nginx'овый fcgiwrap. Можно пользоваться только с горя, унаследовав хайлоад-код на php версии 4.3
nginx имеет динамику, особенно fastcgi (ведь ты его называешь динамикой)
> nginx имеет динамику, особенно fastcgi (ведь ты его называешь динамикой)Можете привести пример конфигурации, или ссылку на такой пример, где nginx работает с PHP именно как FastCGI через врапер, а не через php-fpm, который берёт на себя всю "динамику", о которой ngnx даже не знает?
> ngnx, который не умеет в динамику.Ой, а это кто? Если очепятка и речь про nginx -- главное, нашим экземплярам не говорите, а то они пока ещё всё умеют: http://altlinux.org/nginx/fcgiwrap
PS AOT: сабж позавчера ещё приехал...
ну ты правда думаешь что открыл кому-то америку? fcgiwrap - уродливая и совершенно неэффективная поделка, сводящая весь тот nginx обратно к апачу с suexec, привет 1997й. Да и надежность ее вызывает определенные сомнения в том, что к этому неловимому джо всерьез подбирались.Разработчики (кто бы они сегодня ни были) ниасилили ничего подобного в самом nginx, и не просто так.
так что я бы с интересом поизучал litespeed, если бы подвернулась подходящая кошка.
Интересно, у них документация на их чудо-апи где-то в человеческом виде есть, или как всегда?
> ну ты правда думаешь что открыл кому-то америку?Ну мало ли.
ну в принципе, да - вон некоторые вообще эксгумировали труп пятитысячелетней тухлости, как я погляжу - и зачем-то держатся за него руками и ногами.Это ж надо - mod_fcgi...
Михаил!
Но вот от Вас такого детского стиля я ник не ожидал. :-(
Расскажите тогда подробнее о fcgiwrap
В нём, как и в Apache, можно подключить wraper php, и получить аналог связки Apache + PHP via FastCGI?
> ngnx, который не умеет в динамикуCloudflare это расскажите, и еще очень много кому, например Kong (https://konghq.com/solutions/gateway/)
То что динамика на PHP - это лучше к Апачу, это не про динамику, это про динамику начала двухтысячных.
>проблема в mod_http2, которая может привести к повреждению памяти при отправке push-запросов на очень ранней стадииНу это просто пушка!