Rustc
Уязвимости
26
Эксплуатируемые
0
Макс. CVSS
10
Макс. EPSS
0.20342
Распределение по критичности
Критический
4
Высокий
12
Средний
10
Низкий
0
Также сопоставлено как (исходные строки): rustc
Топ уязвимостей
CVE-2024-24576Rust - это язык программирования. Рабочая группа Rust Security Response WG была уведомлена о том, что стандартная библиотека Rust до версии 1.77.2 неправильно экранировала аргументы при вызове пакетных файлов (с расширениями `bat` и `cmd`) на Windows с использованием `Command`. Злоумышленник, способный контролировать аргументы, передаваемые создаваемому процессу, мог выполнить произвольные команды оболочки, минуя экранирование. Серьезность этой уязвимости критична для тех, кто вызывает пакетные файлы на Windows с ненадежными аргументами. Ни одна другая платформа или использование не затрагиваются.
APIs `Command::arg` и `Command::args` указывают в своей документации, что аргументы передаются создаваемому процессу как есть, независимо от содержания аргументов, и не будут оцениваться оболочкой. Это означает, что передача ненадежного ввода в качестве аргумента должна быть безопасной.
На Windows реализация этого более сложная, чем на других платформах, потому что Windows API предоставляет только одну строку, содержащую все аргументы для создаваемого процесса, и именно от самого создаваемого процесса зависит их разделение. Большинство программ используют стандартное C среднее время argv, что на практике приводит к в основном согласованному способу разделения аргументов.
Однако одно исключение — это `cmd.exe` (используемый, среди прочего, для выполнения пакетных файлов), который имеет свою собственную логику разделения аргументов. Это заставляет стандартную библиотеку реализовывать пользовательское экранирование для аргументов, передаваемых в пакетные файлы. К сожалению, было сообщено, что наша логика экранирования была недостаточно тщательной, и было возможно передать злонамеренные аргументы, которые приведут к произвольному выполнению оболочки.
Из-за сложности `cmd.exe` мы не смогли найти решение, которое правильно экранирует аргументы во всех случаях. Чтобы сохранить наши гарантии API, мы улучшили надежность кода экранирования и изменили API `Command`, чтобы возвращать ошибку `InvalidInput`, когда он не может безопасно экранировать аргумент. Эта ошибка будет сгенерирована при создании процесса.
Исправление включено в Rust 1.77.2. Обратите внимание, что новая логика экранирования пакетных файлов принимает консервативную позицию и может отклонить допустимые аргументы. Тем, кто реализует экранирование самостоятельно или обрабатывает только доверенные вводы на Windows, также можно использовать метод `CommandExt::raw_arg`, чтобы обойти логику экранирования стандартной библиотеки.
CVE-2021-31162В стандартной библиотеке Rust до версии 1.52.0 двойное освобождение может произойти в функции Vec::from_iter, если освобождение элемента вызывает панику.
CVE-2021-28879В стандартной библиотеке Rust до версии 1.52.0 реализация Zip может сообщать о неправильном размере из-за переполнения целого числа. Эта ошибка может привести к переполнению буфера, когда повторно используется использованный итератор Zip.
CVE-2020-36318В стандартной библиотеке Rust до версии 1.49.0 в VecDeque::make_contiguous есть ошибка, из-за которой один и тот же элемент извлекается несколько раз при определенных условиях. Эта ошибка может привести к использованию памяти после освобождения или двойному освобождению.
CVE-2021-42574Проблема была обнаружена в двунаправленном алгоритме в спецификации Unicode до версии 14.0. Он разрешает визуальное изменение порядка символов с помощью управляющих последовательностей, которые можно использовать для создания исходного кода, который отображает другую логику, чем логический порядок токенов, принимаемых компиляторами и интерпретаторами. Злоумышленники могут использовать это для кодирования исходного кода для компиляторов, принимающих Unicode, таким образом, чтобы целевые уязвимости были внесены невидимо для проверяющих. ПРИМЕЧАНИЕ: Консорциум Unicode предлагает следующий альтернативный подход к представлению этой проблемы. Отмечена проблема в природе международного текста, которая может повлиять на приложения, реализующие поддержку стандарта Unicode и двунаправленного алгоритма Unicode (все версии). Из-за поведения отображения текста, когда текст включает символы слева направо и справа налево, визуальный порядок токенов может отличаться от их логического порядка. Кроме того, управляющие символы, необходимые для полной поддержки требований двунаправленного текста, могут еще больше запутать логический порядок токенов. Если не принять меры, злоумышленник может создать исходный код таким образом, что порядок токенов, воспринимаемый проверяющими, не будет совпадать с тем, что будет обработано компилятором/интерпретатором/и т. д. Консорциум Unicode задокументировал этот класс уязвимостей в своем документе Unicode Technical Report #36, Unicode Security Considerations. Консорциум Unicode также предоставляет рекомендации по смягчению последствий для этого класса проблем в Unicode Technical Standard #39, Unicode Security Mechanisms, и в Unicode Standard Annex #31, Unicode Identifier and Pattern Syntax. Кроме того, спецификация BIDI позволяет приложениям адаптировать реализацию способами, которые могут смягчить вводящее в заблуждение визуальное изменение порядка в тексте программы; см. HL4 в Unicode Standard Annex #9, Unicode Bidirectional Algorithm.
CVE-2020-36323В стандартной библиотеке Rust до версии 1.52.0 есть оптимизация для объединения строк, которая может привести к раскрытию неинициализированных байтов (или к сбою программы), если заимствованная строка изменяется после проверки ее длины.
CVE-2024-43402Rust — это язык программирования. Исправление для CVE-2024-24576, где `std::process::Command` неправильно экранировал аргументы при вызове пакетных файлов в Windows, было неполным. До Rust версии 1.81.0 можно было обойти исправление, если имя пакетного файла содержало завершающие пробелы или точки (которые игнорируются и удаляются Windows). Чтобы определить, следует ли применять правила экранирования `cmd.exe`, исходное исправление для уязвимости проверяло, заканчивается ли имя команды на `.bat` или `.cmd`. В то время этого казалось достаточно, поскольку мы отказываемся вызывать пакетные скрипты без расширения файла. Windows удаляет завершающие пробелы и точки при анализе путей к файлам. Например, `.bat. .` интерпретируется Windows как `.bat`, но исходное исправление этого не проверяло. Затронутые пользователи, использующие Rust 1.77.2 или более поздней версии, могут удалить завершающие пробелы (ASCII 0x20) и завершающие точки (ASCII 0x2E) из имени пакетного файла, чтобы обойти неполное исправление и включить меры по смягчению последствий. Пользователи подвержены риску, если их код или одна из их зависимостей вызывает пакетный скрипт в Windows с завершающими пробелами или завершающими точками в имени, и передает ему ненадежные аргументы. Rust 1.81.0 обновит стандартную библиотеку для применения мер по смягчению последствий CVE-2024-24576 ко всем вызовам пакетных файлов, независимо от завершающих символов в имени файла.
CVE-2022-23639crossbeam-utils предоставляет атомарные операции, примитивы синхронизации, потоки с заданной областью видимости и другие утилиты для параллельного программирования на Rust. crossbeam-utils до версии 0.8.7 некорректно предполагал, что выравнивание `{i,u}64` всегда такое же, как и `Atomic{I,U}64`. Однако выравнивание `{i,u}64` на 32-битной цели может быть меньше, чем `Atomic{I,U}64`. Это может вызвать невыровненный доступ к памяти и гонку данных. Эта проблема затрагивает крейты, использующие методы `fetch_*` с `AtomicCell<{i,u}64>`. 32-битные цели без `Atomic{I,U}64` и 64-битные цели не затрагиваются этой проблемой. Это было исправлено в crossbeam-utils 0.8.7. В настоящее время нет известных обходных путей решения этой проблемы.
CVE-2019-12083Стандартная библиотека языка программирования Rust 1.34.x до 1.34.2 содержит стабилизированный метод, который, если его переопределить, может нарушить гарантии безопасности Rust и вызвать небезопасность памяти. Если метод `Error::type_id` переопределен, то любой тип может быть безопасно преобразован в любой другой тип, что вызывает уязвимости безопасности памяти в безопасном коде (например, запись или чтение за пределами границ). Код, который не реализует вручную Error::type_id, не подвержен уязвимости.
CVE-2021-28878В стандартной библиотеке Rust до версии 1.52.0 реализация Zip вызывает __iterator_get_unchecked() более одного раза для одного и того же индекса (при определенных условиях), когда используются вместе next_back() и next(). Эта ошибка может привести к нарушению безопасности памяти из-за невыполненного требования безопасности для трейта TrustedRandomAccess.
CVE-2021-28877В стандартной библиотеке Rust до версии 1.51.0 реализация Zip вызывает __iterator_get_unchecked() для одного и того же индекса более одного раза при вложении. Эта ошибка может привести к нарушению безопасности памяти из-за невыполненного требования безопасности для трейта TrustedRandomAccess.
CVE-2021-28875В стандартной библиотеке Rust до версии 1.50.0 read_to_end() не проверяет возвращаемое значение из Read в небезопасном контексте. Эта ошибка может привести к переполнению буфера.
CVE-2015-20001В стандартной библиотеке Rust до версии 1.2.0 BinaryHeap не является безопасной при панике. Двоичная куча остается в несогласованном состоянии, когда сравнение универсальных элементов внутри sift_up или sift_down_range вызывает панику. Эта ошибка приводит к удалению обнуленной памяти как произвольного типа, что может привести к нарушению безопасности памяти.
CVE-2018-1000810The Rust Programming Language Standard Library версии 1.29.0, 1.28.0, 1.27.2, 1.27.1, 127.0, 126.2, 126.1, 126.0 содержит CWE-680: Целочисленное переполнение в уязвимость переполнения буфера в стандартной библиотеке, что может привести к переполнению буфера. Эта атака, по-видимому, может быть осуществлена, если str::repeat, переданное большое число, может переполнить внутренний буфер. Эта уязвимость, по-видимому, была устранена в версии 1.29.1.
CVE-2018-1000657Rust Programming Language Rust standard library версии Commit bfa0e1f58acf1c28d500c34ed258f09ae021893e и более поздние; стабильный выпуск 1.3.0 и более поздние содержит уязвимость переполнения буфера в функции std::collections::vec_deque::VecDeque::reserve(), что может привести к произвольному выполнению кода, но в настоящее время не опубликовано никаких концептуальных эксплойтов. Эта уязвимость, по-видимому, была устранена после коммита fdfafb510b1a38f727e920dccbeeb638d39a8e60; стабильный выпуск 1.22.0 и более поздние.
CVE-2021-29922library/std/src/net/parser.rs в Rust до версии 1.53.0 неправильно учитывает посторонние нули в начале строки IP-адреса, что (в некоторых ситуациях) позволяет злоумышленникам обходить контроль доступа, основанный на IP-адресах, из-за неожиданной восьмеричной интерпретации.
CVE-2023-38497Cargo загружает зависимости проекта Rust и компилирует проект. Cargo до версии 0.72.2, который был упакован с Rust до версии 1.71.1, не учитывал umask при извлечении архивов crate на системах, подобных UNIX. Если пользователь загрузил crate, содержащий файлы, доступные для записи любым локальным пользователем, другой локальный пользователь мог бы использовать это, чтобы изменить исходный код, скомпилированный и выполненный текущим пользователем. Чтобы предотвратить использование существующих кэшированных извлечений, бинарная версия Cargo 0.72.2, включенная в Rust 1.71.1 или более поздние версии, автоматически очистит кэши, сгенерированные более старыми версиями Cargo. В качестве обходного пути, настройте систему, чтобы предотвратить доступ других локальных пользователей к каталогу Cargo, обычно расположенный в `~/.cargo`.
CVE-2023-40030Cargo загружает зависимости проекта Rust и компилирует проект. Начиная с Rust 1.60.0 и до 1.72, Cargo не экранировал имена функций Cargo при включении их в отчет, сгенерированный `cargo build --timings`. Вредоносный пакет, включенный в качестве зависимости, может внедрить сюда почти произвольный HTML, что потенциально может привести к межсайтовому скриптингу, если отчет впоследствии будет куда-то загружен. Уязвимость затрагивает пользователей, полагающихся на зависимости из git, локальных путей или альтернативных реестров. Пользователи, которые полагаются исключительно на crates.io, не подвержены риску.
Rust 1.60.0 представил `cargo build --timings`, который создает отчет о том, сколько времени заняли различные этапы процесса сборки. Он включает списки функций Cargo для каждого крейта. До Rust 1.72 имена функций Cargo могли содержать почти любые символы (за некоторыми исключениями, используемыми синтаксисом функций), но это вызывало предупреждение о будущей несовместимости, начиная с Rust 1.49. crates.io гораздо строже относится к тому, что он считает допустимым именем функции, и не допускает такие имена функций. Поскольку имена функций включались в отчет о времени без экранирования, их можно было использовать для внедрения Javascript на страницу, например, с именем функции, таким как `features = ["<img src='' onerror=alert(0)"]`. Если бы этот отчет впоследствии был загружен в домен, использующий учетные данные, внедренный Javascript мог бы получить доступ к ресурсам посетителя веб-сайта.
Эта проблема была исправлена в Rust 1.72, превратив предупреждение о будущей несовместимости в ошибку. Пользователям по-прежнему следует проявлять осторожность при выборе загружаемого пакета, включая в свои проекты только доверенные зависимости. Обратите внимание, что даже с исправленными этими уязвимостями Cargo по замыслу разрешает произвольное выполнение кода во время сборки благодаря сценариям сборки и процедурным макросам: вредоносная зависимость сможет нанести ущерб независимо от этих уязвимостей. crates.io имеет серверные проверки, предотвращающие эту атаку, и на crates.io нет пакетов, использующих эти уязвимости. Пользователям crates.io по-прежнему необходимо проявлять осторожность при выборе своих зависимостей, поскольку удаленное выполнение кода разрешено по замыслу и там.
CVE-2018-25008В стандартной библиотеке Rust до версии 1.29.0 существует слабая синхронизация в методе Arc::get_mut. Эта проблема синхронизации может привести к проблемам безопасности памяти из-за состояний гонки.
CVE-2017-20004В стандартной библиотеке Rust до версии 1.19.0 существует проблема синхронизации в объекте MutexGuard. MutexGuards можно использовать в разных потоках с любыми типами, что позволяет возникать проблемам безопасности памяти из-за состояний гонки.
CVE-2022-21658Rust — это многопарадигменный язык программирования общего назначения, разработанный для обеспечения производительности и безопасности, особенно безопасной параллельности. Рабочая группа Rust по реагированию на инциденты безопасности была уведомлена о том, что стандартная библиотечная функция `std::fs::remove_dir_all` уязвима для состояния гонки, позволяющего переходить по символическим ссылкам (CWE-363). Злоумышленник может использовать эту проблему безопасности, чтобы обманом заставить привилегированную программу удалить файлы и каталоги, к которым злоумышленник в противном случае не смог бы получить доступ или удалить их. Rust 1.0.0 — Rust 1.58.0 подвержены этой уязвимости, а 1.58.1 содержит исправление. Обратите внимание, что следующие цели сборки не имеют пригодных для использования API для надлежащего устранения атаки и, следовательно, остаются уязвимыми даже с исправленным набором инструментов: macOS до версии 10.10 (Yosemite) и REDOX. Мы рекомендуем всем как можно скорее обновиться до Rust 1.58.1, особенно людям, разрабатывающим программы, которые должны работать в привилегированном контексте (включая системные демоны и исполняемые файлы setuid), поскольку они подвергаются наибольшему риску пострадать от этого. Обратите внимание, что добавление проверок в ваш код перед вызовом remove_dir_all не смягчит уязвимость, поскольку они также будут уязвимы для состояний гонки, как и сама remove_dir_all. Существующее смягчение работает должным образом вне состояний гонки.
CVE-2021-28876В стандартной библиотеке Rust до версии 1.52.0 реализация Zip имеет проблему безопасности при панике. Она вызывает __iterator_get_unchecked() более одного раза для одного и того же индекса, когда базовый итератор паникует (при определенных условиях). Эта ошибка может привести к нарушению безопасности памяти из-за невыполненного требования безопасности для трейта TrustedRandomAccess.
CVE-2020-36317В стандартной библиотеке Rust до версии 1.49.0 функция String::retain() имеет проблему безопасности при панике. Это позволяет создавать строку Rust, отличную от UTF-8, когда предоставленное замыкание вызывает панику. Эта ошибка может привести к нарушению безопасности памяти, когда другие API-интерфейсы строк предполагают, что для той же строки используется кодировка UTF-8.
CVE-2019-16760Cargo до Rust 1.26.0 может загружать не ту зависимость, если ваш файл package.toml использует ключ конфигурации `package`. Использование ключа `package` для переименования зависимостей в `Cargo.toml` игнорируется в Rust 1.25.0 и более ранних версиях. Когда используется Rust 1.25.0 и более ранняя версия, Cargo может загружать не ту зависимость, которая может быть занята на crates.io как вредоносный пакет. Это влияет не только на манифесты, которые вы пишете локально, но и на манифесты, опубликованные на crates.io. Rust 1.0.0 - Rust 1.25.0 подвержены этой рекомендации, потому что Cargo будет игнорировать ключ `package` в манифестах. Rust 1.26.0 - Rust 1.30.0 не подвержены этому и обычно выдают ошибку, потому что ключ `package` нестабилен. Rust 1.31.0 и более поздние версии не подвержены этому, потому что Cargo понимает ключ `package`. Пользователям затронутых версий настоятельно рекомендуется обновить свой компилятор до последней доступной версии. Предотвращение этой проблемы требует обновления вашего компилятора до Rust 1.26.0 или новее. Не будет точечного выпуска для версий Rust, предшествующих 1.26.0. Пользователи Rust 1.19.0 - Rust 1.25.0 могут вместо этого применить связанные патчи для смягчения проблемы.
CVE-2018-1000622Rust Programming Language rustdoc версии между 0.8 и 1.27.0 содержит CWE-427: Uncontrolled Search Path Element vulnerability в rustdoc plugins, которая может привести к локальному выполнению кода от имени другого пользователя. Эта атака, по-видимому, может быть использована с помощью флага --plugin без флага --plugin-path. Эта уязвимость, по-видимому, была исправлена в версии 1.27.1.