![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
клод митос и сила параллелизации
Людям, которые не понаслышке знают про дырки в секьюрити и как они устроены (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 сожгут зря немного токенов, ничего страшного (и не думайте, что они нагаллюционируют несуществующие баги и займут зря ваше время - дополнительный агент-судья с этим неплохо справится).
Если у вас есть компетентный программист, который может компетентно разобрать один файл исходников, то у вас нет миллиона компетентных программистов, которые могут компетентно разобрать миллион файлов исходников. Но если у вас есть компетентный ИИ-агент, который может разобрать один файл, то у вас есть миллион компетентных ИИ-агентов, которые могут разобрать миллион файлов. Важность этого обстоятельства, мне кажется, люди до сих пор очень плохо понимают.
no subject
С помощью мифа о Психее и Афродите, этот качественный переход можно объяснить даже детям. На понимание взрослых людей надежды мало.
no subject
Я знаю нескольких, которые понимают и пользуются ИИ.
no subject
В последнее время сильно увеличился поток багрепортов связанных с безопасностью. Большинсто из них рядовые сегфолты, которые я без помпы нахожу и исправляю несколько раз в год (просто просматривая код, воспроизвести их часто непросто), и ещё больше ревьювя. Но теперь их подают как проблемы безопасности и требуют CVE. Проверка насколько серьёзна проблема и стоит ли её так квалифицировать (часто -- нет) жрёт человеческие ресурсы.
no subject
no subject
Это пример задачи, которую хорошо решает искусственный интеллект. Признак задач такого рода в том, что их можно пробовать решать много раз и результат каждой такой попытки можно быстро оценивать без привлечения людей.
no subject
всегда так мучаешься с ними, но зато ощущение безопасности. хаха
no subject
no subject
Как только для ее построения надо затронуть несколько разных весь паралелоизм разваливается.
no subject
Собственно, приведенное описание как раз намекает, что ИИ может находить баги, основанные на ошибке в нескольких разнесенных местах, и делать это [вероятно] лучше чем человек.
no subject
no subject
Вот на этом месте эти десятки и сотни глаз должны были бы среагировать. Если подобные вещи считаются нормальными в OBSD, это печально.
no subject
no subject
no subject
"ничего страшного"
Так что цитирую источник.
Источник:
"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."
Плюс зарплаты исследователей - они тоже тратили свое время небесплатно.
К этому надо добавить зарплаты специалистов, которые будут весь этот набор несуразностей разгребать и чинить.
Ну и не факт что все это нельзя было обнаружить существующими средствами-линтерами, профайлерами и юнитестами.
Поэтому неясно, сколько именно наэкономили.
Более того, ...
"You can deploy cheap models broadly, scanning everything,..."
Я в программировании ничего не понимаю, но обе статьи выглядят саморекламой.
С другой стороны, нет сомнений, что AI радикально меняет наши возможности. Недавно סופר סת"מ ("софер стам" - переписчик священных текстов) сказал мне, что проверять текст на ошибки теперь очень легко, так что я могу не беспокоиться. Это сегодня делают с помощью компьютера. 100% гарантии.
Интересным применением может быть реверс-анализ платного ПО на предмет поиска украденных друг у друга программных решений. (Вроде "Диссернета" на новом уровне.)
no subject