LINUX.ORG.RU

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

 , , ,


0

5

Атака на цепочку поставок: вредоносный код в 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)
Ответ на: комментарий от sena

максимально совместимый безопасный си и с++.

Раст, что ли? безопасность и совместимость - взаимоисключающие требования, не будет такого никогда.

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

Раст, что ли? безопасность и совместимость - взаимоисключающие требования, не будет такого никогда.

Это почему же? Пусть 100% совместимости в безопасном режиме конечно не будет, но если, условно 95% кода будет работать, то и отлично. 5% постепенно переписать реально. А пока оно будет в небезопасном режиме.

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

Почему же? Это может быть расширение языка. Тогда и старый код будет работать, и новый можно делать безопасным.

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

Это ещё почему? Сегодня и нейросетями переписывают. Были бы задача и оператор ИИ. Так что, проблем нет.

На нейросети одна надежда. :) Но, как я уже говорил, тогда и язык для нас кожаных не так уж важен, это уже нейросети там как-то между собой договорятся и нам сообщат. :)

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

Не будет. Вот просто не будет.

Разве что комитет это по какой-то причине намеренно не сделает. Что я тоже не исключаю, судя по его решениям.

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

Язык важен как для ревьюверов, так и для присылающих патчи. А в живой проект обычно приходят патчи и от живых людей. Да и мало ли что захочется переделать для самого себя, а именно для этой задачи в своё время Ричард Столлман и придумал GNU GPL.

Потому, кстати, и будут переписывать, что теперь большинство людей будут знать Rust, но не C/C++.

При этом никто не говорит, что нельзя будет писать на C/C++. Но они постепенно уходят в ту же нишу, что и Fortran с Паскалем. А на Фортране и Паскале и сегодня тоже пишут, да.

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

А велика ли разница переписываний на безопасный цепепе или на безопасный раст? Закопать цепепе — не использовать для новых проектов или даже новых модулей проектов существуюущих.

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

старый код будет работать, и новый можно делать безопасным.

Новый код: #include <staryi_kod.h>

А теперь обеспечь совместимость и безопасность.

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

Новый код: #include <staryi_kod.h>

#include <proklyatiy_stariy_kod.h>

Простите.

Так об чём грусть? Никто не говорит, что старых код должен быть безопасным. Он такой, какой есть. Собственно, подружить новый и старый код - задача программиста.

А новый пиши уже по-человечески.

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

Как у тебя 95% кода цепепе начнёт безопасно работать после каких-нибудь решений комитета? После решений комитета у тебя либо НЕ будет работать 95% кода, либо, если повезёт, будет работать как раньше.

Если тебе СЕЙЧАС надо, чтобы твой цепепе был «мемори сейф» — то всё уже готово: Fil-C 0.682 — memory safety без переписывания

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

Старый код от этого безопаснее как станет?

Правильно я понял предложение @sena, что надо ждать копрокорпофилов из комитетов чтобы они стандарт цепепе ещё чуточку усложнили и вот тогда заживём?

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

БЯМ не ставит цели, БЯМ выдаёт некоторые возможные сочетания слов из наиболее вероятных для учебной выборки. «Договорятся», «сообщат» — это ты приписываешь им намерения. Не надо так делать, это уровень Антропик и ОпенАИ: «БЯМ ВРВАЛАС И САМА ВЗЛАМАЛА ЧУЖОЙ ПРОЕКТ, НО МЫ ЕЁ В ТУРМУ НЕ ПОСАДИМ, ХАХА, ВЫ ЧТО, ОНА ЖЕ ХОРОШАЯ ПРОСТО ЗАПУКАЛАСЬ БЕДНАЯ СЛАДКАЯ, БЕГИТЕ ЧЕРТИ ВАМ ХАНА»

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

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

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

Мне лично без разницы, можно и похоронить. Но если создатели/держатели хотят, чтобы их язык жил, надо в него вносить изменения подобного рода.

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

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

И как есть компилируется. А значит, что в новом коде можно легко накосячить точно так же, как в старом, просто использовав что-нибудь старое, возможно даже по ошибке. Добавление новых конструкций в язык без избавления от старых не делает для надёжности программ практически ничего. Тем более если понадобится ещё и слой-прокладка между старым и новым. цпп 2.0 никому не нужен.

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

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

Именно так.

