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

В очередной полёт, как пишут, специальный аппарат X-37B повёз экспериментальную инерциальную навигационную систему с квантовыми сенсорами.

Интересно наблюдать, как инерциальные системы вдруг начали массово противопоставлять спутниковым – GNSS (GPS и др.). Как если бы инерциальные системы только сейчас придумали для того, чтобы было чем заменить GPS. Конечно, принципиальная ненадёжность GPS нынче стала широко известной, но это вовсе и не означает, что о такой ненадёжности специалистам не было известно ранее. Более того, долгое время гражданский сигнал GPS просто содержал уводящую помеху, специально снижавшую точность (забавно, что в “газетах” про это иногда писали так, что, дескать, это ограничение самой спутниковой навигации, как технологии).

С точки зрения навигации, как технической дисциплины, GNSS отличается от инерциальных систем принципиально. GNSS – это система с плавающими внешними ориентирами, да ещё и работающая только тогда, когда с этими ориентирами есть радиосвязь (можно принимать сигнал). Зато успешное использование GNSS требует минимальных затрат: и по аппаратуре, и по энергии сопровождения (не нужны всякие хитрые стабилизирующие механизмы и пр.).

Инерциальная же система – это система сугубо внутренняя, собственная. Они известны давно: гироскопы разных схем и природы, акселерометры и датчики углов – это всё было до GPS. Но квантовые устройства тут не приносят чего-то принципально нового именно в навигационном смысле. Да, интересно было бы попробовать привязать сенсор к некоторому “мировому квантовому эфиру”, если таковой обладает нужной структурой, но это пока что фантастика: гироскопы с акселерометрами и угловыми датчиками остаются, но становятся “атомными”, чтобы измерения можно было проводить квантовыми сенсорами. Эти квантовые сенсоры лишь могут помочь сделать более точную инерциальную систему, потому что основная проблема таких систем – накопление погрешности.

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

“Яндекс” через ВШЭ рапортует, что успешно и официально, пусть и в порядке эксперимента, внедрил LLM/ИИ и “промпт-инжиниринг” в процесс подготовки дипломных работ студентами (кстати, почему-то в тексте новости поготовку работы/проекта называют “подготовкой диплома”, но это уже детали, которые не видит LLM).

Вообще, кто бы, как говорится, сомневался, что использование LLM с целями “подготовки диплома” будет не просто приветствоваться, но ещё и прямо рекомендоваться лучшими вузами, тем более, когда речь идёт о коммерческом сервисе “Яндекса”. Тут ведь главное, чтобы изучение арифметики не было, в конечном итоге, заменено на “промпт-инжиниринг” заданий для калькулятора – ну, на это можно только надеяться, да и шансы не велики.

Кстати, наверное, если уж LLM, то в дипломной работе тогда должны бы указываться эти самые “промпты”, которые использовались для генерирования текста. Есть, конечно, проблема в том, что воспроизводимость отсутствует: и сама LLM так устроена, что выдаёт разные тексты, и провайдер LLM-сервиса может что-то подкрутить. С другой стороны, хоть какие-то содержательные элементы останутся.

В продолжение предыдущей записки, про LLM и математические задачи. Google пока тоже не публикует технических подробностей о том, кто там и как перебирал и форматировал решения задач Международной математической олимпиады, чтобы получилась “золотая медаль”, однако, в отличие от OpenAI, в официальном новостном сообщении, есть, хотя бы, небольшие и довольно занятные намёки.

Во-первых, пишут, что использовалась некоторая “параллельная обработка” (parallel thinking) внутри модели, но, насколько можно понять, для подбора готовых решений. Цитата: “Эта конфигурация позволяет модели одновременно рассматривать и комбинировать многие возможные решения до выдачи окончательного ответа, вместо того, чтобы действовать по единственной, линейной цепочке рассуждений”. (This setup enables the model to simultaneously explore and combine multiple possible solutions before giving a final answer, rather than pursuing a single, linear chain of thought.)

