dxdt.blog: занимательный интернет-журнал

Ко Дню космонавтики – традиционное изображение ракеты. Советская почтовая марка из 1972 года:

Подробное описание уязвимости CVE-2015-1130 в Apple OS X и истории её обнаружения, с примерами кода. Уязвимость позволяет произвольному пользователю получить файл, исполняемый на локальной машине с правами root. Для эскалации привилегий используется системный API, в котором содержится ошибка. Пишут, что уязвимость существовала как минимум с 2011 года.

В домене .ORG доступны однобуквенные имена. Отличный пример: X.ORG (там есть соответствующий сайт, конечно же). Это довольно дорогие доменные имена. Похоже, что в апреле домен i.org приобрёл некоторую связь с Facebook – как минимум, на это указывают записи Whois (почему-то, с минусом, да):

$ whois i.org | grep ‘Organization’
Registrant Organization:-Facebook
Admin Organization:-Facebook
Tech Organization:-Facebook

Домен делегирован на серверы a.ns.facebook.com и b.ns.facebook.com, которые, впрочем, на запросы об этом имени не отвечают (просто молчат в ответ по UDP, а по TCP – эти сервера имён вообще разговаривать сразу отказываются).

К вопросу доступности современных веб-сайтов, использующих HTTPS, для поисковых роботов. Несколько дней назад мне подсказали, что “Яндекс.Картинки” не индексируют файлы по HTTPS, требуя доступа по HTTP. Поверхностное исследование выдачи поисковика подтвердило, что это, похоже, так и есть (более того, в документации прямо сказано, что требуется HTTP для URL-ов картинок). Я воспользовался штатной формой обратной связи и написал в “Яндекс” следующее письмо:

Здравствуйте!

На странице http://help.yandex.ru/images/indexing.xml сказано, что поиск Яндекса по картинкам не поддерживает HTTPS. Точнее, для индексации файла картинки требуется, чтобы файл было доступен по HTTP. Сейчас веб-сайты массово переходят на защищённый протокол (более того, TLS является основным рекомендованным транспортом в HTTP/2). В идеале, весь контент современного веб-сайта должен передаваться веб-сервером по HTTPS, это касается и картинок, потому что “вынос” изображений в открытый протокол HTTP несёт с собой риски возникновения проблем с безопасным доступном к сайту в целом, так как предоставляет возможности для “деградации” протокола при доступе к определённым URL.

Таким образом, сейчас изображения с сайтов, поддерживающих только безопасный протокол HTTPS, не попадут в индекс поиска по картинкам. Планируется ли в ближайшее время исправить ситуацию, добавив поддержку для сайтов, доступных только по HTTPS?

Спустя три дня получил лаконичный ответ от Платона Щукина:

Здравствуйте, Александр!

Эта ситуация уже исправлена. Картинки индексируются по https.

Неплохо, если так, хотя и противоречит описанию на сайте. Что ж, ждём обновления индекса.

После обновления “Яндекс.Карт” проблема с обработкой корневого домена в URL вернулась. Правда, теперь они показывают “ошибку 503” вместо некоторого “сервисного” XML-документа: https://maps.yandex.ru./

Конечно же, указание корневого домена в URL и близко не является какой-то распространённой практикой. О существовании этой “крайней точки” вообще знают только квалифицированные специалисты, а пользователи – вообще не догадываются обо всех этих крайне важных для работы Сети заморочках. Более того, не раз приходилось видеть, как про точку забывают даже те самые специалисты, хотя и работают с DNS, где важнее точки – разве что её отсутствие. (Забывчивость в DNS приводит к более плачевным, по сравнению с веб-сервисами, последствиям: целые густо населённые доменные зоны исчезают из Интернета, а иногда их трафик полностью перенаправляется в адрес ни о чём не подозревающего одинокого сервера.) Тем не менее, то, что пользователи браузеров не вводят адреса с корневым доменом, не означает, что огромный сервис, вроде “Яндекс.Карт”, может неверно обрабатывать URLы.

Технология HSTS (HTTP Strict Transport Security) позволяет принудительно переводить браузер в режим HTTPS для некоторых URL, это требуется для того, чтобы предотвратить активные атаки, основанные на замене протокола. Однако на базе HSTS придумали делать “суперкуки” – то есть, идентифицировать браузер, даже если он работает в “анонимном” режиме, не отправляет куки-файлы. Технология довольно занимательная: используется несколько адресов сайтов, с разным состоянием HSTS, это состояние (HTTP/HTTPS) соответствует одному биту идентификатора; javascript-ом состояния битов считываются с набора сайтов и собираются в число, идентифицирующее браузер. Конечно, требуется несколько десятков адресов (например, 32), но это не проблема.

