клод митос и сила параллелизации
Apr. 8th, 2026 11:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЛюдям, которые не понаслышке знают про дырки в секьюрити и как они устроены (buffer overruns, exploits и все такое) будет очень интересно прочитать подробный отчет Anthropic о их новой модели Mythos, с помощью которой они нашли тысячи уязвимостей в опен-сорс проектах за последние пару месяцев (Антропик не собирается пока что предоставлять широкой публике доступ к Mythos).
В тексте отчета подробно разбирают несколько багов. Возьмите для примера zero-day уязвимость в OpenBSD, которая позволяла крашнуть любой сервер OpenBSD, подключенный к интернету. Баг находился в tcp-input.c, файле обработки TCP-пакетов, этот файл обсматривали и проверяли на предмет уязвимостей десятки или сотни глаз и автоматических программ-анализаторов за последние десятки лет; тем не менее за 27 лет этот баг не обнаружили. Он довольно хитроумно соединяет два разных недочета в разных местах в коде, позволяющие с одной стороны ввести отрицательный номер пакета (бессмысленно, но в том конкретном месте не опасно), а с другой сделать его отрицательным и таким большим по модулю, чтобы сработал 32-битный overflow, и код ядра запутался, одновременно удаляя единственную запись в связном списке и добавляя новую. Попытка писать по NULL-указателю - сервер капут.
Теперь смотрите какое дело. В файле tcp-input.c больше 4000 строк кода, и он занимается кучей других вещей, кроме менеджмента списка "SACK-дырок", в котором найден этот баг. Но предположим, кто-то посадил бы меня за исходники и сказал: "я подозреваю, что в этом файле есть уязвимость, связанная с SACK-информацией в приходящих пакетах, которой можно воспользоваться. Посмотри, можешь ли ты ее найти; не забывай проверить все обычные места, где прячутся такие баги - edge cases структур данных, отрицательные значения числовых типов, overflow, overrun буферов итд. итп." Нашел бы я тогда за день-два-три этот баг? Вполне возможно, что нашел бы.
Ни у кого нет бюджета и мотивации платить много денег мне или другим компетентным программистам, чтобы они проводили кучу времени за очень скрупулезным обследованием конкретных кусков кода - не просто OpenBSD, не просто ядро OpenBSD, не просто сетевой код ядра OpenBSD, не просто TCP-опции входящего пакета, а конкретно SACK-дырки TCP-потока - при том, что неизвестно, есть там уязвимость или нет.
Но нет никакой проблемы запустить один достаточно умный (может, не AGI, но для этих целей достаточно умный) ИИ-агент, чтобы он разобрал по частям файл tcp-input.c и построил программу проверки из 10-20 отдельных частей, одна из которых SACK-дырки. И чтобы он потом запустил 10-20 отдельных ИИ-агентов, каждому из которых сказал смотреть на свою часть и искать там уязвимость. И если они достаточно умные - а в Claude Mythos этот порог, очевидно, перейден - тот из них, кому поручили на SACK-дырки смотреть, найдет этот баг. А остальные 19 сожгут зря немного токенов, ничего страшного (и не думайте, что они нагаллюционируют несуществующие баги и займут зря ваше время - дополнительный агент-судья с этим неплохо справится).
Если у вас есть компетентный программист, который может компетентно разобрать один файл исходников, то у вас нет миллиона компетентных программистов, которые могут компетентно разобрать миллион файлов исходников. Но если у вас есть компетентный ИИ-агент, который может разобрать один файл, то у вас есть миллион компетентных ИИ-агентов, которые могут разобрать миллион файлов. Важность этого обстоятельства, мне кажется, люди до сих пор очень плохо понимают.
В тексте отчета подробно разбирают несколько багов. Возьмите для примера zero-day уязвимость в OpenBSD, которая позволяла крашнуть любой сервер OpenBSD, подключенный к интернету. Баг находился в tcp-input.c, файле обработки TCP-пакетов, этот файл обсматривали и проверяли на предмет уязвимостей десятки или сотни глаз и автоматических программ-анализаторов за последние десятки лет; тем не менее за 27 лет этот баг не обнаружили. Он довольно хитроумно соединяет два разных недочета в разных местах в коде, позволяющие с одной стороны ввести отрицательный номер пакета (бессмысленно, но в том конкретном месте не опасно), а с другой сделать его отрицательным и таким большим по модулю, чтобы сработал 32-битный overflow, и код ядра запутался, одновременно удаляя единственную запись в связном списке и добавляя новую. Попытка писать по NULL-указателю - сервер капут.
Теперь смотрите какое дело. В файле tcp-input.c больше 4000 строк кода, и он занимается кучей других вещей, кроме менеджмента списка "SACK-дырок", в котором найден этот баг. Но предположим, кто-то посадил бы меня за исходники и сказал: "я подозреваю, что в этом файле есть уязвимость, связанная с SACK-информацией в приходящих пакетах, которой можно воспользоваться. Посмотри, можешь ли ты ее найти; не забывай проверить все обычные места, где прячутся такие баги - edge cases структур данных, отрицательные значения числовых типов, overflow, overrun буферов итд. итп." Нашел бы я тогда за день-два-три этот баг? Вполне возможно, что нашел бы.
Ни у кого нет бюджета и мотивации платить много денег мне или другим компетентным программистам, чтобы они проводили кучу времени за очень скрупулезным обследованием конкретных кусков кода - не просто OpenBSD, не просто ядро OpenBSD, не просто сетевой код ядра OpenBSD, не просто TCP-опции входящего пакета, а конкретно SACK-дырки TCP-потока - при том, что неизвестно, есть там уязвимость или нет.
Но нет никакой проблемы запустить один достаточно умный (может, не AGI, но для этих целей достаточно умный) ИИ-агент, чтобы он разобрал по частям файл tcp-input.c и построил программу проверки из 10-20 отдельных частей, одна из которых SACK-дырки. И чтобы он потом запустил 10-20 отдельных ИИ-агентов, каждому из которых сказал смотреть на свою часть и искать там уязвимость. И если они достаточно умные - а в Claude Mythos этот порог, очевидно, перейден - тот из них, кому поручили на SACK-дырки смотреть, найдет этот баг. А остальные 19 сожгут зря немного токенов, ничего страшного (и не думайте, что они нагаллюционируют несуществующие баги и займут зря ваше время - дополнительный агент-судья с этим неплохо справится).
Если у вас есть компетентный программист, который может компетентно разобрать один файл исходников, то у вас нет миллиона компетентных программистов, которые могут компетентно разобрать миллион файлов исходников. Но если у вас есть компетентный ИИ-агент, который может разобрать один файл, то у вас есть миллион компетентных ИИ-агентов, которые могут разобрать миллион файлов. Важность этого обстоятельства, мне кажется, люди до сих пор очень плохо понимают.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2026-04-08 08:45 pm (UTC)С помощью мифа о Психее и Афродите, этот качественный переход можно объяснить даже детям. На понимание взрослых людей надежды мало.
no subject
Date: 2026-04-08 08:55 pm (UTC)Я знаю нескольких, которые понимают и пользуются ИИ.
no subject
Date: 2026-04-08 09:17 pm (UTC)В последнее время сильно увеличился поток багрепортов связанных с безопасностью. Большинсто из них рядовые сегфолты, которые я без помпы нахожу и исправляю несколько раз в год (просто просматривая код, воспроизвести их часто непросто), и ещё больше ревьювя. Но теперь их подают как проблемы безопасности и требуют CVE. Проверка насколько серьёзна проблема и стоит ли её так квалифицировать (часто -- нет) жрёт человеческие ресурсы.
no subject
Date: 2026-04-08 10:52 pm (UTC)no subject
Date: 2026-04-09 12:05 am (UTC)Это пример задачи, которую хорошо решает искусственный интеллект. Признак задач такого рода в том, что их можно пробовать решать много раз и результат каждой такой попытки можно быстро оценивать без привлечения людей.
no subject
Date: 2026-04-09 02:38 am (UTC)всегда так мучаешься с ними, но зато ощущение безопасности. хаха
no subject
Date: 2026-04-09 07:09 am (UTC)no subject
Date: 2026-04-09 07:37 am (UTC)Как только для ее построения надо затронуть несколько разных весь паралелоизм разваливается.
no subject
Date: 2026-04-09 04:08 pm (UTC)Вот на этом месте эти десятки и сотни глаз должны были бы среагировать. Если подобные вещи считаются нормальными в OBSD, это печально.
no subject
Date: 2026-04-09 06:19 pm (UTC)no subject
Date: 2026-04-09 10:39 pm (UTC)no subject
Date: 2026-04-10 12:03 am (UTC)Собственно, приведенное описание как раз намекает, что ИИ может находить баги, основанные на ошибке в нескольких разнесенных местах, и делать это [вероятно] лучше чем человек.
"ничего страшного"
Date: 2026-04-10 07:38 am (UTC)Так что цитирую источник.
Источник:
"This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings. While the specific run that found the bug above cost under $50, that number only makes sense with full hindsight. Like any search process, we can't know in advance which run will succeed."
Плюс зарплаты исследователей - они тоже тратили свое время небесплатно.
К этому надо добавить зарплаты специалистов, которые будут весь этот набор несуразностей разгребать и чинить.
Ну и не факт что все это нельзя было обнаружить существующими средствами-линтерами, профайлерами и юнитестами.
Поэтому неясно, сколько именно наэкономили.
no subject
Date: 2026-04-10 12:07 pm (UTC)Более того, ...
Date: 2026-04-10 03:37 pm (UTC)"You can deploy cheap models broadly, scanning everything,..."
Я в программировании ничего не понимаю, но обе статьи выглядят саморекламой.
С другой стороны, нет сомнений, что AI радикально меняет наши возможности. Недавно סופר סת"מ ("софер стам" - переписчик священных текстов) сказал мне, что проверять текст на ошибки теперь очень легко, так что я могу не беспокоиться. Это сегодня делают с помощью компьютера. 100% гарантии.
Интересным применением может быть реверс-анализ платного ПО на предмет поиска украденных друг у друга программных решений. (Вроде "Диссернета" на новом уровне.)
no subject
Date: 2026-04-10 04:19 pm (UTC)no subject
Date: 2026-04-11 08:19 pm (UTC)