Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Разработчики мессенджера Signal решили наконец повысить безопасность версии приложения для десктопов. В частности, девелоперы поменяли способ хранения ключей шифрования, за что их критиковали с 2018 года.

Ранее при установке Signal на Windows- или macOS-устройства мессенджер создавал зашифрованную SQLite-базу для хранения сообщений пользователя. Эта БД шифровалась с помощью ключа, сгенерированного программой, без пользовательского ввода.

Чтобы программа могла расшифровывать базу и использовать её для хранения данных, нужен ключ шифрования. В случае с логикой работы Signal ключ хранился в виде простого текста в локальном файле по пути «%AppData%\Signal\config.json» в Windows и «~/Library/Application Support/Signal/config.json» — в macOS.

Источник: BleepingComputer

 

Проблема в том, что если Signal может получить доступ к этому файлу с ключом, любая программа в системе тоже способна до него добраться. Другими словами, шифрование БД лишено всякого смысла, ведь любой софт может её расшифровать.

Сначала Signal всячески пытался преуменьшать значение этого бага. Например, один из разработчиков писал:

«Ключ от БД и не задумывался как нечто закрытое. Шифрование при хранении никогда не упоминалось в качестве функциональности десктопной версии Signal».

Однако девелоперы, судя по всему, пересмотрели своё отношение после одного из твитов Илона Маска, в котором миллиардер указывал на уязвимость в мессенджере.

Своё недоумение также высказывали исследователи в области кибербезопасности — например, Томми Миск.

Теперь, по словам разработчиков, они имплементировали поддержку Electron safeStorage. Нововведение скоро должно появиться в бета-версии Signal.

Microsoft Defender заставил VLC думать над MP3 по 33 секунды

Некоторые пользователи Windows 11 столкнулись с необычной задержкой в VLC: плееру требуется до 33 секунд, чтобы начать воспроизведение обычного MP3-файла. Команда VideoLAN обвиняет в проблеме Microsoft Defender, который после одного из обновлений якобы начал отправлять в карантин кеш плагинов VLC.

Ситуация получила огласку после жалобы разработчика игр Джонатана Блоу. Из-за задержки он отказался от VLC в пользу Microsoft Media Player, а заодно раскритиковал состояние открытого ПО на Windows.

Разработчики VLC ответили, что сам плеер здесь ни при чём. По их версии, Defender блокирует или помещает в карантин файл plugins.dat. В нём хранится кеш модулей, отвечающих за кодеки, демультиплексоры и ввод-вывод.

Без кеша VLC при каждом запуске приходится заново сканировать каталог плагинов. Пока пользователь ждёт первые ноты песни, плеер проводит полную перекличку своих внутренних компонентов. Получается почти винил: музыку тоже нужно немного подождать, только атмосферы меньше.

Проблема возникает не на всех компьютерах. Журналисты Tom’s Hardware попытались воспроизвести её на Windows 11, но VLC запускал MP3 без заметной задержки. Microsoft ситуацию пока не комментировала, поэтому точный масштаб сбоя неизвестен.

Для исправления разработчики рекомендуют переустановить VLC или пересоздать кеш с помощью vlc-cache-gen.exe. В меню «Пуск» также доступен ярлык сброса настроек и кеша, но он удалит пользовательские параметры: эквалайзер, горячие клавиши и настройки субтитров.

Добавление каталога VLC в исключения Defender тоже может предотвратить повторную блокировку, однако такой способ снижает контроль антивируса над файлами в этой папке. Поэтому безопаснее сначала ограничиться восстановлением кеша.

Обычный MP3 в итоге оказался полем боя между плеером и защитой Windows. Пользователь, как всегда, выполняет роль секундомера и технической поддержки.

RSS: Новости на портале Anti-Malware.ru