![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Apr. 8th, 2026
клод митос и сила параллелизации
Apr. 8th, 2026 11:28 pmЛюдям, которые не понаслышке знают про дырки в секьюрити и как они устроены (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 сожгут зря немного токенов, ничего страшного (и не думайте, что они нагаллюционируют несуществующие баги и займут зря ваше время - дополнительный агент-судья с этим неплохо справится).
Если у вас есть компетентный программист, который может компетентно разобрать один файл исходников, то у вас нет миллиона компетентных программистов, которые могут компетентно разобрать миллион файлов исходников. Но если у вас есть компетентный ИИ-агент, который может разобрать один файл, то у вас есть миллион компетентных ИИ-агентов, которые могут разобрать миллион файлов. Важность этого обстоятельства, мне кажется, люди до сих пор очень плохо понимают.