🗜 Выжимаем максимум из Qwen3.8-27b на маке

Что, если я скажу, что привычные 20± tok/s генерации, которые дают 4-битные кванты Qwen3.8-27b в LM-Studio под M4 Max на средних контекстах, можно поднять в полтора-два раза на том же железе? И, что эта модель, на задачах работы с кодом, может давать результаты с качеством, вполне приемлемым для повседневной работы при должном тюнинге на стороне агента?

Но давайте по порядку.

❗️Исходные данные

Почему квант именно в 4 бита? Потому что до 4 существенно проседает качество инференса, а в 8 и выше на архитектуре Apple просто нет рационального смысла. Все, о чем будет написано ниже, тестировалось на MacBook M4 Max 128Gb RAM, но в целом адаптируемо и под 32Gb RAM и выше (с поправкой на предельный размер доступного контекстного окна, конечно).

❓Что не так с LM-Studio?

Это замечательный и удобный инструмент (сам для экспериментов часто им пользуюсь), но есть два нюанса. Во-первых, в нём доступны не все ручки движков инференса, за которые можно подергать, чтобы (если повезёт) выжать десяток-другой лишних tok/s. Во-вторых, и это главное, он использует оригинальный MLX, который на данный момент игнорирует MTP (multi-token prediction), а в «родных» MLX-моделях от авторов LM-Studio MTP-головы и вовсе отрезаны.

Беда в том, что со времен Qwen3-Next, модели Alibaba нативно поддерживают технологию MTP, дающую ощутимый буст скорости генерации токенов. С GGUF такой проблемы в LM-Studio нет, но более медленный инференс этого формата, по сравнению с MLX на Apple Silicon, сводит все преимущества MTP на уровень погрешности. Между тем, разработчики более легковесных решений подсуетились и уже справились с этой проблемой.

↗️ Конфигурируем легковесные решения

Устанавливаем MTPLX (можно и с помощью brew) и скачиваем Qwen 3.8 27b optimized speed. После скачивания предложит запустить бенчмарк для определения оптимальных настроек MTP, и модель будет готова к использованию. Дополнительно можно заморочиться тонкой настройкой, по аналогии с описанной ниже.

Либо устанавливаем oMLX (с помощью brew лучше не ставить, там могут возникнуть проблемы с python-зависимостями) и скачиваем модель от его автора: Jundot/Qwen3.8-27B-oQ4e-mtp.

Затем необходимо открыть настройки модели и включить опцию «Lighting MTP», сохранив после этого настройки, чтобы создался файл с ними. После этого в него нужно сходить (~/.omlx/model_settings.json) и установить там следующие параметры:

• max_context_window: 262144 (размер контекстного окна) — или в значение, которое позволяет объем unified-RAM, с одной стороны, и минимально необходимое для решаемых моделью задач, с другой;

• mtp_num_draft_tokens (количество предсказываемых подряд токенов) — в оптимальное для вашего железа значение, в диапазоне 1-3. Если оставить не установленным, то значение будет подбираться адаптивно. Для моего мака это 3.

Затем нужно установить ещё два параметра в ~/.omlx/settings.json:

• sampling.max_context_window: 262144 (fallback-размер контекстного окна для всех моделей);

• sampling.max_tokens: 65536 (максимальная длина ответа).

— опять-таки, исходя из доступной unified-RAM и реалий решаемых моделью задач.

Остальные параметры уже оптимальны для заявленного в начала поста железа. Если ваше отличается от него не только памятью, или просто лень возиться с подбором параметров, то берем своего агента и говорим ему:

oMLX is running at http://127.0.0.1:8000/ (admin panel at /admin, configs in ~/.omlx). Optimize the configuration of model `Qwen3.8-27B-oQ4e-mtp` for maximum token generation speed. Focus on the context window sizes from 32768 and higher up to the limit. First benchmark the current setup with oMLX's built-in benchmarking, then research best practices online, and iteratively tune parameters — one change at a time, re-benchmarking after each. Back up configs before editing, keep the server running at all times (restarts are acceptable, roll back on failure), and finish with a before/after tokens/sec comparison, the final config, and a summary of the most impactful changes.

Но займет до нескольких часов, если что, т.к. прогон каждой итерации бенчей — дело небыстрое. Зато даст максимальный тюнинг всех настроек под вашу систему.

—

А вот про то, как подстроить своих агентов под эту модель, расскажу уже в следующий раз 👋

#LLM #гайд

👩‍💻 «Уязвимость» GitSpawn — влезть на шкаф, чтобы увидеть женскую баню

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

