As part of Apple’s commitment to security, we reward researchers who share with us critical issues and the techniques used to exploit them. We make it a priority to resolve confirmed issues as quickly as possible in order to best protect customers. Apple offers public recognition for those who submit valid reports, and will match donations of the bounty payment to qualifying charities.*
Eligibility
In order to be eligible for an Apple Security Bounty, the issue must occur on the latest publicly available versions of iOS, iPadOS, macOS, tvOS, or watchOS with a standard configuration and, where relevant, on the latest publicly available hardware or the Security Research Device. These eligibility rules are meant to protect customers until an update is available, ensure Apple can quickly verify reports and create necessary updates, and properly reward those doing original research. Researchers must:
Be the first party to report the issue to Apple Product Security.
Provide a clear report, which includes a working exploit (detailed below).
Not disclose the issue publicly before Apple releases the security advisory for the report. (Generally, the advisory is released along with the associated update to resolve the issue). See terms and conditions.
Issues that are unknown to Apple and are unique to designated developer betas and public betas, including regressions, can result in a 50% bonus payment. Qualifying issues include:
Security issues introduced in certain designated developer beta or public beta releases, as noted in their release notes. Not all developer or public betas are eligible for this additional bonus.
Regressions of previously resolved issues, including those with published advisories, that have been reintroduced in certain designated developer beta or public beta release, as noted in their release notes.
Bounty Categories
Bounty payments are determined by the level of access or execution achieved by the reported issue, modified by the quality of the report. A maximum amount is set for each category. The exact payment amounts are determined after review by Apple. All security issues with significant impact to users will be considered for Apple Security Bounty payment, even if they do not fit the published bounty categories. Apple Security Bounty payments are at Apple’s discretion.
Topic
Maximum Payout
iCloud
Unauthorized access to iCloud account data on Apple Servers
Device attack via physical access
Lock screen bypass
User data extraction
Device attack via user-installed app
Unauthorized access to sensitive data**
Kernel code execution
CPU side channel attack
Network attack with user interaction
One-click unauthorized access to sensitive data**
One-click kernel code execution
Network attack without user interaction
Zero-click radio to kernel with physical proximity
Zero-click unauthorized access to sensitive data**
Zero-click kernel code execution with persistence and kernel PAC bypass
Report and Payout Guidelines
The goal of the Apple Security Bounty is to protect customers through understanding both vulnerabilities and their exploitation techniques. Reports that include a basic proof of concept instead of a working exploit are eligible to receive no more than 50% of the maximum payout amount. Reports lacking necessary information to enable Apple to efficiently reproduce the issue will result in a significantly reduced bounty payment, if accepted at all.
A complete report includes:
A detailed description of the issues being reported.
Any prerequisites and steps to get the system to an impacted state.
A reasonably reliable exploit for the issue being reported.
Enough information for Apple to be able to reasonably reproduce the issue.
Maximizing Your Payout
To maximize your payout, keep in mind that Apple is particularly interested in issues that:
Affect multiple platforms.
Impact the latest publicly available hardware and software.
Are unique to newly added features or code in designated developer betas or public betas, including regressions, as noted on this page when available.
Impact sensitive components.
Are novel.
Additional Requirements
In addition to a complete report, issues that require the execution of multiple exploits, as well as one-click and zero-click issues, require a full chain for maximum payout. The chain and report must include:
Both compiled and source versions.
Everything needed to execute the chain.
A sample non-destructive payload, if needed.
Источник
Отсутствие программы bug bounty сыграло с Apple злую шутку
Известно, что в отличие от своих конкурентов, таких как Google и Microsoft, у Apple отсутствует понятие bug bounty, т. е. денежного вознаграждения за обнаруженные уязвимости в своих продуктах. К основным продуктам, которые больше всего притягивают ресерчеров, относятся операционные системы OS X и iOS, а также веб-браузер Safari. Также как и в других случаях обнаружения существенных уязвимостей в ядре для jailbreak, последний кейс с значительной уязвимостью в криптографических алгоритмах сервисов компаниия, также, судя по всему, не стал исключением. Уязвимость была обнаружена исследователями университета Johns Hopkins и была исправлена Apple в вышедших обновлениях для OS X, iOS и watchOS.
Издание NY Times отмечает, что недавно запланированное разбирательство в суде, где представители ФБР должны были встретиться с менеджерами Apple, было отложено из-за того, что некая фирма предложила ФБР свой способ извлечения зашифрованных данных с iDevice. Данная тема еще раз подняла вопрос отсутствия программы bug bounty, что заставляет security-компании искать уязвимости в iOS и продавать эксплойты спецслужбам без уведомления Apple.
На сегодняшний день очень многие компании выплачивают денежные вознаграждения исследователям безопасности за поиск уязвимостей в продуктах и сервисах. Кроме вышеупомянутых Google и Microsoft, другие такие компании как Facebook, Twitter, Mozilla, Yandex, Uber также имеют bug bounty. Google уже заплатила исследователям безопасности более $6 млн. за обнаруженные уязвимости. Компания также предлагает $100 тыс. за обнаружение серьезной уязвимости в Chromebook.
Компания Microsoft также имеет свою систему bug bounty, причем за обнаружение существенной уязвимости в веб-браузере или ОС, она выплачивает $100 тыс. Например, к таким кейсам относятся, обнаруженные концептуальные уязвимости, которые позволяют обходить т. н. mitigation методы, используемые в Windows для блокирования эксплойтов по умолчанию (DEP, ASLR, CFG, SEHOP, и др.). Одним из победителей такого крупного bug bounty стал известный специалист @tombkeeper компании Tencent Xuanwu Lab.
Такая ситуация неприемлема для Apple, которая не предлагает подобной программы, а значит не стимулирует ресерчеров на поиск уязвимостей, что сказывается и на репутации Apple как компании. Кроме включения их имен в бюллетени безопасности, ресерчеры ничего не получают от компании.
Рис. Фрагмент из бюллетеня безопасности рассылки security-announce (APPLE-SA-2016-03-21-5 OS X El Capitan 10.11.4 and Security Update 2016-002), в которой Apple анонсирует исправление существенной уязвимости в iMessage. Детали уязвимости см. здесь.
Это создает ситуацию, при которой security-компаниям, специализирующимся на поиске уязвимостей в продуктах различных вендоров, выгодно придерживать свои эксплойты для продажи и не уведомлять о них компанию. Недавние события стали тому подтверждениям, когда по инициативе правоохранительных органов, судебное разбирательство с Apple было отложено из-за предложения одной из таких фирм ФБР предоставить инструмент по взлому iDevice и извлечения оттуда данных без знания passcode.
Ранее мы отмечали, что в связи с террористическим актом в США, спецслужбы захотели получить законное основание для получения инструмента по расшифровке данных с устройств под управлением iOS. С такой ситуацией не согласилась Apple и дело дошло до суда, а также большой полемики в обществе. Apple не торопиться вставлять бэкдор в iOS, поскольку прекрасно понимает какое негодование это может вызвать у пользователей. Сотрудники также грозят Apple увольнением в том случае, если компания пойдет на уступки.
Источник
Example Payouts
Bounty payments are determined by the level of access or execution obtained by the reported issue, modified by the quality of the report. Issues that are unique to designated developer or public betas, including regressions, can result in a 50% additional bonus if the issues were previously unknown to Apple. All security issues with significant impact to users will be considered for Apple Security Bounty payment, even if they do not fit the published bounty categories.
Unauthorized iCloud Account Access
$25,000. Limited unauthorized control of an iCloud account.
$100,000. Broad unauthorized control of an iCloud account.
Physical Access to Device: Lock Screen Bypass
$25,000. Access to a small amount of sensitive data from the lock screen (but not including a list of installed apps or the layout of the home screen).
$50,000. Partial access to sensitive data from the lock screen.
$100,000. Broad access to sensitive data from the lock screen.
Physical Access to Device: User Data Extraction
$100,000. Partial extraction of sensitive data from the locked device after first unlock.
$250,000. Broad extraction of sensitive data from the locked device after first unlock.
User-Installed App: Unauthorized Access to Sensitive Data
$25,000. App access to a small amount of sensitive data normally protected by a TCC prompt.
$50,000. Partial app access to sensitive data normally protected by a TCC prompt.
$100,000. Broad app access to sensitive data normally protected by a TCC prompt or the platform sandbox.
User-Installed App: Kernel Code Execution
$100,000. Kernel code execution reachable from an app.
$150,000. Kernel code execution reachable from an app, including PPL bypass or kernel PAC bypass.
User-Installed App: CPU Side-Channel Attack
$250,000. CPU side-channel attack allowing any sensitive data to be leaked from other processes or higher privilege levels.
Network Attack with User Interaction: One-Click Unauthorized Access to Sensitive Data
$75,000. One-click remote partial access to sensitive data.
$150,000. One-click remote broad access to sensitive data.
Network Attack with User Interaction: One-Click Kernel Code Execution
$150,000. One-click remote kernel code execution.
$250,000. One-click remote kernel code execution, including PPL bypass or kernel PAC bypass.
Network Attack without User Interaction: Zero-Click Radio to Kernel with Physical Proximity
$50,000. Zero-click code execution on a radio (e.g. baseband, Bluetooth or Wi-Fi) with only physical proximity, with no escalation to kernel.
$200,000. Zero-click partial access to sensitive data, with only physical proximity.
$250,000. Zero-click kernel code execution, with only physical proximity.
Network Attack without User Interaction: Zero-Click Unauthorized Access to Sensitive Data
$100,000. Zero-click attack that can turn on and collect information from a sensor (e.g., camera, microphone, or GPS).
$250,000. Zero-click partial access to sensitive data, without physical proximity.
$500,000. Zero-click broad access to sensitive data.
Network Attack without User Interaction: Zero-Click Kernel Code Execution with Persistence and Kernel PAC Bypass
$1,000,000. Zero-click remote chain with full kernel execution and persistence, including kernel PAC bypass, on latest shipping hardware.
Notes and Definitions
“One-click” refers to an exploit requiring user interaction to successfully gain access or execution. (For example, the user clicks a malicious link or opens a malicious file.)
“Zero-click” refers to an exploit requiring no user interaction to successfully gain access or execution. (For example, being on a network or in proximity is sufficient.)
“Sensitive data” access includes gaining a small amount (i.e., one or two items), partial access (i.e., some large number), or broad access (i.e., the full database) from Contacts, Mail, Messages, Notes, Photos, and real-time or historical precise location data — or similar user data — that would normally be prevented by the system.
The top payouts in each category are reserved for high quality reports and are meant to reflect significant effort, and as such are applicable to issues that impact all or most Apple platforms, or that circumvent the full set of latest technology mitigations available. Payouts vary based on available hardware and software mitigations that must be bypassed for successful exploitation.
Terms and Conditions
Read the legal requirements for the Apple Security Bounty Program.
Источник
Статья, в которой я раскрываю три 0-day уязвимости в iOS и критикую bug bounty программу Apple
Дисклеймер: Apple была уведомлена обо всех описанных в статье уязвимостях в период с 10 марта по 4 мая, ответы о принятии в работу со стороны Apple приходили на следующий день после каждого уведомления. В соответствии с responsible disclosure policy, Google Project Zero раскрывает уязвимости через 90 дней после уведомления вендора, ZDI — через 120, независимо от того, исправлена уязвимость или нет. Я же выждал намного больше (до полугода) и 10 дней назад предупредил Apple, о том, скоро буду вынужден публично раскрыть эти уязвимости. Ответа не последовало, поэтому я решил написать эту статью.
Все уязвимости имеют класс Information Disclosure, а именно получение чувствительной информации приложениями из App Store без запроса разрешений у пользователя, либо обход sandbox и получение такой информации, к которой у приложений в принципе не должно быть доступа. Я загрузил на GitHub код приложений, который я отправлял в Apple для демонстрации уязвимостей, его можно запустить на своих устройствах и посмотреть, приложения только получают данные и отображают их в UI.
Вот список уязвимостей вместе с данными, которые они могут получить:
Gamed 0-day (iOS 15.0)
Позволяет получить доступ к следующим данным:
e-mail аккаунта Apple ID, в который выполнен вход на устройстве и полное имя владельца этого Apple ID, а также authentication token, позволяющий отправлять запросы на сервера Apple от имени этого Apple ID (судя по всему ограничен только функциями, связанными с GameKit, я не проверял тщательно этот момент)
Доступ к содержимому следующих файлов для чтения (сейчас в iOS 15.0 доступен только первый, видимо, частично пофиксили):
/var/mobile/Library/CoreDuet/People/interactionC.db — содержит список контактов из сообщений Почта, Сообщения, прочих мессенджеров (к примеру, Telegram и WhatsApp), а также метаданные о взамодействии с этими контактами, включая статистику и точноее время каждого взаимодействия с каждым контактом
/var/mobile/Library/Preferences/com.apple.mobilephone.speeddial.plist — содержит список избранных контактов из быстрого набора в приложении Телефон
/var/mobile/Library/AddressBook/AddressBook.sqlitedb — Содержит полную адресную книгу со всеми контактами на устройстве
/var/mobile/Library/AddressBook/AddressBookImages.sqlitedb — Содержит фотографии контактов из адресной книги
Nehelper installed apps 0-day (iOS 15.0)
Позволяет проверить, установлено ли то или иное приложение на устройстве по bundle ID. В коде на GitHub содержится список самых популярных приложений, каждое из которых проверяется, после чего выдается список тех из них, что были найдены на устройстве.
Nehelper wifi info 0-day (iOS 15.0)
Незначительная уязвимость, позволяющая получить доступ к информации о точке доступа Wi-Fi, к которой в данный момент подключен устройство без наличия необходимого entitlement у приложения. Проверка на entitlement была добавлена в iOS 12, но ее можно легко обойти, правда для этого у приложения должен быть доступ к геолокации.
Analyticsd (исправлено в iOS 14.7)
Позволяет получить доступ к данным аналитики на устройстве (Эти данные можно увидеть, открыв приложение Настройки -> Приватность -> Аналитика и улучшения -> Данные аналитики -> Analytics-90Day. and Analytics-Daily. ). Данные содержат, помимо прочего:
Информация о пользовании устройством (количество раз, когда пользователь брал в руки устройство в разных контекстах, сколько пришло push-уведомлений, и как пользователь на них отреагировал)
Информация об экранном времени (сколько времени пользователь провел в каждом приложении с указанием Bundle ID этих приложений, а также сколько раз он открывал эти приложения)
Медицинская информация (пульс, число обнаруженных фибрилляций и нарушений сердечного ритма)
Метаданные из приложения Здоровье, связанные с отслеживанием менструального цикла, включая его продолжительность, а также возраст пользователя
Информация обо всех аксессуарах, которые подлючались к устройству (к примеру, AirPods) с указанием производителя, модели, версии прошивки и имен, которые пользователь присвоил этим аксессуарам
Информация о крашах приложений, включающая их Bundle ID и коды исключений, которые вызвали краш
Язык страниц, которые пользователь просматривал в приложении Safari
Данная уязвимость интересна тем, что Apple, после ее исправления, не указала ее в списке исправленных уязвимостей, сославшись на техническую ошибку, и пообещав указать ее в следующий раз. Тем не менее, ни в 14.7.1, ни в 14.8, ни в 15.0 она не появилась. Также мои последующие вопросы по этому поводу были проигнорированы. Что наводит на мысль о том, что Apple пытается утаить эту уязвимость, а возможно и тот факт, что они сами собирают все эти данные и используют их в неизвестных целях.
Вступление
В iOS существует огромное количество фоновых процессов, каждый из которых отвечает за какой-либо функционал. Эти процессы могут быть запущены от разных пользователей с разным уровнем привилегий и разными профилями sandbox, в отличие от приложений из App Store, которые максимально ограничены в возможностях. Поэтому для использования функций из большинства фреймворков, доступ к которым Apple предоставляет разработчикам, код в этих фреймворках взаимодействует с фоновыми процессами, передавая и получая от них данные через разные механизмы (в основном используется XPC). Есть 2 вида XPC — первый использует C API для установления соединения и передачи сериализованных объектов, второй же является оберткой на Objective-C над первым (NSXPC), где интерфейс взаимодействия определяется как обычный протокол Objective-C, с обеих сторон соединения имеется по экземпляру какого-то класса, которые соотвествуют этому протоколу. Клиент просто вызывает методы этого прокси-объекта и получает ответ через callback, передаваемый как параметр при вызове метода. Далее NSXPC же, незаметно для клиента, при помощи NSCoding и NSInvocation связывает эти две сущности и вызывает аналогичный метод на другой стороне соединения. Приложение может обладать различными entitlements, наличие которых проверяется на стороне фоновых процессов при установке XPC соединений и вызове различных методов, для того, чтобы определить, разрешены ли эти действия конкретному приложению.
Все уязвимости, о которых идет речь в этой статье являются логическими, то есть отсутствием различных проверок в привилегированных фоновых процессах, что приводит к тому, что любое приложение может к ним подключиться и получить конфиденциальные данные.
Gamed
Итак, первая уязвимость связана с фреймворком GameKit и соответствующим ему фоновым процессом под названием com.apple.gamed . Данный процесс использует NSXPC и протоколом для прокси-объекта является GKDaemonProtocol . Ниже приведены сокращенные протоколы, где содержатся только нужные нам методы. Полностью файлы заголовков можно увидеть в репозитории на GitHub.
Вот упрощенная версия кода, который позволяет нам получить данные. Ошибка номер один — нам возвращается объект, содержащий Apple ID и токен аутентификации (что в принципе не должно передаваться в приложение). Ошибка номер два — метод requestImageData не производит проверку на схему URL, и получая file:// считывает из файловой системы файл с указанным URL используя привилегии процесса gamed и возвращает нам в приложение его содержимое.
На странице программы Apple Security Bounty данная уязвимость оценивается в $100,000 (Broad app access to sensitive data normally protected by a TCC prompt or the platform sandbox. “Sensitive data” access includes gaining a broad access (i.e., the full database) from Contacts). Минимальная выплата за любые уязвимости, подходящие под категории с их сайта — 5,000$. Но по многочисленным свидетельствам участников этой программы, Apple затягивает в выплатах, а в итоге может либо отказать в выплате без указания причины, либо выплатить сумму, значительно меньше заявленной у них на сайте. Я сообщил о данной уязвимости 10 марта. 25 августа я получил ответ, что уязвимость будет исправлена в ближайшем обновлении. С тех пор прошел почти месяц, вышли iOS 14.8 и 15.0, но в них исправление отсутствует. Я не планировал опубликовывать 0-day уязвимости в открытом доступе, но это единственная возможность привлечь внимание к тому, что произошло с уязвимостью analyticsd , и к тому, как в целом работает программа Apple Security Bounty. Подробнее об этом в конце статьи.
А сейчас небольшое отступление. У Apple есть такое понятие как Private API. Оно подразумевает символы C, классы и методы Objective-C, которые присутствуют в бинарных файлах фреймворков, но которые отсутствуют в файлах заголовков SDK, предоставляемых Apple разработчикам. По правилам App Store, использование приватных API запрещено. При загрузке бинарного файла в App Store Connect происходит проверка на использование приватных API, и в случае обнаружения, бинарный файл не загружается. После чего на почту приходит такое письмо:
We identified one or more issues with a recent delivery for your app, [APP_NAME] 1.0 (1). Please correct the following issues, then upload again.
ITMS-90338: Non-public API usage — The app contains or inherits from non-public classes in [APP_NAME]: GKFamiliarPlayerInternal, GKFriendPlayerInternal, GKLocalPlayerInternal . If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/
Best regards, The App Store Team
Но проверка происходит таким образом, что у Apple есть просто список строк с названиями методов, и все эти строки ищутся в загружаемых бинарниках, что позволяет легко обойти эту проверку. Objective-C Runtime позволяет нам обращаться к классам таким образом: NSClassFromString(«GKLocalPlayerInternal»]) . Но в этом случае строка с названием класса все равно попадет в исполняемый файл. Но, если мы сделаем, к примеру, так: NSClassFromString([«GKLoc»,»lPlayerInternal»].joined(separator: «a»)) , строка не будет обнаружена, проверка пройдет успешно и приложение будет загружено в App Store. Данным методом пользуются многие крупные компании. К примеру в коде одного очень известного приложения с 500 млн пользователей применяется шифр Цезаря для сокрытия использования приватных методов UIKit. А насчет скрытия факта использования С функций, являющихся private API, подробнее можно почитать в моем следующем посте (английская версия).
В дополнение, правила и ограничения, которые Apple применяет к разработчикам, не едины для всех. Как пример можно привести секретный entitlement com.apple.developer.pushkit.unrestricted-voip , выдающийся некоторым приложениям, но я не буду подробно писать об этом в данной статье.
Nehelper installed apps
Здесь и в остальных уязвимостях, подверженные фоновые процессы используют вариант XPC с С API. Но, для удобства, код ниже написан на Swift. Данный сервис под названием com.apple.nehelper отвечает за работу с Network Extensions. В нем есть определенный метод, который получает на вход Bundle ID приложения, после чего, в зависимости от того, обнаружено ли приложение на устройстве, нам возвращается какой-то UUID или nil.
Nehelper wifi info
Это еще одна уязвимость в том же сервисе. У разработчиков есть возможность получать информацию о Wi-Fi сети, к которой подключено устройство. Но для приложений, скомпилированных при использовании iOS 12 SDK и выше, для этого требуется отдельный entitlement. Версия SDK передается в параметре sdk-version , который мы контролируем, поэтому данная проверка легко обходится. Но препятствием является то, что для этого у приложение должен быть доступ к геолокации.
Analyticsd
И, наконец, последняя уязвимость, которая была исправлена в iOS 14.7. Здесь проблема кроется в фоновом процессе, ответственном за сбор аналитики. В нем есть метод под названием log-dump , который не защищен никакими проверками, и любое приложение может подключиться к этому процессу и вызвать данный метод, в ответ получив огромное количество данных об использовании устройства.
29 апреля я сообщил об этой уязвимости в Apple.
3 июня я получил письмо от Apple, в котором было написано, что данная уязвимость будет устранена в следующем обновлении.
19 июля вышла iOS 14.7, но в списке исправленных узявимостей ее нет.
20 июля я написал письмо в Apple с целью разъяснить ситуацию.
23 июля приходит ответ с извинениями, словами о том, что это случилось из-за «processing issue», уверениями, что уязвимость будет указана в следующем обновлении и вопросом о том, как меня упомянуть в списке исправлений. В тот же день я ответил и сразу получил ответ с подтверждением.
26 июля вышла iOS 14.7.1, в списке исправленных узявимостей опять ничего.
13 сентября вышла iOS 14.8, в списке исправленных узявимостей опять ничего. В тот же день я написал письмо в Apple с выражением разочарования в программе Apple Security Bounty, с повторной просьбой прояснить ситуацию и предупреждением, что при отсутствии ответа, я буду вынужден публично раскрыть информацию обо всех уязвимостях, которые я им отправил.
20 сентября вышла iOS 15.0, в списке исправленных узявимостей опять ничего.
По состоянию на 24 сентября ответа я так и не получил, в связи с чем я публикую данную статью.
Я не знаю, по какой причине Apple не хочет публиковать информацию об этой уязвимости, но я уверен, что большинство пользователей даже не подозревают о том, сколько информации Apple собирает о них под видом аналитики. Также неизвестно, с какой целью эта информация используется и кому передается. В связи с этим особенно лицемерно выглядит их позиция о том, что они заботятся о конфиденциальности пользователей.
Я далеко не первый человек, который разочаровался в программе Apple Security Bounty, и я надеюсь, что мой опыт повлияет на решение багхантеров не сотрудничать с ними. Кому интересно почитать о негативном опыте других людей, список публикаций на эту тему есть в английской версии этой статьи.
UPD:
25 сентября, ровно через 24 часа после этой публикации я получил ответ от Apple, цитирую:
We saw your blog post regarding this issue and your other reports. We apologize for the delay in responding to you.
We want to let you know that we are still investigating these issues and how we can address them to protect customers. Thank you again for taking the time to report these issues to us, we appreciate your assistance.
Please let us know if you have any questions.
UPD2: У меня нет возможности проверить, но джейлбрейк-разработчик утверждает, что у него получилось за один день написать tweak, который защищает от трех 0-day уязвимостей, описанных в статье, причем сделал это за один день.
UPD3: Я опубликовал следующий пост (пока только английская версия), где подробно расписал про метод скрытия факта использования С функций, являющихся private API, а также озвучил свои претензии к тому, как проходит ревью в App Store.
UPD4: 1 октября вышла iOS 15.0.1. Все три уязвимости до сих пор не исправлены.
UPD5: 11 октября вышла iOS 15.0.2. Уязвимость gamed исправлена без упоминания об этом в списке исправлений, остальные две уязвимости до сих пор не исправлены.
