Weaponizing NotebookLM - безобидный Intent может забить /data и уложить устройство Любое приложение без единого permission может заставить NotebookLM довести объём свободного места во внутреннем разделе /data до 0 байт. 🤡 И это не КЛИКБЕЙТНЫЙ АНОНС УЯЗВИМОСТИ и не SD-карта. Это data-partition. Итог - краши приложений, отказ SQLite, системная нестабильность. Подробнее тут. Коротко и ясно (если неясно, спрашивайте) - ниже 👇 👀 Что происходит Приложение принимает content:// URI и начинает считывать входной поток, автоматически копируя его во внутренний кэш-каталог. При этом отсутствует какая-либо предварительная валидация: не запрашивается OpenableColumns.SIZE, не проверяется фактический размер данных, не установлен жёсткий лимит на объём принимаемого контента и не осуществляется контроль доступного дискового пространства во время записи. 🚫В результате операция копирования выполняется без ограничений. Если источник отдаёт бесконечный или аномально большой поток, запись будет продолжаться до полного исчерпания свободного пространства раздела /data. Почему это серьёзно 🤔Пользователь получает системное уведомление «Storage full», однако при проверке через файловый менеджер не обнаруживает крупных файлов или очевидных причин переполнения. Проблема скрыта внутри приватного каталога приложения (/data/data/...), который недоступен без root-доступа. Фактически пользователь лишён возможности самостоятельно устранить последствия. Единственные варианты - удалить приложение (с потерей всех локальных данных) либо выполнить factory reset устройства. Речь идёт о целенаправленном использовании storage-привилегий одного приложения другим - по сути weaponization доверенной модели хранения данных. 🥃 Технический сценарий атаки 1. Атакующее приложение создаёт ContentProvider, отдающий infinite stream. 2. Отправляет ACTION_SEND intent в NotebookLM. 3. NotebookLM копирует поток в: /data/data/com.google.android.apps.labs.language.tailwind/cache/ 4. Data partition → 0 bytes free. 5. Система начинает падать. Важно: 😡 0 permissions 😡 sandbox не нарушается 😡 запись происходит самим NotebookLM (легально, получается) 👋 Вывод: Помнишь CIA? Так вот! Availability - не какой-то там второстепенный аспект. Если приложение принимает поток без лимита, оно может стать прокси для self-inflicted DoS. И да, такие кейсы уже были - чаще всего это zip-bomb при импорте, бесконечные ContentProvider-потоки или неограниченный кэш WebView/DownloadManager. Во всех случаях причина одна: приложение принимает внешний поток и тратит свои storage-привилегии без лимита. Паттерн простой: нет size-check + нет quota + нет byte-threshold как следствие self-inflicted DoS Все! 😎