LINUX.ORG.RU

Атака на пакет arrayref Rust

 , , ,


0

3

Атака на цепочку поставок: вредоносный код в crates.io через пакет arrayref

20 августа 2026 года Команда безопасности Rust (Rust Security Response Team) сообщила об обнаружении вредоносных пакетов в реестре crates.io, связанных с популярной библиотекой arrayref.

Что произошло

20 августа 2026 года в 7:15 UTC команда получила сообщение о том, что пакет proc-macro1 является вредоносным. После проверки выяснилось, что его build-скрипт загружал вредоносное ПО.

Пакет proc-macro1, а также связанные с ним proc-macro-en, aovine, arone, aronenao и tinymember были удалены из реестра.

Дальнейшее расследование показало, что широко используемый пакет arrayref был недавно перевыпущен с добавленной зависимостью от вредоносного proc-macro1, при этом последние версии были помечены как yanked. Команда удалила вредоносную версию и восстановила ранее ошибочно отозванные версии.

Аналогичным образом пострадали другие пакеты того же автора — internment и append-only-vec. По ним были приняты те же меры. Аккаунт автора заблокирован в качестве меры предосторожности. По имеющимся данным, сам автор arrayref не действовал злонамеренно — вероятнее всего, были скомпрометированы его компьютер или учётные данные. Команда пытается связаться с ним.

Что нужно сделать пользователям

Рекомендуется проверить локальные зависимости на предмет использования следующих вредоносных версий, удалённых с crates.io:

  • append-only-vec@0.1.9
  • arrayref@0.3.10
  • internment@0.8.7
  • proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (любые версии)

Проверить наличие этих пакетов в локальном кэше можно следующей командой:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Благодарности

Команда Rust поблагодарила исследователей Nextron Systems GmbH за первоначальное обнаружение проблемы и сообщение о ней, а также сотрудников, участвовавших в устранении инцидента.

>>> Источник



Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от doomer

Плюсы были ещё когда библиотеки на дискетах передавали, то что у них такого нет, говорит о том, что оно просто древнее, не говорю плохое, просто древнее

unclestephen ★★★★★
()
Ответ на: комментарий от Lrrr

де факто замкнули все зависимости на единый централизованный репозиторий crates.io

Тут надо серьёзно считать риски в конкретной организации. С бухты-барахты сложно делать обобщения.

В конторах, где пилят громоздкий софт со множеством подрядчиков всё равно используются свои собственные сервера с пакетами. Что для Питона, что для Раста. К тому же, в таких сложных проектах просто невозможно всё время сидеть на апстримных latest and greatest версиях пакетов. Плюс, есть специальные чувачки, которы только и делают, что сидят с радарами, и мониторят все происшествия безопасности, выясняют, какие версии чего кто использует в конторе и т.д. Т.о., если просуммировать все эти факторы разработки (организационно) сложного ПО, подобные взломы им даже не видны, потому что большая инертность обновлений (только что-то очень серьёзное, что может привести к человеческим травмам/смертям, массовым отключениям и систем по всему миру) в свою очередь приводит к тому, что из 10 подобных инцидентов за весь жизненный цикл ПО (ну, скажем, 15 лет) до потребителей доходит от силы один.

Ах да, кража ключей SSH у разраба - это как бы проблемы разраба. Ну, т.е., если репа хостится системой, которая позволяет пуши в стабильную ветку и/или слияние из других веток без ревью, то процесс разработки либо неадекватно выстроен, либо эта репа - мало кому нужный проект.

Удачно вам кодить на этом говне.

не кодим, но и не осуждаем

seiken ★★★★★
()

Оказывается возможные проблемы с памятью, которые раст пытается избежать любой ценой, составляют лишь небольшую часть возможных проблем с безопасностью.

Так стоит ли овчинка выделки?

sena ★★★
()
Ответ на: комментарий от sena

Так стоит ли овчинка выделки?

Нет, конечно же. Если есть проблемы с пакетным менеджером, то все остальные проблемы решать не нужно. Горит сарай, гори и хата.

yvv1 ★★
()

А я давно говорю, что все зависимости это зло. Зависеть можно только от ядра линукса. Всё остальное нужно писать самому.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от byko3y

Сколько раз говорить, что простота загрузки кала из интернета

Сначала подумал что речь про скачку mp3 с репом и уже хотел пожаловаться на офтопик.

perl5_guy ★★★★★
()
Последнее исправление: perl5_guy (всего исправлений: 1)
Ответ на: комментарий от liksys

…проблема не в расте как таковом, а в пакетной системе NPM-like…

Скорее просто привлекательность и эффективность такого рода атак стали выше по мере становления текущих подходов к разработке ПО. Тут не столько пакетный менеджер играет роль, хоть ручками делай, проблема не уйдет. Просто сейчас 1 либа (если смотреть на всю цепочку зависимостей) на 10 строк в проекте - вполне себе обычное дело.

