Oracle в апреле перестанет доверять JAR-файлам, подписанным с MD5

Oracle в апреле перестанет доверять JAR-файлам, подписанным с MD5

Oracle решила дать разработчикам Java больше времени, чтобы убедиться, что их JAR-файлы не подписаны с помощью алгоритма MD5. Java Runtime Environment (JRE) больше не будет доверять этим типам файлов, подписанных MD5 начиная с апреля 2017 года.

Компания в октябре объявила о том, что планирует прекратить доверять JAR-файлам, подписанным с использованием алгоритма MD5, в котором, как известно, некоторые уязвимости (например, к коллизионной атаке) существуют  на протяжении более десяти лет.

Начиная с версии Java SE 8u131, которую компания планирует выпустить в апреле, JAR-файлы, подписанные с использованием MD5 будут рассматриваться как неподписанные. Изначально Oracle планировала перестать доверять алгоритму MD5 в январе 2017 года, но некоторые разработчики запросили дополнительное время, чтобы подготовиться к этому.

Oracle посоветовала разработчикам проверить, подписаны ли их JAR-файлы с использованием MD5 и если да, повторно подписать их с более сильным алгоритмом. Чтобы удалить существующие подписи MD5 в утилите Zip можно использовать следующую команду:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

«Если вы не сами подписывали, либо создавали JAR-файлы, которые вы используете, вам необходимо обратиться непосредственно к их разработчику. Если разработчик не может выяснить с использованием какого алгоритма он подписывал свои файлы (если подписывал), то рекомендуется повторно подписать их, используя более современный алгоритм» - объясняет сотрудник Oracle, Эрик Костлоу (Erik Costlow).

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

Баг Android сливает DNS-запросы при блокировке соединений в обход VPN

Один из пользователей Mullvad VPN заметил интересную особенность: смартфоны на Android сливают DNS-запросы в момент переключения серверов. Причем это происходит даже при включенной функции «Always-on VPN» с опцией блокировки соединений без VPN.

«Always-on VPN» запускает службу VPN при включении устройства и поддерживает её работу на протяжении всего цикла активности.

Опция «Block Connections Without VPN» в этом контексте нужна для экстренного разрыва сетевого соединения, её задача — убедиться, что все запросы проходят через VPN-туннель.

Тем не менее, как отмечают в Mullvad, 22 апреля один из пользователей обнаружил в Android баг, из-за которого частично сливалась информация о DNS. Проблема актуальна даже для последней версии мобильной операционной системы — Android 14.

Описанный баг проявляется при использовании приложений, отправляющих прямые запросы C-функции getaddrinfo. Задача последней — предоставлять независимый от протокола перевод из тестового имени хоста в IP-адрес.

В итоге выяснилось, что Android сливает DNS-трафик при выключенном VPN или в момент, когда пользователь меняет настройки клиента.

«Нам не удалось обнаружить утечки у приложений, использующих исключительно Android API (например, DnsResolver). А вот браузер Chrome — классический пример софта, использующего getaddrinfo напрямую», — объясняют в Mullvad.

«Утечка происходит вне зависимости от того, включены ли опции “Always-on VPN” и “Block connections without VPN”, что является нетипичным поведением системы и должно быть устранено на уровне ОС».

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

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