Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
claude_opus_cve_2023_0266 — Демонстрация того, что Claude Opus не находит CVE-2023-0266 | Kitploit
Инструменты/GitHubGitHub/seanheelan/claude_opus_cve_2023_0266
Статический анализАнализ уязвимостейАнализ КодаСтатьи и ИсследованияОбучение и ОбразованиеБезопасность ИИ
GitHubseanheelan/claude_opus_cve_2023_0266

claude_opus_cve_2023_0266

Демонстрация того, что Claude Opus не находит CVE-2023-0266

Репозиторий
1632 лет назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

Демонстрация того, что Claude 3 Opus не понимает CVE-2023-0266 и не находит его (Демо 1). Даже если указать, где находится ошибка, Opus её не находит и галлюцинирует наличие захватов блокировок (Демо 2). "Промпт-инжиниринг" (то есть точное указание LLM, как найти ошибку) тоже не работает (Демо 3).

Эта Project Zero запись в блоге описывает уязвимость. Короче говоря, есть два пути, которые достигают функции snd_ctl_elem_write. Один, который выглядит так и является безопасным:

root@kitploit:~
snd_ctl_ioctl ->

  snd_ctl_elem_write_user ->

    snd_ctl_elem_write

А другой выглядит так и не является безопасным:

root@kitploit:~
snd_ctl_ioctl_compat ->

  snd_ctl_elem_write_user_compat ->

    ctl_elem_write_user ->

      snd_ctl_elem_write

Первый безопасен, так как захватывает блокировку controls_rwsem через down_write(&card->controls_rwsem); в функции snd_ctl_elem_write_user. Второй небезопасен, потому что он приходит к snd_ctl_elem_write по пути, который не включает snd_ctl_elem_write_user, и ни одна из других функций на этом пути не захватывает блокировку controls_rwsem.

Установка

Установите пакеты anthropic и python-dotenv через pip. Скопируйте .env.example в .env и вставьте в него свой ключ API Claude 3. Затем вы можете запустить main.py, original.py и multistage.py. Смотрите ниже, что делают эти файлы. Все файлы принимают каталог с кодом для анализа в качестве первого аргумента. res содержит ошибочный код, а res_patched содержит исправленный код.

Opus находит CVE-2023-0266?

Я создал этот репозиторий в ответ на этот чат Claude Opus, который был опубликован вместе с утверждением, что Opus может найти CVE-2023-0266. Если бы это было правдой, это стало бы значительным достижением для LLM. К сожалению, ошибка, о которой сообщил Claude, — это не CVE-2023-0266. На самом деле это вообще не похоже на ошибку, и предложенный Claude патч не исправляет CVE-2023-0266.

Я скопировал промпт из этого чата в original.py, хотя при запуске он не даёт идентичных результатов тем, что в опубликованном чате. Вместо этого он выдает ещё один ложный положительный результат.

Демо 1 — Неудача в поиске CVE-2023-0266

Запускается через ./main.py. Вы можете передать аргумент --chat, чтобы начать сеанс чата после того, как Opus предоставит свой первоначальный ответ, что может быть показательно для выяснения того, что именно Claude понимает/не понимает в коде.

По состоянию на сегодня (10 марта 2023 года) это то, что выдает Claude Opus (версия модели claude-3-opus-20240229):

root@kitploit:~
Код в sound/core/control.c и sound/core/control_compat.c, похоже, использует
блокировки надлежащим образом для предотвращения состояний гонки и проблем параллелизма. Вот
ключевые наблюдения:

1. Чтение-запись семафор snd_ioctl_rwsem используется для защиты списка
зарегистрированных обработчиков ioctl (snd_control_ioctls и snd_control_compat_ioctls).
Семафор захватывается для чтения при итерации по списку обработчиков
и для записи при регистрации или отмене регистрации обработчиков.

2. Чтение-запись семафор card->controls_rwsem используется для защиты списка
элементов управления, связанных с картой. Он захватывается для чтения при поиске
элемента управления или доступе к информации об элементе управления, и для записи при добавлении, удалении
или изменении элементов управления.

3. Спинлок ctl->read_lock используется для защиты списка ожидающих событий
(ctl->events), связанных с элементом управления. Он захватывается при добавлении или удалении
событий из списка, а также при ожидании событий, доступных для чтения.

4. Блокировка чтения-записи card->ctl_files_rwlock используется для защиты списка
открытых файлов управления (card->ctl_files), связанных с картой. Он захватывается для
чтения при итерации по списку файлов управления и для записи при добавлении или
удалении файлов управления.

5. Операции, связанные с событиями в snd_ctl_elem_read(), используют комбинацию
спинлока ctl->read_lock и очереди ожидания ctl->change_sleep для синхронизации
доступа к списку событий и ожидания событий.

6. Функции snd_ctl_find_numid() и snd_ctl_find_id(), которые ищут
элемент управления по его числовому идентификатору или полному идентификатору, ожидают, что семафор
card->controls_rwsem удерживается вызывающей стороной, чтобы предотвратить изменение списка элементов управления во время
поиска.

7. Функция __snd_ctl_add_replace(), которая добавляет или заменяет элемент управления,
захватывает семафор card->controls_rwsem для записи, чтобы обеспечить исключительный
доступ к списку элементов управления во время операции.