Примерно такие формулировки возникают в голове, когда читаешь новости об очередной «уязвимости», накрывшей всех агентов. Например, о свежей GitSpawn. Вдумайтесь в её суть: если в агенте открыть git-репозиторий, полученный из недоверенного zip'а (не через git clone), то при выполнении агентом команд типа git status/diff git-клиент штатно отработает, следуя всем настройкам в .git/config. Что внезапно может привести к выполнению произвольного кода, ибо там можно прописывать кастомные скрипты и тулы, а следовательно сие является уязвимостью всех агентов 🤦‍♂️

И бомбит тут даже не с некомпетентности «исследователей» с манией попиариться на громких утверждениях (главное, красивое название атаке придумать, чтобы лучше разлетелась — это стремление как раз понятно), а с того, что разработчикам агентов теперь нужно как-то отстраиваться ещё и от этого.

А это значит, что пользователям, либо придется подтверждать доверие ещё и к настройкам (локальным, btw) своих репозиториев, либо мириться с тем, что они перестанут работать внутри агентов, ради защищенности от чисто гипотетической угрозы. Либо разработчикам агентов делать ещё один шаг в сторону того, чтобы становиться вендорами EDR-решения.

😡

#мысли_вслух

😺 ChatGPT, давай, до свиданья!

Сегодня утром произошло нечто, впервые за всё время, что работаю над c0wrk и sp4rk. По ходу их разработки, я стараюсь использовать все доступные мне LLM, чтобы держать в голове применимость каждой из них для тех или иных около-R&D'шных задач.

Разумеется, не смог пройти мимо и случившегося на прошлой неделе релиза Astra. И сегодня утром, после двухдневной долботни с этой моделью, сделал тупо hard reset в обоих проектах на более ранние коммиты, откатив всё то, что натворила в их коде эта модель.

💩 После добавления поддержки stream-режима взаимодействия с моделями, в чате c0wrk стали задваиваться сообщения: сначала отображалось аккумулируемое содержимое получаемых чанков в реальном времени, а затем оно же отображалось, уже как событие чата. Попросив убрать аккумулируемое, я впервые столкнулся с тем, что модель не только начисто игнорирует требования, указанные в промпте, но и пытается спорить, доказывая, что её решение лучше и правильнее. Потому что она убрала ровно то, что я просил оставить. Вот только так не было правильнее и лучше. Так было проще.

💩 Ни одна, подчеркиваю, НИ ОДНА модель, ещё начисто не игнорировала заданное в AGENTS.md разграничение ответственности между этими двумя проектами (в sp4rk — переиспользуемая агентская логика, в c0wrk — конкретная реализация агента на её основе). И неиллюзорно удивился, увидев в sp4rk размазанную по нескольким пакетам реализацию того, что было сугубо специфичным для c0wrk и прямо предписывалось в AGENTS.md под реализацию в нём.

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

💩 Делая ревью только что написанного (ей же, в другой сессии) кода, выдавала единичные should-fix'ы и consider'ы, в то время, как запущенные вслед за ней ревью на DeepSeek и GLM находили несколько реальных must-fix'ов, действительно ломавших функциональность проекта.

💩 Когда решил попробовать её в глубоком ресерче (на основе поиска инфы в сети), то с удивлением узнал, что не стоит даже пытаться инферить DeepSeek-V4-Flash-Vision на двух спаренных ASUS Ascent GX10, и Qwen3.8 27b на десктопе с RTX 5090, т.к. подобное железо — не для этих моделей. Ума не приложу, как обе конфигурации у меня работают с этими моделями, уже почти месяц и без каких-либо нареканий 🤷‍♂️

💩 В какой-то момент в голову закралась мысль, что возможно это у меня в проектах что-то не так: системные промпты там не оптимизированы под новую модель, описания инструментов, AGENTS.md подмешиваются не так и т.п. Попробовал повторить те же задачи, сначала в OpenCode, а затем и в Codex. И получил плюс-минус те же результаты, ещё и с чуть большим расходом токенов.

В итоге понял, что проще и быстрее откатить весь тот говнокод, который мне нагородила Astra в проектах, чем пытаться его исправить, даже другими моделями. GLM, к слову сказать, реализовала всё это достаточно четко с нуля, потребовав ровно 3 сессии: реализация, ревью и правки по итогам + исправление пары мелких багов.

