Hacker News Digest

Эксплойт Relapse-Exploit позволяет выполнить произвольный код на консолях PlayStation 5 с прошивками от 7.00 до 13.60 включительно. Для использования достаточно изменить Primary DNS в настройках сети на 45.56.67.85 и открыть веб-страницу эксплойта через браузер PS5 либо запустить локальный сервер с serve.py. После успешной эксплуатации загружаемый ELF-пайлоад становится доступным через порт 9021, а исходные бинарники сохраняются в директории payloads/.

Эксплойт состоит из двух этапов: браузерный использует утечки информации в JSC и несоответствие в пуле объектов structured clone для повреждения typed array, что приводит к выполнению кода в рендерере; ядерный этап сочетает утечку адреса с гонкой условий типа use-after-free в aio_multi_wait для достижения чтения и записи в ядре. Из-за возможной нестабильности Webkit может потребоваться несколько попыток перезагрузки страницы, а ядерный эксплойт иногда приводит к панике системы — в таких случаях рекомендуется перезагрузить консоль перед повторной попыткой. Проект создан для образовательных и исследовательских целей, его использование на чужих устройствах или для обхода защиты запрещено. Среди авторов: ntfargo, ufm42, Sonic_Iso, Jordy, Dr. Yenyen, TheFlow и другие.

Эксплойт позволяет выполнить произвольный код на PS5, но полноценный Linux пока невозможен без доступа к гипервизору. Уязвимость исправлена в прошивке 14.0, поэтому новые консоли защищены. Эксплойт работает на уровне ядра, но запуск Linux требует гипервизорного доступа, которого пока нет. Sony продаёт консоли в убыток и зарабатывает на играх, поэтому не заинтересована в открытии системы для пользовательского ПО. Уязвимость, вероятно, связана с JavaScriptCore в WebKit; Sony может отключить JIT в прошивке 14.0, чтобы снизить риск атак. Обсуждаются применения: медиа‐ПК, запуск Steam‐игр через проекты типа AnyPS5, но есть ограничения по контроллеру и стоимости. Память и хранилище ограничены 128 ГБ, что делает консоль неудобной для современных игр объёмом 50‐100 ГБ. Для использования рекомендуется запускать ELF‐payload через порт 9021 с локальным сервером serve.py, как в оригинальном гиде. Некоторые считают, что Linux на PS5 станет возможным благодаря усилиям сообщества и аналогам вроде Apple Game Porting Toolkit. Есть споры о конкуренции с Apple TV: один считает его способным запускать 4K‐игры, другой указывает на малый объём хранилища и отсутствие контроллеров. Для экспериментов советуют изучить проект ProsperoEden — порт Switch‐эмулятора на PS5, позволяющий запускать некоторые игры без полного доступа к системе.

Andy ‘TheFlow0’ Nguyen, ключевой разработчик проекта PS5 Linux, покинул сцену из-за массового проникновения в открытые проекты «vibe-coders» — людей, которые используют LLM для генерации кода, не понимая его сути. Он описал современную разработку как «толпу новичков, пишущих хаки, которые не понимают», в отличие от прошлых времён, когда проекты вели талантливые исследователи. Особую боль вызвало то, что такие пользователи обнаружили последний оставшийся гипервизорный баг, который позволял запускать Linux на PS5, и сообщили его Sony в обмен на вознаграждение — вопреки ожиданиям сообщества дождаться выхода GTA 6.

Проект PS5 Linux, обеспечивавший полноценную замену системной оболочки консоли и возможность dual-boot с Linux, теперь застрял на версии 2.5, поддерживающей прошивки 3.00–7.61. Утрата этого бага означает, что обновления для новых версий PS5 становятся невозможными без новых уязвимостей. Nguyen, известный своими эксплоитами для PlayStation Vita и PS3, назвал это «концом эпохи» — когда глубокая техническая работа вытесняется поверхностным использованием ИИ, а сообщество превращается в «сборище слепых копировщиков».

