Всем пользователям Firefox дефолтно включат защиту Total Cookie Protection

Всем пользователям Firefox дефолтно включат защиту Total Cookie Protection

Всем пользователям Firefox дефолтно включат защиту Total Cookie Protection

Вчера, 14 июня, компания Mozilla начала централизованно менять настройки приватности десктопных Firefox по всей пользовательской базе. Функциональность Total Cookie Protection (TCP), ранее доступная только в режиме строгой защиты от трекинга и при просмотре сайтов «инкогнито», будет теперь включена в браузере по умолчанию.

Механизм TCP создает отдельное, изолированное хранилище для куки каждого сайта, на который заходит пользователь. Доступ к содержимому файла может получить только его источник; таким образом, отслеживание перемещений пользователя и его поведения на других сайтах становится невозможным.

 

Возможность межсайтовой передачи куки оставлена лишь для сервисов, не связанных с трекингом, — например, для систем единого входа. Информация о блокировке и разрешении отслеживания отображается в меню, выпадающем при клике по значку щита в адресной строке браузера. При изменении настроек вручную Firefox сохраняет предпочтения в течение 30 дней.

По данным Mozilla, ее браузером в настоящее время активно пользуются более 200 млн обитателей всемирной паутины. Идею оградить их от трекинга, которым зачастую злоупотребляют не только рекламодатели, в компании начали разрабатывать лет десять назад.

В 2015 году в Firefox появилась опция Tracking Protection, которую можно было включить, перейдя в режим приватного просмотра. Впоследствии эта защита стала дефолтной; ее также переименовали в Enhanced Tracking Protection (ETP) и расширили, добавив возможность автоматической блокировки сторонних куки.

Концепция полной защиты от межсайтовой слежки через куки (TCP) была впервые реализована в десктопном Firefox 86 — как дополнение к ETP, осуществляющей блокировку трекеров на основе обновляемого списка злостных нарушителей приватности. С этого года возможности TCP доступны также пользователям Android-устройств и iPhone.

В GNU telnetd нашли критическую дыру с удалённым root-доступом

В GNU InetUtils telnetd обнаружили новую критическую уязвимость, которая позволяет удалённо выполнить произвольный код с правами root. Проблема получила идентификатор CVE-2026-32746 и, согласно опубликованному описанию, затрагивает версии до 2.7 включительно.

Исследователи из DREAM Security Labs говорят о классическом Переполнении буфера, который срабатывает ещё до появления запроса логина.

Суть бага в том, как telnetd обрабатывает переговоры по опции LINEMODE SLC. Если на старте соединения по TCP-порту 23 отправить специально подготовленное сообщение с аномально большим числом параметров, можно спровоцировать переполнение буфера.

Поскольку этот код отрабатывает сразу после подключения, атакующему не нужно проходить аутентификацию. А так как telnetd часто запускается с повышенными правами через inetd или xinetd, успешная эксплуатация фактически даёт полный контроль над хостом.

Отдельно неприятно то, что Telnet хоть и считается почти вымершим в обычной ИТ-инфраструктуре, до сих пор живёт в промышленных системах, OT-сетях, SCADA, PLC и старом сетевом оборудовании. Именно там такие уязвимости обычно особенно болезненны: обновляться сложно, замена железа дорогая, а сервисы продолжают висеть в работе годами.

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

Если это невозможно, то минимум — закрыть порт 23 снаружи, оставить доступ только с доверенных адресов и не держать daemon с лишними привилегиями.

Здесь важно не перепутать эту уязвимость с другой недавней проблемой в GNU InetUtils telnetd. Ранее мы писали про CVE-1999-0073 — уязвимость из конца 90-х, которая неожиданно вернулась и снова позволяет получить полный root-доступ к серверу без аутентификации.

RSS: Новости на портале Anti-Malware.ru