Во-вторых, для получения решений провели “дополнительное обучение”, подстроенное для подходящих типов задач, и ввели инструкции, подобранные конкретно под задачи ММО (видимо, этого года – иначе нет смысла уточнять дважды). Цитата: “Мы также предоставили Gemini доступ к корпусу специально отобранных высококачественных решений математических задач и добавили в инструкции некоторые подсказки и советы общего характера о том, как решать задачи ММО”. (We also provided Gemini with access to a curated corpus of high-quality solutions to mathematics problems, and added some general hints and tips on how to approach IMO problems to its instructions.) Это самый интересный кусок из официального сообщения. Его можно понимать и так, что добавили базу с содержанием решений задач именно такого типа, как потом спрашивали, а позже ввели “советы” с ответами конкретных задач. А можно понять и так, что в процессе “настройки” корректировали входные данные, направляя вывод генерации к текстам верных доказательств (перечитайте в исходнике: a curated corpus of high-quality solutions).

Проще говоря, подробного описания процесса нет, а так – это уж слишком сильно напоминает улучшенный вариант традиционного уже упражения “ИИ сдаёт ЕГЭ” – выбираем тот сгенерированный текст из десятков выданных LLM вариантов, который набирает больше баллов.

Оказывается, история с “экспериментом” LLM OpenAI на IMO 2025 гораздо проще: это просто агрессивный маркетинговый выход, чтобы опередить заявление от Google о том же самом – о получении “золотой медали” на IMO 2025 силами ИИ/LLM DeepMind. Но зато у Google есть подтверждение от оргкомитета олимпиады, а у OpenAI – нет.

Не привязывать хотя бы Международную математическую олимпиаду к ИИ/LLM, сами понимаете, сейчас нельзя – это будет превратно понято, это вам не шахматные компьютеры отключать от шахматных турниров между человеками. Похоже, что вопрос-то был лишь в том, чтобы ИИ-корпорации хотя бы не объявляли о “золотых медалях” раньше, чем завершится само мероприятие для людей и некоторый период “охлаждения”, дабы не перехватывать небольшое внимание прессы. Но OpenAI – заявили раньше всех, что, конечно, тут же перехватило фокус медиа. И пусть достижение OpenAI не “официальное”, насколько можно судить, но зато и Google явно опередили, и внимание от конкурса среди человеков переключили. Такая вот маректинговая действительность, да.

В продолжение предыдущей записки, про решение задач с Международной олимпиады средствами LLM: самое забавное, что, например, решение для первой задачи ММО-2025, которое сгенерировала “экспериментальная модель”, почему-то содержит ответ в самом начале – то есть, буквально, написано: смысл решения – доказать, что правильный ответ – правильный. Вот этот фрагмент, в виде скриншота (потому что там нужно “рендерить” LaTeX и Markdown):

Далее там идёт очень большой и не очень внятный сгенерированный текст доказательства, перегруженный отступлениями, понимать который довольно сложно, но не потому, что задача сложная, а потому, что много лишнего в “рассуждениях”. Сомневаюсь, что полезно делать его полный разбор. (Нет, сама исходная задача не требует таких больших объёмов для записи решения.)

Небольшое техническое пояснение: первая задача IMO 2025 это комбинаторная геометрия, нужно посчитать возможные варианты покрытия целых точек на решётке прямыми – это один из самых популяных “сеттингов” для олимпиадных задач; соответственно, набор возможных вариантов – {0, 1, 3} – появляется в процессе решения, поскольку составляет основную содержательную часть этого решения: надо понять, что других чисел (это количество подходящих прямых) там не может появиться; и то, что отсутствует 2, это, вообще говоря, не самый тривиальный момент (но и не самый сложный). Так что то, что решение от LLM OpenAI построено на доказательстве верности состава ответа, без указания на то, как этот состав получен, – почему, хотя бы, там не {1, 2, 3}, – выглядит весьма странно.

Сообщают (осторожно, ссылка на Twitter), что некая “внутренняя”, экспериментальная модель от OpenAI продемонстрировала уровень “золотой медали” при решении задач Международной математической олимпиады (ММО) 2025 года. Подробностей, как обычно, нет, но опубликованы решения, которые сгенерировала та модель. Всё это занятно. Поделюсь ниже скриншотом по этой же теме, он из недавней выдачи “общедоступной” LLM той же корпорации – ChatGPT 4o.