Основная причина ухода разработчика — нарушение соглашения о соглашении о конфиденциальности: эксплойт был сообщён Sony для получения баг-бонуса, что подорвало доверие и поставило под угрозу проект PS5 Linux. Массовое использование LLM для генерации кода без понимания разрушает культурный опыт открытых проектов, где ценилось глубокое понимание систем и взаимодействие с компетентными людьми. Проблема не в LLM как инструменте, а в том, что новички используют их как замену обучению, что приводит к росту спам-пул-реквестов и снижению качества вклада в FOSS. Для сохранения качества некоторые сообщества создают закрытые приглашённые пространства, где эксперты используют LLM осознанно, опираясь на опыт, а не как на источник истины. Один участник внедрил требование: все PR должны быть вручную протестированы и подписаны человеком — это сократило спам от LLM и ускорило работу ядра команды. Спор: некоторые считают, что разработчик просто сгорел и винит LLM, чтобы избежать признания, что проект PS5 Linux был обречён из-за политики Sony и отсутствия спроса, а не из-за 'slop kiddies'. Другой участник утверждает, что 'slop kiddies' не виноваты — они использовали доступные инструменты, а вина лежит на системе, которая поощряет баг-бонусы, а не коллективную ответственность. Сравнение с пиццей: если раньше тестирование теста занимало день и требовало мастерства, сейчас всё делается за 10 секунд — идеально, но без глубины, и это убивает смысл процесса для истинных энтузиастов. Проблема не ограничивается хакерскими проектами — она наблюдается во всех когнитивных профессиях, где LLM заменяет обучение и критическое мышление, а не дополняет их. История с эксплойтом показывает, что даже если LLM помог найти уязвимость, проблема — в этике сообщества: ожидание моральной ответственности против индивидуальной выгоды. Многие разработчики, не говоря вслух, испытывают схожее разочарование: публичные репозитории превратились в мусорные кучи, где даже опытные люди перестали отвечать из-за токсичности и низкого качества вклада. Предлагается создавать отдельные 'форки для новичков', где можно экспериментировать без риска для основного проекта — это снизит давление на поддержку и сохранит качество ядра. Использование LLM не проблема — проблема в том, что люди перестали учиться: если эксперт использует LLM как помощника, результат отличается от того, когда новичок принимает его ответ как истину без проверки.

Слух о баге в OCaml-библиотеке cohttp привёл к тому, что атаки начались ещё до публикации исправления. Автор обнаружил в логах своего веб-сервера попытки эксплуатации уязвимости path traversal всего через несколько минут после открытия публичного pull request с патчем. Используя собственный ИИ-агент (DeepSeek V4 Pro), он смог воспроизвести эксплойт локально за минуту, основываясь лишь на общем описании проблемы — что демонстрирует, насколько быстро современные агентные системы могут находить уязвимости по косвенным намёкам.

Традиционный процесс закрытого исправления и embargo перестал работать: агенты, получив лишь общее направление (например, описание CVE), способны самостоятельно исследовать код и создавать эксплойты. Исследования показывают, что GPT-4-агент эксплуатирует 87% уязвимостей по их описанию, а среднее время до эксплуатации теперь отрицательное — атаки начинаются до выхода патча. Это требует пересмотра практик безопасности в open source: нужны быстрые механизмы триажи, верификации и доверия, а также защитные системы, способные противостоять автоматизированным атакам в реальном времени.

