Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Никто не заметил, но Apple тоже ограничила блокировщики рекламы

Многие пользователи возмутились, когда узнали, что Google планирует ограничить возможности блокировщиков рекламы в браузере Chrome. Однако мало кто заметил, что схожие меры уже ввели в Safari, при этом Apple даже не подверглась критике.

На протяжении последних полутора лет Apple постепенно нивелировала работу блокировщиков рекламы в браузере Safari. Именно к такому подходу многие пользователи выразили резко негативное отношение в случае с Google.

Судя по всему, Apple оказалась чуть более прозорлива, чем американский поисковой гигант, поскольку купертиновцы не стали предавать свои планы огласке.

Вместо этого руководство Apple долго кормило нас разговорами о защите конфиденциальности пользователей. Если бы корпорация упомянула, что эффективность блокировщиков рекламы пострадает, реакция людей была бы совсем иной.

Все началось с того, что Apple несколько лет назад представила App Extensions — механизм, с помощью которого приложения могут внедрить свои возможности в другие программы.

По словам компании из Купертино, App Extensions должен работать в тандеме с технологией Content Blocker, которая была представлена в iOS 9 в 2013 году. 

На деле это значит, что приложения и расширения могут использовать API Content Blocker, который будет диктовать Safari, какой контент блокировать перед отображением веб-страницы. Блокировка будет осуществляться на основании набора правил.

После того как Apple на протяжении нескольких лет опробовала эти две функции, в компании поняли: разработчики, создающие расширения для Safari, больше не нужны. Вместо этого они могут просто задействовать приложения в App Store, чтобы обеспечить пользователей Safari дополнительными функциями.

Таким образом, предыдущая экосистема расширений оказалась устаревшей. В результате в середине 2018 Apple объявила окончание поддержки «устаревших» расширений.

К концу 2018 года Safari начал выводить следующее предупреждение: «Safari отключил расширения, которые могут замедлить работу вашего браузера».

Естественно, одними из таких «устаревших» расширений оказались и блокировщики рекламы. При этом большинство пользователей даже не обратили на это внимание, так как им рассказывали только о преимуществах нововведений.

В начале месяца стало известно, что Mozilla решила не следовать примеру Google в отношении новой политики блокировки рекламы. Компания-разработчик браузера Firefox продолжит поддерживать расширения для блокировки рекламного контента.

В 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