Apple решила дать разработчикам больше времени для перехода на HTTPS

Apple решила дать разработчикам больше времени для перехода на HTTPS

Apple решила дать разработчикам больше времени для перехода на HTTPS

На этой неделе Apple проинформировала разработчиков о том, что им будет предоставлено больше времени на то, чтобы убедиться, что их приложения взаимодействуют через защищенное HTTPS -соединение.

В июне на всемирной конференции разработчиков (WWDC) Apple объявила о том, что всем приложениям для iOS в App Store к концу года придется использовать технологию App Transport Security (ATS).

ATS включена по умолчанию в iOS 9.0 и OS X 10.11, она предназначена для защиты соединения между приложением и сервером за счет использования HTTPS.

В Apple, по-видимому, поняли, что многие разработчики не успеют выполнить требования к 1 января, так что решили продлить этот срок на неопределенное время. После того, как компания сделала это заявление, многие разработчики высказали опасения, что их приложения не будут работать с ATS из-за проблем с оборудованием и инфраструктурой.

Некоторые разработчики считают, что у них по-прежнему будет возможность размещать в App Store свои приложения без взаимодействия через защищенный протокол. Они рассчитывают на разумное обоснование в процессе обзора приложения.

Исследование, проведенное недавно фирмой, специализирующейся на изучении мобильных угроз Appthority показало, что только 3 процента из 200 топовых iOS-приложений могут реализовать взаимодействие с ATS без ущерба для своего функционала.

«На самом деле, мы наблюдаем, что все больше приложений начинают соответствовать жестким стандартам безопасности. Однако, процесс идет достаточно медленно, поэтому было неудивительно, что Apple решила продлить срок, чтобы дать разработчикам больше времени. Надеемся, что это кратковременная задержка» - говорит Робби Форкиш (Robbie Forkish), вице-президент Appthority.

В своем блоге в четверг Форкиш представил ряд рекомендаций, которые помогут предприятиям контролировать и потенциально исправлять приложения, которые не работают с ATS.

Критическая уязвимость в TLP позволяет обойти защиту Linux

В популярной утилите TLP, которую многие владельцы ноутбуков на Linux используют для управления энергопотреблением, обнаружили критическую уязвимость. Причём проблема нашлась во время обычной проверки пакета командой SUSE Security Team и располагается во вполне штатном коде.

Брешь получила идентификатор CVE-2025-67859 и затрагивает версию TLP 1.9.0, где появился новый profiles daemon.

Этот демон работает с root-правами и управляет профилями питания через D-Bus. Задумка хорошая, но реализация подвела: в механизме аутентификации Polkit нашлась логическая ошибка, которая фактически позволяет обойти проверку прав.

Как объясняют исследователи, демон должен был строго проверять, кто именно отправляет команды. Но из-за ошибки любой локальный пользователь мог взаимодействовать с ним без должной аутентификации — а значит, менять системные настройки питания от имени root.

На этом сюрпризы не закончились. В ходе анализа специалисты SUSE нашли ещё несколько проблем, уже связанных с исчерпанием ресурсов. В частности, механизм profile hold, который позволяет временно «зафиксировать» профиль питания, оказался совершенно без валидации. Локальный пользователь мог создавать неограниченное количество таких блокировок, причём без прав администратора.

В итоге это открывает прямую дорогу к DoS-атаке: демон начинает захлёбываться от бесконечных записей в структуре данных, куда попадают числа, строки с причиной и идентификаторы приложений — всё это полностью контролируется клиентом.

Любопытно, что SUSE вспомнила похожую историю с демоном управления питанием в GNOME: аналогичную проблему находили ещё несколько лет назад. Отдельно исследователи отметили вопросы к механизму «куки», которыми отслеживаются profile hold. Формально речь шла о предсказуемости значений, но в сочетании с отсутствием лимитов это лишь расширяло поверхность атаки.

К счастью, реакция была быстрой. SUSE сообщила об уязвимостях разработчикам ещё в декабре, и в версии TLP 1.9.1 проблема уже закрыта. В частности, число одновременных profile hold теперь жёстко ограничено числом 16, что убирает риск истощения ресурсов.

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