Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta

Критическая уязвимость в OpenSSL 1.0.1 и 1.0.2-beta

Несколько часов назад сотрудники The OpenSSL Project выпустили бюллетень безопасности, в котором сообщается о критической уязвимости CVE-2014-0160 в популярной криптографической библиотеке OpenSSL. Уязвимость связана с отсутствием необходимой проверки границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

Из-за этой маленькой ошибки одного программиста кто угодно получает прямой доступ к оперативной памяти компьютеров, чьи коммуникации «защищены» уязвимой версией OpenSSL. В том числе, злоумышленник получает доступ к секретным ключам, именам и паролям пользователей и всему контенту, который должен передаваться в зашифрованном виде. При этом не остается никаких следов проникновения в систему, сообщает habrahabr.ru.

Некто, знавший об уязвимости, мог прослушивать «зашифрованный» трафик почти во всем интернете с марта 2012 года, когда вышла версия OpenSSL 1.0.1. В то время была продемонстрирована успешная атака на TLS (BEAST), и многие перешли на защищенную версию TLS 1.2, появление которой совпало с выходом OpenSSL 1.0.1.

Уязвимая версия OpenSSL используется в популярных веб-серверах Nginx и Apache, на почтовых серверах, IM-серверах, VPN, а также во множестве других программ. Ущерб от этого бага исключительно велик.

Некоторые дистрибутивы операционных систем с уязвимой версией OpenSSL:
Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
CentOS 6.5, OpenSSL 1.0.1e-15)
Fedora 18, OpenSSL 1.0.1e-4
OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
NetBSD 5.0.2 (OpenSSL 1.0.1e)
OpenSUSE 12.2 (OpenSSL 1.0.1c)

Дистрибутивы с более ранними версиями OpenSSL: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14, SUSE Linux Enterprise Server.

Баг присутствует во всех версиях веток OpenSSL 1.0.1 и 1.0.2-beta, включая 1.0.1f и 1.0.2-beta1. Исправленная версия — 1.0.1g, которую всем пострадавшим необходимо установить немедленно, после чего сгенерировать новые ключи и сертификаты и предпринять прочие меры безопасности. Пользователей следует предупредить о возможной утечке их паролей. В случае невозможности немедленного апдейта на исправленную версию следует перекомпилировать OpenSSL с флагом -DOPENSSL_NO_HEARTBEATS.

Уязвимость обнаружили специалисты по информационной безопасности из компании Codenomicon, а также, независимо от них, Нил Мехта (Neel Mehta) из подразделения Google Security. Именно последний сообщил разработчикам The OpenSSL Project, что нужно срочно исправить код. Ребята из компании Codenomicon подготовили подробное описание бага и даже открыли для него отдельный сайт Heartbleed.com с изображением кровоточащего сердца.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

В Chrome для Android тестируют выдачу сайтам только примерной геолокации

Разработчики Android-версии Chrome тестируют более умный и аккуратный способ делиться геолокацией — теперь браузер может выдавать сайтам не точные координаты, а только примерное местоположение. Это не связано с системными настройками Android для приложений: речь идёт о новом уровне контроля именно над веб-сайтами.

Новую опцию для выдачи неточной геолокации отметили в версии Chrome 142.0.7444.171.

Она автоматически появилась у одного из тестировщиков, хотя другие не заметили нововведения, что намекает на A/B-тестирование. То есть Google пока экспериментирует с обновлённым диалогом разрешений.

Сегодня Chrome для Android получает доступ к точной геолокации через настройки приложения: достаточно зажать иконку браузера, открыть «О приложении», затем «Разрешения» → «Местоположение» и включить параметр «Использовать точное местоположение».

 

Можно и вовсе его отключить — тогда Chrome будет работать только с примерной локацией. Но такой подход ломает сайты, которым действительно нужны точные координаты — например, сервисы навигации.

Новая функция решает эту проблему: браузер может сохранить разрешение на точную геолокацию на уровне приложения, но выдавать сайтам только приблизительное местоположение, если вы так настроите логику.

 

Таким образом, сайты, которым достаточно знать ваш район, не получат конкретных координат, а тем, кто действительно требует точных данных, придётся запрашивать доступ отдельно.

Android давно поддерживает два уровня отслеживания геолокации: примерный (радиус около 3 кв. км) и точный. Многие приложения используют это через системные диалоги разрешений, но Chrome до сих пор не применял такую логику к веб-ресурсам.

Теперь это меняется. Функцию можно включить вручную через chrome://flags — именно там Google хранит экспериментальные настройки. После активации выбор «Примерное местоположение» ограничит сайты только вашей приблизительной зоной.

 

 

Google пока не объявляла о нововведении официально и не раскрывала сроки широкого запуска. Но раз эксперимент уже идёт, пользователи Android могут довольно скоро получить более гибкий и приватный контроль над тем, какие сайты видят их точное местоположение.

Пару недель назад мы сообщали, что в Android 16 появилась новая функция density-based coarse location — «приблизительное местоположение на основе плотности населения». Она работает просто: система проверяет, насколько густо заселён район, и если рядом мало людей, то делает координаты ещё более размытыми.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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