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 копирует поток в:
4. Data partition → 0 bytes free.
5. Система начинает падать.
Важно:
😡 0 permissions
😡 sandbox не нарушается
😡 запись происходит самим NotebookLM (легально, получается)
👋 Вывод:
Помнишь CIA? Так вот!
Availability - не какой-то там второстепенный аспект. Если приложение принимает поток без лимита, оно может стать прокси для self-inflicted DoS.
И да, такие кейсы уже были - чаще всего это zip-bomb при импорте, бесконечные ContentProvider-потоки или неограниченный кэш WebView/DownloadManager.
Во всех случаях причина одна: приложение принимает внешний поток и тратит свои storage-привилегии без лимита.
Паттерн простой:
Все!
😎
Любое приложение без единого 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
Все!
😎