PyPI въведе нова мярка за сигурност, която пречи на потребителите да качват нови файлове към версии на пакети, които са на повече от 14 дни. Тази промяна има за цел да спре атакуващите да добавят зловреден код към доверени версии на Python пакети, след като са компрометирали токен за публикуване на поддържащия пакета или работния процес по издаване на версии.
Официалният каталог с пакети на Python (PyPI) започна да отхвърля нови качвания за версии, по-стари от 14 дни. Това ограничение беше интегрирано в кодовата база на PyPI Warehouse на 8 юли 2022 г. и адресира риск в жизнения цикъл на доставките на софтуер, създаден от разрешаването на „отворени“ версии.
Преди това поддържащите пакетите можеха да публикуват допълнителни файлове към съществуваща версия по всяко време. Например, даден разработчик можеше да качи нов wheel файл за по-нова версия на Python, като същевременно запази същия номер на версията на пакета.
Въпреки че тази гъвкавост беше полезна за съвместимостта, тя също така предоставяше възможност за атаки. Ако атакуващ получеше достъп до PyPI API токен, компрометираше CI/CD пайплайн или злоупотребеше с работен процес за доверено публикуване, той можеше да качи зловреден код в стара версия, която разработчиците смятаха за безопасна.
Тъй като номерът на версията не се променяше, идентифицирането на компрометирания файл по време на рутинни актуализации на зависимостите беше много по-трудно. Новото правило ограничава този риск. След като дадена версия стане по-стара от 14 дни, PyPI вече няма да приема качвания на нови файлове за нея.
От PyPI посочиха, че не са запознати с атакуващи, които да са експлоатирали тази конкретна уязвимост в миналото. Въпреки това от платформата отбелязаха, че не са съществували технически контроли за предотвратяване на подобни сценарии, освен предположението, че киберпрестъпниците може да не разпознаят тази възможност.
Проблемът придоби популярност след компрометирането на популярните Python пакети LiteLLM и Telnyx през 2022 г. Тези инциденти подчертаха как доверените автоматизирани среди за издаване на софтуер могат да бъдат входни точки за атаки по веригата за доставки.
С новите ограничения в сила, компрометиран акаунт на разработчик вече не може тихомълком да добави зловреден код към отдавна утвърдена версия. Разработчиците, които трябва да публикуват поддръжка за нова версия на Python, обикновено ще трябва да създадат и издадат нова версия на пакета.
Тази промяна също така опростява реагирането на инциденти както за администраторите на PyPI, така че и за потребителите на пакети. При предишния модел една версия на пакет можеше да съдържа както легитимни, така и злонамерени файлове в зависимост от това кога е бил качен всеки файл, оставяйки потребителите несигурни относно безопасността на конкретна версия.
Преди да приложи това правило, PyPI прегледа историческите модели на публикуване, за да разбере потенциалното му въздействие. Този анализ включваше проекти, които са добавили файлове, след като дадена версия вече е била публикувана.
Прегледът на съвместимите с Python 3.10 wheel файлове в първите 15 000 пакета установи, че само 56 проекта са качили съвместим wheel файл повече от 14 дни след първоначалното публикуване, което предполага, че изискването за нова версия на пакета ще има минимално въздействие върху повечето разработчици.
Предложението беше обсъдено и на Срещата за пакетиране по време на PyCon US 2022, където участниците постигнаха общ консенсус, че ще бъде приемливо проектите да увеличават номера на версията си, когато добавят поддръжка за нови версии на Python.
От PyPI предупредиха потребителите все още да не разчитат на това поведение като на формална гаранция за състоянието на дадена версия. Понастоящем няма публикувана API семантика, която да потвърждава дали дадена версия е отворена или затворена за качване.
Очаква се такива дефиниции да се появят чрез предложената спецификация Upload 2.0 API и предварителните етапи, описани в PEP 694. Дотогава 14-дневният лимит служи като практическа предпазна мярка за сигурност срещу фин, но значителен риск от отравяне на пакети.