LINUX.ORG.RU

Десятки уязвимостей в Squid не могут исправить уже 2,5 года

 ,


0

3

Более двух лет прошло с момента обнаружения 35 уязвимостей в кеширующем прокси Squid, и большинство из них до сих пор не устранено, предупреждает эксперт по безопасности, который первым сообщил о данных проблемах.

В феврале 2021 года специалист по безопасности Джошуа Роджерс провел анализ Squid и выявил 55 уязвимостей в коде проекта.

К настоящему времени были устранены всего 20 из них. Основная часть уязвимостей так и не получила обозначений CVE, что означает отсутствие официальных исправлений или рекомендаций по их устранению. Роджерс в письме к сообществу безопасности Openwall сказал, что после долгого ожидания он решил опубликовать эту информацию.

Роджерс детализировал уязвимости на своем сайте, подчерчеркнув разнообразие проблем – использование после освобождения (Use-After-Free), утечка памяти (memory leak), отравление кэша (cache poisoning), ошибка утверждения (assertion failure) и другие недостатки в различных компонентах. При этом специалист выразил понимание к команде Squid, отметив, что многие разработчики open-source проектов работают на волонтерских началах и не всегда могут оперативно реагировать на подобные проблемы.

Стоит отметить, что Squid в настоящее время используется в миллионах экземпляров по всему миру.

Рекомендации Роджерса подразумевают, что каждый пользователь должен самостоятельно оценить, подходит ли Squid для их системы. В противном случае пользователи могут столкнуться со сбоями и рисками в области информационной безопасности.

Эта ситуация напоминает всем нам о важности регулярного обновления и обеспечения безопасности программного обеспечения. В противном случае, как подчеркивает Роджерс, «толку от этого не будет».

Этот беспокойный эпизод поднимает серьезные вопросы о безопасности открытых проектов и их способности справляться с непрекращающимся потоком новых уязвимостей.

Остается надеяться, что участники сообщества и разработчики примут неотложные меры для устранения этой угрозы в будущем.

Письмо Джошуа на Openwall (англ.)

Детализация проблем на сайте Джошуа (англ.)

>>> Подробности (securitylab.ru)



Проверено: hobbit ()
Последнее исправление: Virtuos86 (всего исправлений: 4)

Ответ на: комментарий от cumvillain

nginx

Ну его можно настроить как reverse proxy, и даже как forward proxy для http, используя магию его конфигов, но не уверен, что это прокатит для https)

goingUp ★★★★★
()
Ответ на: комментарий от firkax

Для начала надо выяснить зачем тебе прокси

Мне прокси не нужен, мне интересно на что сегодня заменяют squid люди, которые его выкидывают)

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

используя магию его конфигов

Там пять строк надо сказать, это элементарно делается.

но не уверен, что это прокатит для https

Это прокатит для чего угодно, nginx прекрасно работает tls-терминатором с обеих сторон.

cumvillain
()
Ответ на: комментарий от firkax

Я думаю эти миллионы экземпляров - это компании, которые используют его для контроля доступа. Корпоративный интернет до сих пор часто бывает обрезан, а руководство хочет знать куда ходят их сотрудники.

Без прокси разобрать tls тяжело, а со всякими ECH и невозможно.

sergej ★★★★★
()

А какая альтернатива сквиду есть? Кеширование не надо, просто обычная http/https прокся с авторизацией по IP и username:password.

vbr ★★★
()
Ответ на: комментарий от vbr

Tinyproxy allows forwarding of HTTPS connections without modifying traffic

Если нужна разгрузка, вполне можно HAProxy взять, мне кажется. Basic Auth он умеет.

ivanov17
()
Ответ на: комментарий от ivanov17

Tinyproxy allows forwarding of HTTPS connections without modifying traffic

Мне нужно, чтобы он слушал на HTTPS, а не только проксировал HTTPS. Посмотри его опции, там нет ни сертификата, ни ключа, как он будет без них HTTPS-ить.

Если нужна разгрузка, вполне можно HAProxy взять, мне кажется. Basic Auth он умеет.

Не понял, что такое разгрузка. HAProxy разве умеет в стандартный HTTP/HTTPS Proxy протокол? Типа в браузере его прописать можно будет? Это же реверс-прокси, по крайней мере я его обычно видел в такой роли.

vbr ★★★
()

35 уязвимостей в кеширующем прокси Squid, и большинство из них до сих пор не устранено, предупреждает эксперт по безопасности Джошуа Роджерс. К настоящему времени устранены всего 20 из них.

Last_login
()
Ответ на: комментарий от firkax

squid обычно используется в организации с разграничением ширины канала по отделам и временем доступа интернету, плюс всякие редиректоры типа rejik, SquidGuard и т.д.

