Microsoft, предположительно, потеряла исходный код компонента Office

Microsoft, предположительно, потеряла исходный код компонента Office

Microsoft, предположительно, потеряла исходный код компонента Office

У экспертов в области информационной безопасности появилось подозрение, что компания, возможно, потеряла исходный код одного из своих компонентов Office. Эксперты на этой неделе пришли к такому выводу после того, как Microsoft исправила уязвимость, отслеживаемую как CVE-2017-11882, которая затронула EQNEDT32.EXE - редактор формул, включенный в пакет Microsoft Office.

Напомним, что на днях мы писали об этой уязвимости. Теперь же исследователи из 0patch заметили, что исправленный файл EQNEDT32.EXE почти идентичен старому.

«Вы когда-нибудь видели компилятор C/C++, который бы поместил все функции в исполняемый файл 500+ KB после восстановления измененного исходного кода точно по тому же адресу», — задают эксперты риторический вопрос.

На самом деле, эксперты намекают, что EQNEDT32.EXE настолько похож на свою предыдущую версию потому, что инженеры Microsoft вручную отредактировали сам двоичный файл. Стоит учитывать, что такая компания, как Microsoft, имеющая прочную и сложную разработку программного обеспечения и методы обеспечения безопасности, никогда не сочтет приемлемым редактирование двоичного файла вручную.

Единственное разумное объяснение этому — Microsoft каким-то образом потеряла исходный код давно забытого компонента Office.

Отметим, что редактирование исполняемых файлов вручную считается нежелательной мерой, используемой программистами низкого уровня. Как правило, такие меры создают больше проблем, чем решают. Разработчики, практикующие такое, обычно рискуют повредить весь бинарный файл. Согласно 0patch, исправление EQNEDT32.EXE было сделано очень качественно — «произведение искусства».

ChatGPT тайно заставили выполнять команды из чужого аккаунта

Исследователи из Check Point Research обнаружили канал, позволявший передавать команды между изолированными сессиями ChatGPT из разных аккаунтов. В результате ассистент мог отвечать пользователю как обычно, а параллельно выполнять чужое задание и отправлять результат атакующему.

Канал проходил через внутренний JFrog Artifactory, к которому обращались контейнеры ChatGPT при установке программных пакетов.

Напрямую связаться друг с другом они не могли, но имели доступ к общему сервису. Исследователи выяснили, что контейнеры способны записывать данные в свойства объектов Artifactory и читать их из других аккаунтов. Метаданные репозитория фактически превратились в общий буфер обмена.


Чтобы запустить атаку, требовалось поместить вредоносную инструкцию в контекст жертвы — например, через скопированный промпт, общую беседу или специально созданный GPT. После обычного сообщения пользователя ассистент проверял скрытый канал, забирал оттуда задачу и выполнял её с правами текущей сессии.


В демонстрации ChatGPT получил данные из подключённого Gmail жертвы и передал их исследовательскому аккаунту. На экране при этом появился нормальный ответ на исходный вопрос. Единственной подсказкой оставалась небольшая отметка Talked to Gmail — уже после чтения почты.


Масштаб возможной утечки зависел от полномочий сессии: атакующему потенциально становились доступны история чата, загруженные файлы и данные из подключённых Gmail, Google Drive, Microsoft Teams или GitHub.

Check Point сообщила о проблеме OpenAI. Корпорация подтвердила, что задействованный экземпляр Artifactory выведен из эксплуатации, поэтому описанный канал больше не работает. Данных о его использовании в реальных атаках нет.

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