“Нет, 205 не делится на 5” – считает данная LLM. Сам транскрипт относится к “обобщённой” задаче про набор воды вёдрами – там было три ведра огромного объёма и решать нужно было, понимая общие принципы обратимости/делимости. Откуда, собственно, и взялся НОД (gcd). Так что количество шагов и пр. – это более или менее близко к задаче, вот только использовать три ведра LLM не “догадалась”, без подсказки. Но это детали. Главное – это вывод про то, что “205 не делится на 5”.

Но, предположим, экспериментальная модель для ММО – существенно лучше, конечно. Хотя, и уровень золотой медали ММО, как бы, существенно выше.

Забавная история.

Попалось тут снова утверждение, что, мол, если количество уязвимостей в библиотеках с открытым исходным кодом выросло в два раза, а количество самих библиотек за тот же период – только на четверть, то это означает, что количество “угроз” растёт в четыре раза быстрее, чем “объём компонент” с открытым кодом.

Оставим за скобками способы определения “количества библиотек”, оставим за скобками и такое наблюдение, что если библиотек меньше, то их проще обновить и, тем самым, проще нивелировать угрозы. Посмотрим, так сказать, на сам принцип и на сравнение “прироста”. Тут ведь не сказано, какие именно это уязвимости. Откуда известно, что их количество выросло в библиотеках? Как вообще по количеству уязвимостей можно определять количество угроз (это сильно разные понятия и сильно разные метрики)? И так далее, и тому подобное.

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

Естественно, подобная статистика уязвимостей в ПО ведётся по обнаруженным уязвимостям, о которых опубликована информация. То, что уязвимость не обнаружена, не означает, что в коде нет уязвимостей. А обнаружение уязвимости – не гарантирует, что их в исследуемом коде много. Именно поэтому угрозы, как таковые, нельзя расставлять по обнаруженным уязвимостям. Но, конечно, в списке должны быть две-три угрозы, связанные с возможностью эксплуатации известных уязвимостей при помощи автоматических инструментов – это достаточно очевидно. Вот только количество этих угроз не растёт вместе с ростом публикаций CVE – максимум, угрозы эти можно разделить по библиотекам, то есть, максимум на четверть они вырастут, если все новые библиотеки строго тянуть в свою модель угроз (но зачем? вопрос риторический).

Во-первых, вот уже лет пять как начали присваивать статус “признанной уязвимости”, “с кодом CVE”, даже самым мелким обнаруженным дефектам, практическое значение которых при проведении атак довольно сомнительно.

Во-вторых, сейчас сам поиск уязвимостей стал настолько массовым, что, действительно, находить их стали больше, в том числе, существенных (это и капитан Очевидность подтверждает). Рост интереса исследователей – вот единственный параметр, о котором можно судить, косвенно, по количеству публикаций уязвимостей. Да, находят весьма и весьма существенные уязвимости, которым десять и более лет – внимание, вопрос: когда эти уязвимости преобразовались в угрозы, если преобразовались? В момент внесения в код, или когда об этом в газетах написали, десять лет спустя?

В-третьих, уязвимости сильно различаются по тому контексту, который их вообще делает уязвимостями и создаёт возможность установления связи с угрозами (угрозы, на минуточку, и определяются-то не по уязвимостям – см. выше). Эффект от одной и той же “уязвимости с CVE” может сильно различаться в зависимости от модели угроз (учитывается ли подключение системы к внешним вычислительным сетям; учитывается ли наличие USB-портов и возможность физического доступа, и т.д.).

Так что угрозы отдельно, поиск уязвимостей – отдельно, а наличие уязвимостей – тут вообще в другой плоскости. Наличие или отсутстие уязвимостей не мешает их поиску, – да, искать можно и то, чего в коде нет, это основной принцип “статического” анализа кода. Не мешает наличие или отсутствие уязвимостей и сортировке перечня угроз. С уверенностью можно сказать только одно: уязвимости всегда есть, даже если CVE-номер ещё не опубликовали.