Опять же кто будет отчеты по трафику составлять ?

mx__ ★★★★★
()
Ответ на: комментарий от goingUp

Мне прокси не нужен, мне интересно на что сегодня заменяют squid люди, которые его выкидывают)

А зачем в текущих реалиях вообще может понадобиться кэширующий прокси? Когда я начинал заниматься интернетом, каналы были дохлые, а трафик платный. Почти весь веб трафик был без шифрования. В таких условиях было выгодно кэшировать все запросы, что если твои соседи смотрят тоже самое, то, во первых, они не гоняют лишние килобайты по дорогому медленному каналу, во-вторых, экономят время. В современных условиях с безлимитными мегабитными, а то и гигабитными каналами, а также повсеместным распространением https, этот самый кэш практически теряет смысл, потому что кэшировать нечего. Ну а скорость загрузки контента у пользователей и без того, нормальная. И если у тебя десяток пользователей, а канал 1-2 Мб/с, то этого вполне хватает для комфортного серфинга. Подобное любой 4G телефон обеспечивает.

Вы, конечно, можете заморочиться с подставными сертификатами и заставить кэшировать https, за одно и контролировать кто и что качает (как это нужно было делать, когда каждый мегабайт был на счету). Но стоит ли оно того?

Feonis ★★★
()
Последнее исправление: Feonis (всего исправлений: 1)
Ответ на: комментарий от Feonis

Так строят cdn. Десять кешей (возможно в разных регионах) и один origin.

Если ты про клиентскую часть, то так делаются динамические зеркала репозиториев типа голанга или рпм.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от monkdt

смотрю все обсуждают кэширующие сервера. Разве назначение squid дефакто не прокси сервер only?

Одна из актуальных задач решаемая Squid быть именно кеширующим прокси для http репозиториев с deb/rpm пакетами. Особенно если в конторе более десятка linux компов.

AlexVR ★★★★★
()
Ответ на: комментарий от cumvillain

Осталось узнать, зачем для тупого зеркалирования файлохранилища комбайн-сквид с авторизациями и кучей прочих настроек.

firkax ★★★★★
()
Ответ на: комментарий от cumvillain

Альтернатива это комбайн nginx. Не то чтобы это было плохо, но оно все комбайн.

Он не то чтобы комбайн. Просто он из чисто HTTP-сервера превратился в.. ээээээ… программируемый интернет-http-прокси-балансер, на котором можно запилить вообще всё, даже небо, даже Аллаха.

hateyoufeel ★★★★★
()
Ответ на: комментарий от vbr

Мне нужно, чтобы он слушал на HTTPS, а не только проксировал HTTPS

Будет себе висеть на 443 порту и пересылать трафик дальше. Или я не понимаю что такое «обычная прокся».

HAProxy разве умеет в стандартный HTTP/HTTPS Proxy протокол? Типа в браузере его прописать можно будет?

Не вполне понял вопрос. HAProxy умеет и в TCP, и в HTTP/HTTPS. На какой железке он будет стоять, к той и будешь обращаться, по любому нужному протоколу.

Это же реверс-прокси, по крайней мере я его обычно видел в такой роли.

А Nginx у нас вообще веб-сервер, на минуточку.

HAProxy в принципе без разницы в какую сторону проксировать. Чтобы не быть голословным, вот статья с их сайта с видео и картинками.

ivanov17
()
Ответ на: комментарий от AlexVR

Одна из актуальных задач решаемая Squid быть именно кеширующим прокси для http репозиториев с deb/rpm пакетами. Особенно если в конторе более десятка linux компов.

Нахрена? В этом случае проще своё зеркало забабахать через rsync и не насиловать моск. У Debian полный репозитарий amd64+all меньше терабайта выходит.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Нахрена? В этом случае проще своё зеркало забабахать через rsync и не насиловать моск.

Чтобы не сливать террабайты данных.

cumvillain
()
Ответ на: комментарий от ivanov17

А Nginx у нас вообще веб-сервер, на минуточку.

Ты очень сильно заблуждаешься. NGINX это такой socat для HTTP, только с плагинами.

cumvillain
()
Ответ на: комментарий от cumvillain

Нахрена? В этом случае проще своё зеркало забабахать через rsync и не насиловать моск.

Чтобы не сливать террабайты данных.

Там «террабайтов» и не будет. Будет меньше одного терабайта. Это две-три игры из стима сейчас :)

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Там «террабайтов» и не будет. Будет меньше одного терабайта. Это две-три игры из стима сейчас :)

Ха-ха. Нет:

/dev/vdb         20T   15T  4.0T  79% /var/mirror
cumvillain
()
Ответ на: комментарий от ivanov17