Я вижу всего два варианта: 1. закопать цпп, 2. Дать возможность писать безопасно. Чтобы неофиты писали новый код по новому, бить их палками по рукам.

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

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

БЯМ не ставит цели…

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

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

похоронить цепепе

сначала стоило бы похоронить си

yatazet
() автор топика
Ответ на: комментарий от BruteForce

Как у тебя 95% кода цепепе начнёт безопасно работать после каких-нибудь решений комитета? После решений комитета у тебя либо НЕ будет работать 95% кода, либо, если повезёт, будет работать как раньше.

Очень просто. Если я вызывал функцию double sin(double), почему она будет как-то иначе выглядеть в безопасном c++? Если у меня был код

std::list<std::string> sl;
sl.push_back("pruvet");

Почему он перестанет работать после решений комитета?

Да, где-то будут проблемы, но много чего заработает с минимальными переделками и можно будет сразу повесить плашку «safe 100%» на радость корпам.

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

Язык важен как для ревьюверов, так и для присылающих патчи.

Пока да, пока ещё да. Впрочем ревьювить и патчить нейронки тоже умеют.

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

в расте же тоже можно вызывать внешние опасные библиотеки?

Во-первых, вот оно, ключевое слово: в расте же можно. Расту уже не первый десяток лет, в нём уже можно. Нахрен цпп 2.0?

Во-вторых, очень много цпп - это темплейты. Как в старый небезопасный темплейт будет подставляться новый безопасный код? Получится же смесь старого и нового. Если она не компилится, то подход не работает, потому что нет совместимости. Если компилится, то подход не работает, потому что нет безопасности. Всё.

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

Дать возможность писать безопасно.

Что значит дать возможность писать безопасно? Надо отбирать возможность писать небезопасно. Писать как угодно можно и сейчас, хоть на асме. Проблемы возникают, когда человеческого внимания не хватает, и возникает ошибка в коде. Асм съест практически что угодно, Си очень многое, какой-нибудь идрис заставит тебя доказывать все заявленные свойства кода.

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

Во-первых, вот оно, ключевое слово: в расте же можно. Расту уже не первый десяток лет, в нём уже можно. Нахрен цпп 2.0?

А, ну то есть можно и раст не развалился, а в с++ нельзя? Ой. У вас ус отклеился. ;)

Зачем цпп 2.0 понятно, чтобы сэкономить деньги и ресурсы. Проще подправить компилятор и стандарты, чем переписывать (или тем более выкидывать) миллиарды строк годного кода. Правда раст становится не нужен. Я тебя понимаю.

Во-вторых, очень много цпп - это темплейты. Как в старый небезопасный темплейт будет подставляться новый безопасный код? Получится же смесь старого и нового. Если она не компилится, то подход не работает, потому что нет совместимости. Если компилится, то подход не работает, потому что нет безопасности. Всё.

Так элементарно вроде бы. Если темплейт старый и небезопасный, то он будет компилироваться только внутри unsafe блока. В чём ты видишь проблему? Ты не сможешь использовать старый небезопасный template в безопасном блоке. Если же темплейт безопасен, то ты сможешь его использовать и в безопасном блоке, а если он совместим, то и в небезопасном тоже. Может я чего-то не понимаю, вроде несложно выходит.

В расте же всё это есть, можно даже сишные библиотеки вызывать. Вообще проблемы нет никакой.

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

Всё что я понял из слов @unC0Rr, это что расту можно исполнять небезопасный код в unsafe блоке и даже сишные библиотеки вызывать, а изменить точно также c++ запрещено свыше. Потому что… что? Не, просто запрещено и всё.

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

Не запрещено, а никому это не нужно. Вызывать из unsafe можно уже прямо сейчас из раста. Новый цпп не совместимый со старым не нужен.

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

Я понял, тебе не нужен. Ну значит тебя вычёркиваем. :)

Если спрос на безопасность есть (а он вроде есть), то он нужен всем, у кого много с++ кода. Например он может понадобиться мне, если вдруг в тендерах все потенциальные покупатели начнут указывать требование «язык с гарантиями безопасности».

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

Если спрос на безопасность есть (а он вроде есть), то он нужен всем, у кого много с++ кода

Ну так раст уже есть, зачем ждать стандарт c++52?

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

Ну так раст уже есть, зачем ждать стандарт c++52?

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

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.