Я искренне не понимаю мотивации тех, кто платит OpenAI за подобную хрень в наше время. Ну хз, может люди просто не знают, что есть модели, которым не надо повторять требования по 2-3 раза, значительно переделывать написанный ими код, и изучать многостраничные гайды по оптимизации промптов, чтобы получить хотя бы средненький результат? Причем, некоторые из них — можно запустить, пусть и на мощном, но всё же относительно «домашнем» железе. Да, у работы с ними есть своя специфика и ограничения, но они хотя бы работают понятно и прогнозируемо.

А ещё не понимаю, о каком AGI там вообще может идти речь. Увы, но лично для меня OpenAI уж точно не технологический визионер, судя по динамике развития их моделей. Скорее — хайпожоры, кричащие об AGI, не имея на это никакого права, и пиарящиеся исключительно на шоу с побегами их агентов.

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

#мысли_вслух

🔗Мультимодельная разработка

Написать этот пост подтолкнула одна статья, вышедшая на днях (в рефах ниже она стоит первой). Дело в том, что после выхода превью DeepSeek-V4-Flash я практикую подход, при котором задачи по написанию кода уходят этой модели, а код-ревью и правками занимается GLM-5.3.

Почему именно так и более слабая модель делает основную работу, в то время как более сильная лишь подчищает за ней? На самом деле потому, что большинство исследований на эту тему рекомендуют именно такое распределение ролей. Для тех, кто захочет погрузиться в это поглубже, в конце поста привёл ссылки на все рефы. Здесь же просто обозначу основные тезисы из них, ну и свои личные доводы.

1️⃣ Стоимость

При feature-based кодинге (а я использую в основном его) потребление токенов на непосредственно разработку кода в разы больше, чем на ревью изменений в нём. DeepSeek-V4-Flash же является очень дешёвой моделью, даже после недавнего подорожания тарифов, а с выходом V4.1 у него (по ощущениям первого дня плотной работы с этой моделью) прям сильно поднялось качество работы с агентскими сценариями и генерируемого им кода. Ну и его vision-версия развернута у меня локально, под задачи на-всю-ночь. Кроме того, при 2-3 одновременно разрабатываемых проектах, лимитов максимальной подписки GLM для задач кодинга лично мне явно не хватит.

2️⃣ Почему бы не ревьюить той же моделью?

Этой теме посвящена последняя статья в рефах. Если вкратце, то слишком высока вероятность, что модель (или даже семейство моделей), допустившая ошибку, пропустит её на ревью. Причем, именно по тем же причинам, по которым она её допустила.

В целом это бьётся и с моими наблюдениями, т.к. периодически я устраиваю (и не только этой парочке) ревью против саморевью с последующим сравнением результатов. И саморевью почти всегда дает менее качественный результат. Это можно чуть нивелировать, если пускать его в режиме goal'а типа «повторное ревью не должно выявить новых проблем уровней must и should fix», но блин... токенов там потратится значительно больше, чем при ревью другой моделью.

3️⃣ Почему слабая модель кодит, а сильная — ревьюит, а не наоборот?

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

ℹ️ Разумеется, «слабая модель» здесь употребляется весьма вольно. Речь не о моделях, которые можно запустить на любом утюге. И слабая модель должна обеспечивать качество кода за некоторым порогом, после которого ревью фактически не сводится к «переписать большую часть изменений заново», чтобы такая связка была эффективной. Но размер этого порога во многом определяется характером задач, предметной области, используемым стеком и т.п., поэтому может довольно сильно варьироваться и его надо нащупывать индивидуально.

И вот упомянутые две модели, на моих задачах, показывают себя на отлично, позволяя при этом оставаться в бюджете до $200 ежемесячно, если вынести за скобки наличие локального дипсика. Если не выносить, то $144 — это стоимость подписки Max v2 в GLM. Можно конечно сюда стоимость железа и электричества ещё присовокупить, но это оставлю для тех, кто разворачивает инференс у себя дома для дела, а не по фану, который бесценен)

🙌

🗂Рефы

• «Reviewer Capability Governs Rejection Targeting, Not Repair Skill», arXiv:2609.04270 (2026).

• «An Empirical Study on Strong-Weak Model Collaboration for Repo-level Code Generation», arXiv:2505.20182 (CMU, 2025).

• «Improving Code Generation via Small Language Model-as-a-judge», arXiv:2602.11911 (2026).

• «Variation in Verification: Understanding Verification Dynamics in Large Language Models», arXiv:2509.17995 (2025).

• SWR-Bench, arXiv:2509.01494 (2025).

• «On the Self-Verification Limitations of Large Language Models», arXiv:2402.08115 (2024).