P.S. Пожалуй, тут нужно привести конкретный пример. Представьте, что у вас определена следующая внутренняя угроза: “Локальный непривилегированный пользователь через уязвимость библиотеки в системном сервисе повышает права своего аккаунта и удаляет все защищаемые данные”. Зависит ли определение (хотя бы описание) этой угрозы от того, что в утилите sudo найдена уязвимость, позволяющая поднять права до суперпользователя? Нет, не зависит, хоть в определении угрозы и используется слово “уязвимость” – рассматривать такую угрозу нужно даже в том случае, если sudo вообще нет в системе. Поэтому про sudo в определении угрозы ничего нет, определение не зависит от конкретных уязвимостей, так как они рассматриваются в самом общем смысле. Появилась ли эта угроза лишь после того, как опубликовали данные об уязвимости в sudo и демонстратор (PoC)? Нет, конечно – угроза была и раньше. Появление информации о новой уязвимости (плюс один к количеству индексов в базе сканера), тут никак не повлияло на количество угроз.

Cloudflare публикуют разбор причин аварии сервиса DNS-резолвера 1.1.1.1, который некоторое время был недоступен (глобально) 14 июля 2025 года. Краткая причина, как это нередко бывает, – некорректная работа с BGP: ошибочно удалили маршруты к сервису 1.1.1.1 (это, в принципе, было понятно практически сразу). Интересный момент: написано, что после аварийного отзыва штатных маршрутов Cloudflare – анонсировать префикс 1.1.1.0/24 начала AS4755 (Tata Communications India). Но отдельно отмечено, что этот “угон префикса” не был причиной недоступности сервиса. Всё равно – странно.

12 июня 2025 года Boeing 787-8 Dreamliner (рейс AI171) потерпел катастрофу в Индии. Согласно предварительным результатам расследования (англ.) – на взлёте, в самом начале набора высоты, произошло отключение подачи топлива, полное, сразу на оба двигателя. Закрылки были выпущены на 5, что, оказывается, соответствует взлётной конфигурации (я в июне предположил, что закрылки “практически полностью убраны” – это так и есть, но, получается, что тут не повлияло практически никак).

Согласно записи регистраторов, тумблеры подачи топлива каким-то образом (объяснений нет) были переведены в положение CUTOFF (“Отключено”), практически одновременно (написано: 1 сек. между сигналами переключения тумблеров для каждого двигателя). Соответственно, двигатели начали останавливаться. На записи слышно, что один пилот спросил другого, зачем тот отключил подачу топлива, на что получил ответ – “я не отключал”. По отчёту, через (примерно) пять секунд, когда обороты упали ниже предела, вышла турбина резервного (аварийного) генератора (RAT), что видно на видеозаписи с камер наружного наблюдения, а ещё через пять секунд тумблер подачи топлива первого двигателя переведён в положение RUN (“Включено”), через четыре секунды – тумблер второго двигателя тоже переведён в RUN. Но это всё записи сигналов, как нетрудно предположить. На извлечённом из обломков секторе управления тягой ручки этих тумблеров так и стоят в положении RUN (в отчёте по ссылке есть фото). После разрешения на подачу топлива двигатели начали автоматически пробовать запуститься, но, понятно, времени уже на набор высоты не хватило. Довольно странная история.

Почему-то очередную “кросс-протокольную” атаку под названием Opossum стали в новостных сообщениях называть “атакой на TLS”. Но к TLS эта атака имеет примерно такое же отношение, как автомобиль – к дороге. Причём, сами авторы не утверждают, что это атака на TLS – на сайте она классифицирована как “кросс-протокольная атака десинхронизации на прикладном уровне”, а применима к прикладным протоколам, использующим TLS и напрямую, и “приспособительно” (opportunistic) на одном и том же логическом узле.

О чём тут идёт речь? Существуют протоколы обмена командами и данным, в которых использование TLS встроено в схему протокола. То есть, на верхнем логическом уровне, не сам обмен протокола полностью и прозрачно завернут в TLS (как HTTP в HTTPS, скажем), а TLS можно включить, при наличии возможности, уже в контексте самого протокола – пример: SMTP + STARTTLS. То есть, сеанс в рамках атакуемого протокола обязательно начинается в открытом и незащищённом варианте. Это позволяет атакующему подменить начальные сообщения той или иной стороны, а потом переключить трафик на использование TLS: либо штатными средствами протокола, либо – перенаправив трафик на другой номер порта. Атакующий при этом должен активно перехватывать сетевое соединение, подменять пакеты и прозрачно перенаправлять трафик на разные номера портов. (В исходной публикации, для одного из сценариев, ещё и требуют выполнения атакующей стороной произвольного кода в контексте веб-страницы внутри браузера.)

