Zoom пообещал внедрить сквозное шифрование для Zoom Phone

Zoom пообещал внедрить сквозное шифрование для Zoom Phone

Zoom пообещал внедрить сквозное шифрование для Zoom Phone

Популярный сервис для видеоконференций Zoom представил ряд новых функций, призванных повысить безопасность пользователей. В частности, сквозное шифрование (E2EE), реализованное в Zoom Meetings в октябре прошлого года, теперь будет доступно и для Zoom Phone.

Если пользователь пожелает защитить свою беседу, ему придётся включить E2EE вручную. Вот как описывают процесс представители Zoom:

«Во время звонка пользователи могут нажать на кнопку "More" и найти опцию, позволяющую включить сквозное шифрование. Активация занимает буквально секунду и помогает защитить людей от скомпрометированных серверов».

«Помимо этого, пользователи могут обмениваться кодами безопасности по голосовому каналу, что позволит избежать атак вида "meddler in the middle". Сквозное шифрование для Zoom Phone будет доступно в следующем году».

Также разработчики рассказали о двух других нововведениях, нацеленных на повышение безопасности всей платформы: Bring Your Own Key (BYOK) и Verified Identity. Первая функция поможет тем клиентам, которым приходится иметь дело со строгими соответствиями требованиям, а вторая лучше защитит пользователей от социальной инженерии.

BYOK, согласно описанию, позволит людям управлять собственными ключами шифрования. Для этого разработчики создадут отдельную систему, которая будет содержать мастер-ключ. К этому ключу не будет доступа даже у самого Zoom.

Другое нововведение — Verified Identity — позволит пользователям убедиться в том, что их собеседник действительно является тем, за кого себя выдаёт. Как мы уже отмечали выше, это существенно снизит риски, связанные с социальной инженерией.

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

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

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

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

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