altwazar ★★★★★
()
Ответ на: комментарий от liksys

В новости нет самого главного, что есть по ссылке. Вредоносные пакеты лежали в репе где-то полтора часа, а не были вредоносными прям долгое время. Проблему это не уменьшает, но если вы не собирали ничего на расте в последнее время - всё будет в порядке.

Дополнительно добавлю, что проблема не в расте как таковом, а в пакетной системе NPM-like, ее невозможно сделать правильно, все языки с интернет-репами этим страдают. Хотя растовикам в принципе ее делать в таком виде не стоило.

Ну конкретно эту проблему решить просто. Если выкладываешь релиз популярного пакета, он становится доступным всем по умолчанию через 24 часа, например. А в течение этих 24 часов он доступен только тем, кто каким-то образом специально его запросит. Т.е. цель - дать время для автоматических сканеров или «тысячи глаз» обнаружить вредоноса до того, как он дойдёт до публики. Конечно это не решит всех проблем, но раз тут через полтора часа убрали, скорей всего сработал именно какой-то автоматический сканер.

vbr ★★★★★
()
Ответ на: комментарий от LightDiver

Почему ось? Не понял логики. Ядро переписывать я не советую.

Хотя у линукса архитектура некоторых компонентов максимально отвратительная. Например если хочешь пользоваться графическим ускорением, я так понял, адекватного способа линковаться без glibc нет. Поэтому для каких-то приложений придётся линковаться с glibc.

vbr ★★★★★
()
Ответ на: комментарий от gns

Впервые слышу. :)

Просто говорит о том что ты не интересуешься развитием экосистемы вокруг плюсов за последние лет 10

Gary ★★★★★
()
Ответ на: комментарий от Gary

А зачем? Мне пакетного менеджера операционной системы хватает. А в ядре и этого не надо;

gns ★★★★★
()
Ответ на: комментарий от Gary

Просто говорит о том что ты не интересуешься развитием экосистемы вокруг плюсов за последние лет 10

Про conan не скажу, но vcpkg пару раз подставлял с AGPL.

sarumeister
()
Ответ на: комментарий от doomer

Такое было было с XZ Utils, что кагбе было несколько более опасно, чем данный случай.

Проблема не в языке, а в инфраструктуре. Открытость и доступность имеет и свои подводные камни.

WatchCat ★★★★★
()
Ответ на: комментарий от LightDiver

любой ценой

Не любой

Ты имеешь в виду unsafe блоки? Но они же не для ежедневного использования, а только для исключительных случаев. Использовать их просто для упрощения кода не совсем правильно.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 2)
Ответ на: комментарий от yvv1

Если есть проблемы с пакетным менеджером, то все остальные проблемы решать не нужно. Горит сарай, гори и хата.

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

sena ★★★
()
Последнее исправление: sena (всего исправлений: 2)
Ответ на: комментарий от kto_tama

Компрометация пакетов это не проблема языка, а проблема инфраструктуры, но тут ничего не поделаешь, кроме регулярного мониторинга. Пример с XZ Utils тому показатель.

WatchCat ★★★★★
()
Ответ на: комментарий от sena

казывается возможные проблемы с памятью, которые раст пытается избежать любой ценой, составляют лишь небольшую часть возможных проблем с безопасностью.

Так стоит ли овчинка выделки?

Стоит хотя бы тем, что Ржавый как язык поудобнее и поприятнее убогой сишечки и набора костылей и подпорок называемым C++.

WatchCat ★★★★★
()
Ответ на: комментарий от sena

Сгорел сарай, гори и хата.

Так решают проблемы психи. Нет хаты - нет проблем, думают они.

Нормальные люди обычно подходят к решению проблем систематически, по мере их поступления.

yvv1 ★★
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от WatchCat

Ржавый как язык поудобнее и поприятнее убогой сишечки и набора костылей и подпорок называемым C++.

Я на расте не писал, но то что я читал о нём, говорит как раз о заметно большей сложности. И это если забыть о том, что большинство кода уже написано на с/c++

sena ★★★
()
Ответ на: комментарий от unclestephen

Поживём — увидим.

Я же ориентируюсь на классику, сейчас изучаю эти ваши «кресты».

sparkie ★★★★★
()
Ответ на: комментарий от Reset

Все эти пакетные менеджеры в языках - одна огромная дыра в безопасности

А пакетные менеджеры в линуксах как? Уже другая дыра?

yvv1 ★★
()
Ответ на: комментарий от dynamic_cast

вместо удобных исключений?

Исключения удобны если пишешь на уровне прототипа. Чуть что серьезнее, так в гайдлайнах тут же бан на исключения.

sarumeister
()
Ответ на: комментарий от Reset

Большинство программ на с++ и на с имеют множество зависимостей. Было бы весьма неплохо иметь стандартный и удобный способ работы с ними. Так что отсутствие стандартного пакетного менеджера (и соответственно отсутствие в нём дыр в безопасности) это едва ли плюс с/с++. Скорее это минус. Не критичный, потому что есть способы решать эту проблему, но минус.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от Bad_ptr