Добавил в избранные новый блок записок, вот они:

• Обнаружение небольших беспилотников
• Тотальное наблюдение за поверхностью Земли
• Наблюдение за железнодорожными ракетными комплексами
• Воздушные заграждения и гиперзвуковые беспилотники
• Слежение за смартфонами GSM по всему миру

• Ключи в DNSSEC: разбор на примере
• Фундаментальные характеристики бэкдора
• “Любительские” подводные дроны
• HTTPS и “открытые веб-страницы”
• Air gap: наивное использование

У iPhone есть функция, которая стирает пользовательские данные с устройства, если PIN-код на экране блокировки введён неверно 10 раз. Казалось бы, подобрать даже четырёхзначный код нереально – шанс угадать слишком мал. Тем не менее, пишут про электронное устройство, которое PIN-код успешно подбирает. Хитрость в том, что устройство, обнаружив ошибочный ввод по показаниям дисплея, моментально отрубает питание телефона (для реализации этого требуются вскрыть корпус и подключить прерыватель). Из-за алгоритмической ошибки в процедуре обработки ввода PIN-кода, телефон не успевает записать новое значение счётчика попыток в память, поэтому после перезагрузки можно попробовать ещё раз (пишут, что примерно 111 часов нужно для проверки всего множества кодов).

Насколько можно понять, речь об уязвимости CVE-2014-4451, которая датирована 18 ноября 2014 года и должна быть уже закрыта. Очевидно, что ошибка разработчиков состоит в последовательности шагов алгоритма: нужно сперва увеличивать значение счётчика попыток в энергонезависимой памяти, а только потом выводить результат проверки на экран (не наоборот). Очень показательный пример того, что в реализации функций обеспечения безопасности подобная “мелочь” может начисто удалить все защитные свойства.

Китайский удостоверяющий центр CNNIC, признаваемый всеми основными браузерами, поучаствовал своими ключами в выпуске промежуточного сертификата, который использовался в прозрачно перехватывающем трафик SSL-прокси. Об этом, конечно, стало быстро известно в Google (потому что браузер Chrome устроен достаточно добротно). Объяснения от CNNIC сводятся к тому, что, дескать, это всё была тестовая среда, а сертификаты утекли наружу случайно. Итог пока такой: корень CNNIC таки изымают из продуктов Google:

“As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products.” (В результате совместного расследования событий, связанных с данным инцидентом, мы приняли решение что CNNIC Root и EV УЦ больше не признаются продуктами Google.)

Это весьма резкое решение, но, собственно, такого варианта следовало ожидать. Mozilla пока думает, но в том же самом направлении. А для повторного включения корней CNNIC в браузеры планируют потребовать от УЦ поддержки Certificate Transparency.

В CNNNIC уже ответили, в том ключе, что шаг Google – неприемлем, требуют задуматься о правах пользователей.

Ссылка по теме: перехват HTTPS.

Update, 04/04/15: Mozilla подключилась – сертификаты, впущенные от корней CNNIC после 1 апреля 2015, не признаются. Таким образом, CNNIC, как коммерческий УЦ, теряет всякий смысл. Интересно, как прореагируют в Китае?

Google некоторое время назад зарегистрировал собственный домен верхнего уровня. Вот как они его используют: https://com.google. Весьма занятный вариант, да:

(Для полноты картины, конечно, нужно было регистрировать elgoog. Но, вероятно, просто забыли.)

Популярная новость – DARPA продвигает разработку новых автоматических систем навигации, независимых от GPS. Основные недостатки спутниковой навигации растут из того факта, что она использует сильно удалённый от навигационного приёмника, внешний “базис” – то есть, сами спутники. Отсюда и возможные проблемы с получением сигнала, который, к тому же, могут испортить разными помехами. С другой стороны, для практически полезной навигационной системы всё равно нужны некие опорные точки, и спутники, передающие навигационный сигнал, не самый плохой вариант. Пожалуй, сошлюсь на старую заметку по этой теме, трёхлетней давности – “Автоматический навигатор, без спутников“.

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