В целом, код, похоже, правильно использует блокировки для синхронизации доступа к
разделяемым структурам данных и предотвращения состояний гонки. Чтение-запись семафоры
и блокировки захватываются и освобождаются соответствующим образом в зависимости от типа требуемого
доступа (чтение или запись). Код также использует очереди ожидания для обработки
синхронизации между производителями и потребителями событий.

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

Модель считает, что код в порядке, и не замечает ошибку.

Демо 2 — Галлюцинация захвата блокировки при указании места ошибки

Что произойдет, если мы явно попросим Claude проверить, захватывается ли соответствующая блокировка на уязвимом пути?

root@kitploit:~
чат> Захватывается ли блокировка controls_rwsem на пути от snd_ctl_ioctl_compat до
snd_ctl_elem_write?

Давайте проследим путь от snd_ctl_ioctl_compat() к snd_ctl_elem_write() и
проверим, захватывается ли блокировка controls_rwsem на этом пути.

1. snd_ctl_ioctl_compat() вызывается с командой SNDRV_CTL_IOCTL_ELEM_WRITE32.

2. Внутри snd_ctl_ioctl_compat() случай SNDRV_CTL_IOCTL_ELEM_WRITE32
обрабатывается вызовом snd_ctl_elem_write_user_compat(ctl, argp).

3. snd_ctl_elem_write_user_compat() вызывает ctl_elem_write_user(file, data32,
&data32->value).

4. ctl_elem_write_user() вызывает snd_ctl_elem_write(card, file, data) после
копирования данных из пользовательского пространства.

5. snd_ctl_elem_write() захватывает блокировку записи card->controls_rwsem с помощью
down_write(&card->controls_rwsem) перед выполнением операции записи.

Итак, да, блокировка controls_rwsem захватывается на пути от
snd_ctl_ioctl_compat() к snd_ctl_elem_write() при обработке команды
SNDRV_CTL_IOCTL_ELEM_WRITE32. Блокировка захватывается в функции
snd_ctl_elem_write(), которая вызывается косвенно из
snd_ctl_ioctl_compat() через snd_ctl_elem_write_user_compat() и
ctl_elem_write_user().

Следовательно, операция записи элемента управления надлежащим образом защищена
блокировкой записи controls_rwsem.

Модель галлюцинирует захват блокировки на шаге 5 и ошибочно сообщает, что код безопасен. Для ясности, вот код функции snd_ctl_elem_write. Как видите, вызова down_write нет.

root@kitploit:~

static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
			      struct snd_ctl_elem_value *control)
{
	struct snd_kcontrol *kctl;
	struct snd_kcontrol_volatile *vd;
	unsigned int index_offset;
	int result;

	kctl = snd_ctl_find_id(card, &control->id);
	if (kctl == NULL)
		return -ENOENT;

	index_offset = snd_ctl_get_ioff(kctl, &control->id);
	vd = &kctl->vd[index_offset];
	if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || kctl->put == NULL ||
	    (file && vd->owner && vd->owner != file)) {
		return -EPERM;
	}

	snd_ctl_build_ioff(&control->id, kctl, index_offset);
	result = kctl->put(kctl, control);
	if (result < 0)
		return result;

	if (result > 0) {
		struct snd_ctl_elem_id id = control->id;
		snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, &id);
	}

	return 0;
}

Здесь Opus терпит неудачу в решении значительно более простой задачи: "Учитывая список функций, захватывается ли блокировка X?".

Ситуация становится ещё хуже, если затем попросить Opus показать нам код, который, по его утверждению, содержит захват блокировки.

root@kitploit:~
чат> Покажи мне код функции snd_ctl_elem_write и выдели
место, где она захватывает блокировку controls_rwsem

Вот код функции snd_ctl_elem_write() с выделением захвата блокировки
controls_rwsem:

<pre>
static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file,
                              struct snd_ctl_elem_value *control)
{
    struct snd_kcontrol *kctl;
    struct snd_kcontrol_volatile *vd;
    unsigned int index_offset;
    int result;

    kctl = snd_ctl_find_id(card, &control->id);
    if (kctl == NULL)
        return -ENOENT;

    index_offset = snd_ctl_get_ioff(kctl, &control->id);
    vd = &kctl->vd[index_offset];
    if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || kctl->put == NULL ||
        (file && vd->owner && vd->owner != file)) {
        return -EPERM;
    }

    snd_ctl_build_ioff(&control->id, kctl, index_offset);
    <span style="background-color: yellow;">down_write(&card->controls_rwsem);</span>
    result = kctl->put(kctl, control);
    up_write(&card->controls_rwsem);
    if (result < 0)
        return result;

    if (result > 0) {
        struct snd_ctl_elem_id id = control->id;
        snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, &id);
    }

    return 0;
}
</pre>

Как выделено в коде, вызов функции `down_write(&card->controls_rwsem)`
захватывает блокировку записи `controls_rwsem` перед вызовом функции
`kctl->put()` для выполнения фактической операции записи элемента управления.
Блокировка освобождается после операции записи с помощью
`up_write(&card->controls_rwsem)`.

Это гарантирует, что операция записи защищена блокировкой `controls_rwsem`,
предотвращая одновременный доступ к элементам управления во время выполнения записи.

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

Скачать инструмент