Опубликован (https://www.mail-archive.com/announce@httpd.apache.org/...) релиз HTTP-сервера Apache 2.4.39, в котором представлено 18 изменений (http://www.apache.org/dist/httpd/CHANGES_2.4.39) и устранено 7 уязвимостей (http://httpd.apache.org/security/vulnerabilities_24.html).Наиболее опасная уязвимость (CVE-2019-0211 (https://security-tracker.debian.org/tracker/CVE-2019-0211)) позволяет локальному злоумышленнику (например, пользователю хостинга), имеющему возможность выполнить свой скрипт под управлением web-сервера (в том числе через mod_php, mod_lua, mod_perl и т.п.), добиться выполнения кода с правами управляющего процесса, обычно запускаемого с привилегиями root. Проблема проявляется при применении MPM-модулей event, worker или prefork и может быть эксплуатирована через через манипуляции с областью scoreboard, применяемой для организации взаимодействия между дочерним и родительским процессом Уязвимость проявляется начиная с выпуска 2.4.17.
Другие уязвимости:- CVE-2019-0217 - возможность обхода средств разграничения доступа в mod_auth_digest. Злоумышленник, обладающий корректными параметрами входа, может получить доступ под другим именем пользователя. Проблема вызвана созданием состояния гонки (race condition) при запуске mod_auth_digest на сервере, работающем в многопоточном режиме. Проблема проявляется во всех выпусках ветки 2.4;
- CVE-2019-0215 - обход ограничений доступа в mod_ssl. При использовании привязки клиентского сертификата к пути или каталогу (настройки Location и Directory) в случае применения TLSv1.3 пользователь с поддержкой аутентификации после завершения согласования соединения (Post-Handshake Authentication) может обойти установленные ограничения доступа. Проблема затрагивает только выпуски 2.4.37 и 2.4.38;
- CVE-2019-0197 - отказ в обслуживании (крах процесса) через манипуляцию с запросами HTTP/2 (попытка обновить соединение http/1.1 до http/2, в случае если это не первый запрос в цепочке). Проблема проявляется в 2.4.34 и более новых выпусках на серверах с включенным модулем mod_http2;- CVE-2019-0196 - чтение из уже освобождённой области памяти в mod_http2. Проблема проявляется начиная с выпуска 2.4.18 и может привести к краху при обработке определённым образом оформленных запросов;
- CVE-2019-0220 - различное поведение при нормализация запросов с повторяющимися слешами ('//'). Директивы LocationMatch и RewriteRule требуют явной обработки дубликатов в регулярных выражениях, в то время как в остальных директивах дубликаты автоматически объединяются. Проблема проявляется во всех выпусках ветки 2.4. Начиная с текущего выпуска слеши в URL всегда объединяются, но отключить это поведение можно при помощи настройки "MergeSlashes OFF".
Обновления пакетов с устранением уязвимостей уже доступны во FreeBSD (http://www.vuxml.org/freebsd/cf2105c6-551b-11e9-b95c-b499bae...). Проблемы пока остаются неисправленными в SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-0211), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-0211), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1694986), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...) и Debian (https://security-tracker.debian.org/tracker/CVE-2019-0211).
Наиболее заметные изменения, не связанные с безопасностью:- В mod_log_config добавлена поддержка подстановок "%{c}h" для хоста принявшего соединение (conn-hostname) и "%h" для хоста подключившегося пользователя (useragent_host);
- Добавлен модуль mod_socache_redis для хранения совместного кэша объектов (socache, Shared Object Cache, например используется для SSLSessionCache и SSLStaplingCache) в СУБД Redis;- Добавлена новая настройка 'MergeSlashes on|off' для управления объединением дублирующихся символов '/' в URL поступившего запроса;
- В mod_http2 реализована новая настройка "H2Padding numbits", где numbits значение от 0 до 8, для управления добавочным заполнением блоков HTTP/2;- Из mod_http2 удалён внутренний API h2_req_engine, который больше не требуется для работы mod_proxy_http2. Полностью переработана реализация модуля mod_proxy_http2;
- В mod_http2 реализована возможность указания настроек H2Push и H2Upgrade в контексте блоков Location и Directory, что позволяет отключить метод PUSH для определённого набора ресурсов;- В mod_reqtimeout добавлена возможность задания таймаутов для
этапа согласования TLS-соединений;- В mod_proxy_wstunnel налажена работа прокси для проброса websocket поверх UDS.
URL: https://www.mail-archive.com/announce@httpd.apache.org/...
Новость: https://www.opennet.me/opennews/art.shtml?num=50447
Именно поэтому я не использую HTTP/2 и TLSv1.3. Ещё лет 5 пройдёт пока в них все ошибки вычистят.
Усложнения никогда до добра не доводят.
Так можно и с деревьев не слезать было.
Можно. Но не нужно.
Не слезай, да.
И что же такого усложнилось в TLS 1.3?
HTTP/2 согласен, TLS 1.3 же зря
еще пять месяцев и мы начнем помечать тебя как небезопасТный, и выбросим из индексации!Ишь че удумал, соскочить с телеги прогресса! (_нашей_ телеги - и мы ее пассажиров доим)
> Именно поэтому я не использую HTTP/2 и TLSv1.3Ну так используюй nginx в качестве фронтенда. А внутри можно и по http данные передавать, всё равно внутри машины или через локальную сеть. Хотя, самым лучшим вариантом будет вообще выкинуть Apache, но это уже от вашего приложения зависит.
Не обязательно нгинх, можно хапрокси.
Если бы Апач был на Rust, дыры находили бы также? Или нет? И был бы он также быстр? Или нет?
Да.
Это зависит не столько от языка, сколько от радиуса кривизны рук.
Просто Rust вроде как защищает от всяких ошибок памяти и прочего, так говорят, по крайней мере. Я вот думаю попробовать, но интересно, насколько это всё правда, может лучше писать на старом-добром Си? А то ведь так-то ошибки все совершают, даже опытные
Пока не сравнишь сам — не поймёшь.
Начни с синтаксиса. Лично мне от одного уже синтаксиса всех этих новомодных поделок хочется выблеваться...
Пока я мельком читал растбук, походит на функциональные языки, помню в универе лабы на хаскелл и мл писали, тоже были всякие let.А так, если ценою синтаксиса можно победить ошибки безопасности, почему нет?
>Добавлен модуль mod_socache_redisДобавить-то добавили, только в доках нет ни слова про его настройки. Нет упоминаний ни на сайте, ни в исходниках. Как говорится: пользуйтесь на здоровье.
хм, только сейчас заметил его. А какая у него транскрипция, мод сосач, ммммм...
https://httpd.apache.org/docs/trunk/tr/socache.html
https://httpd.apache.org/docs/trunk/tr/mod/mod_socache_redis...
https://httpd.apache.org/docs/trunk/tr/mod/mod_ssl.html#ssls...
>обычно запускаемого с привилегиями rootа вот за такое надо увольнять. Потому что все необходимые механизмы уже давно есть.
>Обновления пакетов с устранением уязвимостей уже доступны во FreeBSD.Т.е. под OpenBSD он вообще не идёт?
под опенок свое наклепают. эх а когда то апач был всем и вся)) правда даже тогда его ломали постоянно))
"... добиться выполнения кода с правами управляющего процесса, обычно запускаемого с привилегиями root.". Прошу прощения, за, возможно, глупый вопрос, а в каких системах Apache-сервер запускают "обычно" с правами системного администратора (root)? Это неточность в статье?
> Прошу прощения, за, возможно, глупый вопросфеерически глупый, ага.
> а в каких системах Apache-сервер запускают "обычно" с правами системного администратора (root)
во всех, кроме винды.
> Это неточность в статье?
нет, это твоя неграмотность.
workers - да, работают не от рута. И весь смысл "уязвимости" - что внезапно можно получить обратно права, которые они успешно сбросили перед запуском юзерского кода. Учитывая, что гадюшники где юзеры занимаются взломом сервера а не работой, уже практически преданья старины глубокой, да и там есть мильен способов нагадить, помимо самого сервера, кое-как затыкаемые бесконечным костылингом без особых гарантий, оно актуально разьве что на случай пролома твоего сервера извне - когда уже в общем-то не о чем особенно скорбеть, можно перезаливаться с бэкапа, не забыв напоследок обналичить пару карт зашедших что-то прикупить клиентов - потом на хакеров свалишь.