Так, механизм STARTTLS для SMTP – тут сервер может предложить поддержку TLS в самом начале SMTP-сессии, а клиент, если он поддерживает TLS, может тут же начать переход на защищённое соединение, просигнализировав об этом серверу. Если переход на TLS произошёл, то SMTP-сессия начинается, фактически, заново – пусть и в том же сокете, но уже внутри TLS. Но для SMTP есть и вариант с прямым TLS-подключением, то есть, сразу по TLS на другом выделенном номере порта (например, 587, а не 25). Для осуществления атаки требуется, чтобы на сервере были доступны оба способа подключения – смысл и состоит в “перекидывании” сессии между открытым соединением и подставным TLS-соединением.

Атака Opossum для SMTP предлагает атакующему возможность обмануть клиентскую программу, которая пытается подключиться с использованием STARTTLS: атакующий перехватывает соединение этой программы и отвечает вместо сервера, отправляя собственное серверное SMTP-приветствие и опцию, указывающую на STARTTLS; далее, как только клиентская программа начнёт инициировать TLS-соединение, атакующий перенаправляет начальное TLS-сообщение клиента на выделенный для TLS номер порта легитимного сервера; сервер считает, что это просто прямое подключение TLS и обрабатывает его обычным образом. Получается, что клиент прочитал подставное SMTP-приветствие и подставной список SMTP-опций, а потом начал SMTP-сессию через TLS, что для сервера выглядит обычной новой сессией. Таким образом, контекст на сервере как бы отличается от контекста на клиенте. Насколько это критично с практической точки зрения, особенно, на фоне того, что атакующий мог вообще скрыть поддержку TLS сервером, – отдельный вопрос. Но никакой атаки на TLS тут нет, TLS сработал так, как и планировалось, однако шаги штатного протокола на стороне клиента и на стороне сервера теперь не синхронизированы, из-за вмешательства атакующего – запросы и ответы переставлены на полуход. В публикации Opossum это, что логично, так и называется: “десинхронизация прикладного уровня”.

(Иллюстрация из исходной работы.)

Как ни странно, но TLS в “приспособительном” режиме возможен, – в теории, – и для HTTP. Этот вариант, впрочем, практически не встречается на веб-серверах: смысл для HTTP – тёмен, а настраивать нужно отдельно. Для случая HTTP последовательность данной атаки другая: атакующий модифицирует запросы, ответы и задерживает TLS-трафик так, что внутри TLS-сеанса оказывается ответ сервера не на легитимный запрос клиента, а на предыдущий запрос, поступивший к серверу от атакующего в открытом виде. TLS-опять же, атака не касается. Но, как и отмечено в исходной работе, все перечисленные атаки возможны потому, что TLS не предоставляет способа аутентифицировать состояние внешнего протокола на стороне сервера и клиента, а аутентифицирует только имена и адреса. Это так. Однако подобная расширенная аутентификация и не входит в модель TLS: несмотря на наличие расширений типа ALPN, TLS работает только на своём уровне. (Кстати, на ALPN описание атаки Opossum как раз ссылается: с ALPN связана вспомогательная часть и предыдущая атака по теме.)

Let’s Encrypt сообщают, что выпустили первый TLS-сертификат, валидный для IP-адреса. Это сертификат сроком валидности шесть суток, там пустое поле Subject (это важно, если вы всё ещё проверяете сертификаты по Subject), отсутствует ссылка на OCSP, но всё ещё есть ссылка на CRL. IPv6-адрес указан в Subject Alternative Name, вместе с несколькими доменными именами. Часть указанных имён, кстати, имтируют IPv6-адрес, поэтому они аж восьмого уровня. Вообще, максимальная допустимая “глубина” DNS-имён в Let’s Encrypt – десятый уровень.