Тред подтверждает: волна фейковых и низкокачественных security-репортов стала повседневностью для open source, а LLM сократили цикл от слуха до эксплойта и массового сканирования до минут. Главный враг — не техника, а отсутствие воли фиксить баги и медленный релиз патчей против рисков supply-chain автообновлений. По опыту @nickcw (rclone): за 10 лет — ~20 репортов, за последний месяц — >40, ~75% содержат зерно проблемы, конфигурации для воспроизведения становятся экзотичнее. @thedonncha наблюдает волнообразное накопление: после исчерпания одного проекта атаки переключаются на следующий, качество падает, нагрузка — нет. @bri3d и @happyopossum: использование PoC из обрывков кода — не ново, но LLM демократизировали его, сжав цикл (чтение коммита → RE → сборка → сканирование) с дней/недель до минут/часов. @loeg и @avsm: memory-safe языки (включая OCaml) не спасают — LLM находят логические баги и corner-кейсы в C-биндингах, как в Mirage-crypto. @loeg утверждает, что такие языки снижают число эксплуатируемых багов, но @avsm и @aseipp настаивают: ключевая проблема — масштабируемость и скорость атак: от слуха до эксплойта теперь часы, и это легко масштабируется деньгами и compute. @stephbook и @talon8635: реальный bottleneck — rollout/deployment. Обновление стека за 10 минут — редкость, CI верифицирует бизнес-логику дольше, автообновления сами становятся вектором supply-chain атаки. Выбор между известной уязвимостью и слепым доверием к апдейтам — ловушка. @Saghm и @xbar обсуждают, может ли LLM «найти» эксплойт по ложному слуху; @petesergeant приводит пример sgnt.ai/p/terrible-mistake: агент генерирует критичный баг по ложной подсказке — false positives становятся индуктивным инструментом. Советы: @nickcw — держать security-фиксы в отдельных ветках, мёржить только в релиз-день, мириться с конфликтами. @rndhouse — построил инструмент для детекции «тихих» багфиксов через GPT-5.5-класс модели; обфускация изменений для обхода — ненадёжна, c-lightning временно раздавал закрытый бинарь. @ChrisMarshallNY и @skybrian: мейнтейнеры могут уйти в приватные репозитории ради сокращения окна эксплуатации — хотя публичность ранее игнорировалась с тезисом «LoL MaRkEtInG». @godelski и @dingdongditchme: менеджмент давит на скорость и отказывается чинить баги, которые Claude уже верифицировал в open PR; без воли — качество ПО не растёт, LLM только ускоряют и хорошее, и плохое. @janpeuker: когда средние и высокие баги станут дёшевы для фикса, lowkey-хакинг и privacy-аудиты станут prohibitively expensive для обычных граждан — баланс сил сместится. Остальные не оспаривают напрямую, но тон треда — про удешевление эксплойтов, а не защиты.

Уязвимость GhostLock (CVE‑2026‑43499) позволяет любому локальному пользователю без привилегий получить контроль над ядром Linux, который живёт в каждом из основных дистрибутивов более 15 лет. По данным исследователей, эксплуатация стабильна в 97 % случаев и уже привела к выплате $92 337 в рамках kernelCTF. Уязвимость появилась в версии 2.6.39 при упрощении PI‑алгоритма rtmutex и оставалась непатченной до версии 7.1; её активация требует лишь включения CONFIG_FUTEX_PI, без необходимости привилегий или специальных настроек. Через простую последовательность системных вызовов можно вытащить указатель на стек ядра, записать его в произвольный адрес и захватить таблицу функций, что в итоге даёт полное повышение прав и побег из контейнеров.

Техническая основа – ошибка в функции remove_waiter() в kernel/locking/rtmutex.c, где при ошибке прокси‑переадресации стека задачи очищается не тот указатель. Это приводит к использованию после освобождения (UAF) стека, который можно инициировать через системный вызов FUTEX_WAIT_REQUEUE_PI. В результате получаем dangling‑pointer к стеку, возможность записать произвольный адрес и перехватить управление, что в конечном итоге приводит к повышению до root. Эта уязвимость позволяет получить контроль над ядром без специальных прав, что делает её критически важной для всех дистрибутивов.

• Обсуждается уязвимость, позволяющая получить root через JavaScript в Firefox на Android, используя Chromium‑based браузер без JS.
• Уязвимость связана с устаревшими функциями ядра (GhostLock) и может привести к привилегированному доступу к системным ресурсам.
• Участники делятся мнениями о влиянии уязвимости на безопасность Android, необходимости обновлений и роли OpenBSD, SELinux и виртуализации.
• Есть споры о том, насколько такие эксплойты делают инфосекурность менее надёжной и требуют ли новых подходов к защите.