Будет себе висеть на 443 порту и пересылать трафик дальше. Или я не понимаю что такое «обычная прокся».

HTTP Proxy это такой протокол специальный. Например можешь указать curl –proxy= или в браузере прописать и он будет использоваться. Чтобы висеть на 443 порту, нужно прописать ключ и сертификат. Сейчас я сквид использую с примерно таким конфигом:

acl addresses src 1.2.3.4

http_access allow addresses
http_access deny all

https_port 0.0.0.0:8883 cert=/etc/squid/cert.pem key=/etc/squid/key.pem
http_port 0.0.0.0:8888

sslproxy_flags DONT_VERIFY_PEER

но мне не нравится, что он слишком умный (перекодирует траффик, вон даже пришлось флажок добавлять, не нравился ему самоподписанный сертификат) и жирный.

vbr ★★★
()
Ответ на: комментарий от AlexVR

я этого не знал. По логике кэширующие сервера раскидываются по разным местам, так что думал мухи и котлеты отдельно

monkdt
()
Ответ на: комментарий от cumvillain

Там «террабайтов» и не будет. Будет меньше одного терабайта. Это две-три игры из стима сейчас :)

Ха-ха. Нет:

/dev/vdb         20T   15T  4.0T  79% /var/mirror

Ха-ха да.

https://www.debian.org/mirror/size

Architecture 	Size in GB
source		106
all		222
amd64		626
hateyoufeel ★★★★★
()
Ответ на: комментарий от cumvillain

Ха-ха да.

Ну как видишь реальность отличается :)

Не вижу. Может у тебя там порево с лосями и конями. Смари, я тоже так могу:

$ zpool list storage  
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
storage  49.1T  1.26T  47.9T        -         -     0%     2%  1.00x    ONLINE 
hateyoufeel ★★★★★
()
Ответ на: комментарий от vbr

HTTP Proxy это такой протокол специальный

Если этот имеется в виду, то он не только для HTTP.

Чтобы висеть на 443 порту, нужно прописать ключ и сертификат

Висеть можно на каком угодно порту же. Если это «обычная прокся», которая через TCP работает, она тебе что угодно уровнем выше через TCP передаст.

Я понимаю, что у тебя кейс другой, но всё же.

Сейчас я сквид использую с примерно таким конфигом

Посмотри HAProxy.

ivanov17
()
Ответ на: комментарий от cumvillain

А Nginx у нас вообще веб-сервер, на минуточку.

Ты очень сильно заблуждаешься. NGINX это такой socat для HTTP, только с плагинами.

Я иронизировал :3

Кстати говоря, он не только в HTTP уже умеет. По крайней мере, видел какие-то конфиги для проксирования SMTP, POP3, IMAP etc. Но в этой роли его не пробовал.

ivanov17
()
Последнее исправление: ivanov17 (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

У Debian полный репозитарий amd64+all меньше терабайта выходит.

Нафига столько? Один раз настроил, и живёт себе годами. И не надо 100500 версий дистрибутивов рсинком гонять. А поставь его «прозрачным» прокси на шлюзе, так и настраивать клиентов читай не надо, многие и так по http ходят.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

У Debian полный репозитарий amd64+all меньше терабайта выходит.

Нафига столько? Один раз настроил, и живёт себе годами. И не надо 100500 версий дистрибутивов рсинком гонять. А поставь его «прозрачным» прокси на шлюзе, так и настраивать клиентов читай не надо, многие и так по http ходят.

Многие – это кто? Сейчас любой браузер тебе на HTTP (без S) выкинуть 100500 предупреждений. Пакетные менеджеры тоже по дефолту все на HTTPS настроены. Более того, большинство зеркал тупо не умеют HTTP, у них ответом 301 идёт при попытке на 80 порт подключиться.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от cocucka_B_TECTE

Оно было тёплым и ламповый

Магнитные ленты, микродрайвы

LinuxFromMachine
() автор топика
Ответ на: комментарий от hateyoufeel

Многие – это кто?

$ cat /etc/apt/sources.list
#deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 NETINST with firmware 20231007-10:28]/ bookworm main non-free-firmware

deb http://deb.debian.org/debian/ bookworm main non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware
...
AlexVR ★★★★★
()
Ответ на: комментарий от hateyoufeel
$ cat /etc/apt/sources.list
deb-src http://archive.ubuntu.com/ubuntu jammy main restricted
deb http://ru.archive.ubuntu.com/ubuntu/ jammy main restricted
deb-src http://ru.archive.ubuntu.com/ubuntu/ jammy multiverse restricted main universe
...
AlexVR ★★★★★
()
Ответ на: комментарий от hateyoufeel

Многие – это кто?

Да почти все у кого есть подпись пакетов.

cumvillain
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.