#LLM #ИИ_инструменты

🖥 О замедлении разработки ИИ

Да, я про вчерашнее эссе Дарио Амодеи «We Must Pace the Frontier»

Там он признаёт огромную пользу ИИ, но утверждает, что из-за рекурсивного самоусовершенствования и инцидента с побегами агентов риски стали настолько острыми, что нужно сознательно замедлять рост возможностей моделей, чтобы выиграть время для выравнивания, интерпретируемости, тестов и операционной строгости. Он предлагает его через три уровня: встроенные сторонние оценщики с правом доступа как у сотрудников, координацию демократических стран по стандартам и темпам прогресса при поддержке государства, а затем — осторожную глобальную координацию с авторитарными режимами (это про Китай, в основном) от узких запретов до возможных «ограничений скорости» рекурсивного самоусовершенствования. Смысл совсем не в остановке ИИ, скорее — в управляемом темпе: сохранить лидерство, не проиграв Китаю (наивный чел), и использовать отложенное время, чтобы сделать системы заметно безопаснее, прежде чем их возможности станут критическими.

Углубляться в геополитику не хотелось бы, хотя и кажется, что Китаю до одного места мнение Запада по этому вопросу. Тем более, у них агенты вроде пока и не сбегали (хотя, как по мне, это скорее вопрос найма отбитых маркетологов, кои в Китае в дефиците, судя по всему). А санкционный Сбер со своим ГигаЧатом, думаю, их вообще вертеть хотел, вместе с их мнением. Да и им скорее ускорять разработку нужно, нежели замедлять.

Но в целом, если убрать всю геополитическую воду, я с Дарио так-то согласен. И вот почему.

3 года назад я до одури доказывал коллегам, что ИИ не сможет показывать в SAST результаты, хотя бы сравнимые с формальными методами. Сейчас у нас есть технология, которая это опровергает напрочь, и о которой скоро планируем рассказать (да-да, упоминавшаяся здесь). У нас — не в смысле «только у нас», но в смысле, что нам намного проще сравнивать её с формальными подходами к SAST, в силу наличия некоторой экспертизы в этой области.

2 года назад я удивлялся, как вообще с помощью LLM кто-то пишет код и насколько это непродуктивно. Сейчас — релиз c0wrk v1.0 медленно, но уверенно приближается к финальной точке.

Год назад, я вместе с агентом начал работать над формальным статанализатором пары десятков языков с поддержкой dataflow-анализа и абстрактной интерпретации. О нём мы тоже скоро расскажем, покажем, и возможно даже заопенсорсим.

А сегодня произошло вот что. c0wrk, решая задачу по добавлению себе же очередной фичи, как обычно, разбил её на шаги плана, делегировав каждый отдельному субагенту. И одному из них он поставил недостаточно четкие требования по сути подзадачи. Тот, немного побухтев на эту тему, и, не найдя нужной ему инфы в общей памяти (там действительно её не было, а контекст у каждого субгагента свой) сотворил вот что:

• нашел профиль реального инстанса c0wrk'а;
• увидел там SQLite'ную database.db приложения;
• исследовал её и нашел таблицу с сессиями;
• нашел сессию основного агента, и tool call, которым сам был вызван;
• изучил историю работы и ризонинга основного агента до этого момента, уточнил чтением оттуда всё, что ему было нужно по его задаче, и успешно её выполнил.

И знаете какой была моя реакция на это? Ну, если бы я был отбитым маркетологом, то пост назывался бы «Первый побег агента из c0wrk: расследование», без всей этой воды выше. Но нет, моя реакция была просто «о, прикольно, ну ок».