От педеRUSTа не переворачиваются, да. Наверное потому что его в самолётах нету?

verh010m
()

Я тут зашел на rustsec и вообще страшно стало. Но наверное если бы сделали аналог для npm все вообще бы красным горело

anonymous_sama ★★★★★
()
Ответ на: комментарий от dynamic_cast

удобных исключений

Довольно спорное утверждение, у нас на работе например исключения в своём коде вообще запрещены, потому что в большой кодовой базе становится сложно их все отследить, и код получается crash-prone.

В свою очередь когда ошибки становятся частью возвращаемого типа, их просто невозможно пропустить на этапе написания кода. В плюсах кстати тоже это поняли т.к. завезли expected.

Gary ★★★★★
()

Безопасный язык такой безопасный.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от Gary

В свою очередь когда ошибки становятся частью возвращаемого типа, их просто невозможно пропустить на этапе написания кода.

Ага, особенно если это возвращаемое значение «послать» в /dev/null..

dynamic_cast
()

Microsoft Windows Defender хорошо лечит подобную заразу, если к винде подключить Linux раздел на запись ;)

efoxxi
()
Ответ на: комментарий от dynamic_cast

Послать просто так не получится, ведь тип-суммы типа expected хранят ИЛИ возвращаемое значение, ИЛИ ошибку. Т.е. если ты получил ошибку, то дальше работать по успешному пути не получится, нужно обработать ошибку.

Я понимаю, что можно написать такой код, который всегда будет обращаться к значению, даже если была возвращена ошибка, и что приведет к исключению/панике/нужное подчеркнуть. Ну ок, а можно ещё вилкой в розетке ковыряться, дальше-то что?

Gary ★★★★★
()
Ответ на: комментарий от Gary

Ну ок, а можно ещё вилкой в розетке ковыряться, дальше-то что?

Буквально это говорят все эти сишники и вышиватели крестиком…

BruteForce ★★★★
()

ожидаемо, предсказуемо

rsync ★★★
()

proc-macro1

А про proc-macro2 ничего нет? А то оно в mesa иcпользуется...

superuser ★★★★☆
()
Ответ на: комментарий от doomer

что за... не подсказывайте, а то потеряем еще и плюсы

sunjob ★★★★★
()
Ответ на: комментарий от vbr

дать время для автоматических сканеров или «тысячи глаз» обнаружить

тыщи глаз годами ни чего на замечают, да и не имеют такой привычки (бла бла бла).
а вот если спецом натравить ии на эти пакеты в «карантине» - это другое дело!
однозначно, с онлайн-пакетной системой что-то надо делать, даже, возможно, пересматривать идеологию, механизмы итд, а то «это» только цветочки.

sunjob ★★★★★
()
Ответ на: комментарий от vbr

что все зависимости это зло. Зависеть можно только от ядра линукса. Всё остальное нужно писать самому.

тогда теряется смысл самого слова «прогресс/наработки/база»...
и каждый раз начинать с начало? упс...
в таком случае, мы-бы до сих пор сидели на самопайных «персональных компьютерах» (каждый под свой нос)
имхо - нужен контроль над «кубиками», на базе которых мы создаем «последующие кубики», это однозначно!

sunjob ★★★★★
()
Ответ на: комментарий от sunjob

нужен контроль над «кубиками», на базе которых мы создаем «последующие кубики», это однозначно!

А потом понадобится контроль над контролями за «последующими кубиками» - это ж классика (та еще рекурсия)… Тут вообще, считаю, ржавая мертворожденная история - предать ее анафеме)))))

Sm0ke85
()
Ответ на: комментарий от Sm0ke85

но контроль-то, как таковой, нужен! иначе как по другому, коли появились «черви»?!
такая-же история может произойти практически с любым языком/системой.

п.с. давно, когда «все вокруг» писали/гордились что «линукс без вирусов и их там нет»... я просто горько молчал и опускал глаза, прекрасно понимая, что это все до поры до времени...

sunjob ★★★★★
()
Последнее исправление: sunjob (всего исправлений: 1)
Ответ на: комментарий от sunjob

но контроль-то, как таковой, нужен!

Да я так, просто выразил «фи» расту, уж больно он мне «не нравится» по политическим скорее причинам))))

Sm0ke85
()
Ответ на: комментарий от sunjob

вся надежда на антивирусы на базе ИИ которые будут всё проверять (ну разумеется что должны быть люди которые будут за этим следить и откликаться на обратную связь)

Bad_ptr ★★★★★
()
Ответ на: комментарий от Gary

Ну ок, а можно ещё вилкой в розетке ковыряться, дальше-то что?

Этой же логикой можно все UB оправдать. За что боролись, на то и напоролись..

dynamic_cast
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.