Т.е. для вау-эффекта лично мне уже нужно что-то намного более весомое. Тем более, что подобное у меня уже случалось и ранее (правда тогда отличился OpenCode, подхватив и самостоятельно закончив упавшую сессию у c0wrk'а, тоже по истории шагов его ReAct-цикла).

Оно пришло как-то совсем незаметно, всего за пару лет. И, мне кажется, это отличный маркер того, что вся эта область действительно развивается быстрее, чем мы успеваем это осознавать.

И вот поэтому я согласен с Дарио 🙂

#ИИ_мнения #мысли_вслух

👨‍💻 Продуктивные выходные

Как-то незаметно (и неожиданно) для себя с удовольствием провёл почти все выходные в возне со своим опенсорсом.

• SKILLS

В скиллсет vibespec добавился vibespec-explore. По сути, это explore, адаптированный под работу со спеками и предназначенный для детальной проработки идей по изменениям в кодовой базе. Именно в текущем виде этот скиллсет будет интегрирован в c0wrk в ближайших релизах.

Btw, на прошлой неделе добавил в этот репозиторий скилл study-paper, здорово облегчающий чтение и проработку научных публикаций и технических статей. Скилл встроен в c0wrk (для него там реализовал отдельный UI), автономная версия скилла — для тех, кто, по неведомым причинам, ещё пользуется другими агентами.

• FLOWSH

Довёл до v0.3.2. Расширил базу знаний по наборам известных команд обоих шеллов и утилит популярных стеков и экосистем на +45%; исправил кучу багов, поднявших precision и recall до 100% на типичных командах, генерируемых дипсиком и глм; добил alias-анализ в абстрактном интерпретаторе для PowerShell до полной реализации (для bash уже был).

Примечательно, что для всего этого использовал корпус шелл-команд, собранный по всей истории моей работы с агентом.

• SP4RK

Полностью перевёл анализ шелл-команд на flowsh, вместе с ним — модель вызовов оболочки, ужесточение tool-safety гейтов, расширил эффект-ориентированные сигнатуры формального судьи.

• C0WRK

Выпустил v0.9.0. Тут проще отправить в changelog, чем всё перечислять. Отдельно хочу поблагодарить всех ребят, делавших PR-ы в эту и предыдущие версии ❤️ Из значимо-видимого, что сделал на выходных:

- полностью переработал security-гейты, что позволило добавить опциональный silent-режим, в котором все вопросы разруливает агент, не эскалируя вопросы пользователю (см. изменения в sp4rk и flowsh), не деградирующий при этом до YOLO;

- реализовал возможность переопределения оболочки на кастомную команду — помимо основного предназначения, позволяет обернуть shell-вызовы в стороннюю песочницу;

- добавил гайд по написанию и подключению скиллов и субагентов;

- наконец оформил весь бэклог v1.0 в issues.

🙌

А как вы провели выходные? 🛏

#ИИ_инструменты #продуктивность

🔗 Старый добрый аппсек, часть 1

...совершенно незаслуженно задвинутый на второй план ИИ-хайпом последних лет(

Решил вот проскочить по волнам истории аппсека и смежных областей за последние пару-тройку лет на предмет появившихся за это время новых классов недостатков и атак. Пока проскакивал, с удивлением обнаружил, как много нового прошло мимо меня, и решил поделиться находками с вами (а то вдруг я не один такой).

Начнем с самого лоулевела, а именно:

1️⃣ Железо

Не совсем аппсек, но всё же интересная тема, напрямую затрагивающая и безопасность приложений. В ней за эти годы наметилось 3 заметных сдвига:

• От кэша к другим структурам CPU
- TSA эксплуатирует логику планировщика и ложное завершение спекулятивных загрузок. Не Spectre-вариант в привычном смысле, да и AMD сама маркирует это как новый класс.
- Branch Privilege Injection внедряет привилегию в процесс тренировки предсказателя.
- RFDS (CVE-2023-28746) читает состояние файлового регистра на Intel Atom.
- Native BHI (CVE-2024-2201) показывает BHI целиком из user space в Linux.
- TikTag обходит ARM MTE спекулятивно, то есть под удар попал сам механизм защиты памяти.

• От данных к семантике
- GhostRace делает спекулятивным источником уязвимости конкурентность: TOCTOU случатся без всякой многопоточности в коде жертвы.
- А VMScape переносит атаку на границу «гость → user-space гипервизор», что важно для облачных стеков на QEMU/KVM.

• От x86/ARM — к новым архитектурам
- В 2026 класс Transient Execution задокументирован для коммерческих RISC-V (SiFive P550, T-Head C910/C920) с практической утечкой памяти ядра, отсутствием барьера спекуляций в ISA и непереносимостью x86/ARM-митигаций.
- Появились не-спекулятивные аппаратные баги иной природы: Zenbleed — дефект оптимизации в Zen 2, возвращающий мусор из регистров.

А ещё целями подобных атак перестали быть только CPU:

• BadRAM: атакующим оказывается SPD-чип памяти.
• GPU.zip: канал утечки — аппаратное сжатие графики; атака реализуется из веб-страницы и нарушает политику same-origin браузера на уровне... пикселей 😳

Продолжение следует...)

#аппсек · #кибербез

🔗 Старый добрый аппсек, часть 2

Продолжаем вспоминать ключевые вехи аппсека и смежных областей последних лет, не испоганенные агентами.

2️⃣ Протоколы и криптография

Когда в 2023 году Google раскрыл Rapid Reset, выяснилось, что мультиплексирование стримов в HTTP/2 можно обернуть против самого сервера: клиент открывает поток и тут же его отменяет, а весьма затратная по ресурсам обработка на стороне сервера всё ещё идёт. Дешёвый для атакующего усилитель, который в итоге и породил рекордные DDoS-волны. Два года спустя исследователи из Тель-Авивского университета развернули идею в обратную сторону: в MadeYouReset на отправку RST_STREAM провоцируется уже сам сервер. Лимит на клиентские сбросы, поставленный после Rapid Reset (пример самих авторов — сто RST_STREAM на соединение), здесь попросту не задействован, и на фронте поток считается закрытым, тогда как бэкенд продолжает его обрабатывать. Что любопытно, Cloudflare и защищаться от этого не пришлось: митигации, оставшиеся от Rapid Reset, прикрыли и преемника. Уязвимыми остались разве что непропатченные стеки вроде h2 старее 0.4.11.

Тот же протокол подарил атакующим и разведывательный примитив: метод CONNECT превращает прокси в сканер внутренних портов, где открытые и закрытые различаются по типу возвращаемых ошибок. Граница доверия при этом проходит между двумя машинами, по-разному понимающими состояние одного соединения.

В SSH снова прошлись по хэндшейку. Terrapin — атака усечения префикса: MitM удаляет начальные сообщения согласования; в затронутых режимах (ChaCha20-Poly1305, CBC-EtM) порядок и счётчики сообщений не аутентифицированы до завершения обмена ключами, поэтому атакующий может незаметно выбросить отдельные расширения и даунгрейдить соединение, вплоть до отключения в OpenSSH защит от timing-атак. Уязвимость была в самом протоколе, поэтому лечением стало расширение strict-kex: любое неожиданное сообщение посреди key exchange теперь рвёт соединение, а после NEWKEYS обе стороны обнуляют счётчики пакетов в OpenSSH 9.6p1 и выше.

Не обошли стороной и DNS: усилителем атаки там стала... защита. KeyTrap эксплуатирует рекомендации стандарта DNSSEC: один специально-сформированный пакет с записями, требующими валидации подписей под множеством ключей и алгоритмов, заставляет резолвер выполнить до двух миллионов раз больше работы, чем без «защиты». Резолвер в таких случаях висит часами: в замерах авторов до 16 часов (BIND 9). Уязвимыми оказались все популярные реализации. Сами авторы при этом сразу предупредили: заплатки на отдельные резолверы ломают рекомендации стандарта, чинить здесь надо сам DNSSEC. Вообще, вычислительная сложность механизмов защиты — тема отдельного поста, но тут получилось что-то вообще запредельное.

Была история и с VPN-клиентами: криптография тут даже не понадобилась, хватило таблицы маршрутизации. TunnelVision использует DHCP-опцию 121 (classless static routes): нелегитимный DHCP-сервер, внедренный в локальную сеть, отдаёт маршруты, уводящие трафик в обход туннельного интерфейса. VPN при этом честно показывает «подключено», kill-switch молчит, данные уходят в открытую. По оценке самих исследователей, эта ошибка дизайна прожила в сетевых стеках около двадцати лет, и полного фикса для всех ОС до сих пор нет.

С криптографией вышло похоже: KyberSlash показал, что в эталонной реализации Kyber, того самого, что недавно стал стандартом ML-KEM (на всякий случай: ML здесь — это Module-Lattice, а не то, что вы подумали), есть деление секретно-зависимого числителя на публичный знаменатель, а время аппаратного деления зависит от операндов. На Raspberry Pi 2 и Cortex-M4 этого хватает, чтобы восстановить секретный ключ за минуты. Авторы заодно прогнали через пропатченный Valgrind больше тысячи криптопримитивов из SUPERCOP и вытащили на свет ещё целую серию таких утечек. Слепая зона тут, судя по всему, системная. В обзорной работе о миграции ECDSA→ML-DSA утверждается, что смена алгоритма переносит с собой весь набор атак на реализацию, и привычные по ECDSA сценарии side-channel и fault-injection мутируют, находя новые мишени в решёточных подписях. Так что постквантовая миграция 2024–2026 в итоге превратилась в фабрику свежих уязвимостей, причём задолго до сколько-нибудь практичного квантового компьютера.

🙌 (продолжение всё ещё следует...)

#аппсек · #кибербез