Обновления Windows 10 приводят к сбою приложений на Visual Basic

Обновления Windows 10 приводят к сбою приложений на Visual Basic

Обновления Windows 10 приводят к сбою приложений на Visual Basic

Microsoft пытается выяснить причину проблемы, проявившей себя после установки очередных обновлений Windows. На этот раз баг приводит к сбою в работе приложений на VB6, VBA и VBScript — они в какой-то момент перестают отвечать и выдают ошибку.

Пользователи затронутых проблемой систем при использовании приложений, созданных с помощью Visual Basic 6 (VB6) или Visual Basic Scripting Edition (VBScript), могут наблюдать ошибку «invalid procedure call error».

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

Клиент Сервер Проблемное обновление
Windows 10 версии 1903 Windows Server версии 1903 KB4512508
Windows 10 версии 1809 Windows Server версии 1809/Windows Server 2019 KB4503327
Windows 10 Enterprise LTSC 2019   N/A
Windows 10, version 1803 Windows Server, version 1803 KB4512501
Windows 10, version 1709 Windows Server, version 1709 KB4512516
Windows 10, version 1703 Windows Server 2012 R2 KB4512507
Windows 10 Enterprise LTSC 2016 Windows Server 2012 N/A
Windows 10, version 1607 Windows Server 2016 KB4512517
Windows 10 Enterprise LTSC 2015   N/A
Windows 8.1 Windows Server 2012 R2 KB4512488
Windows 7 SP1 Windows Server 2008 R2 SP1 KB4512506

Представители Microsoft заявили, что в настоящее время проводится расследование с целью выявить причину такого поведения ОС. Как только разработчики выяснят что-то конкретное, будет выпущен соответствующий патч.

В Exim нашли критическую RCE-уязвимость: почтовики лучше обновить срочно

В популярном почтовом сервере Exim обнаружили критическую уязвимость CVE-2026-45185. При определённых условиях она позволяет удалённому атакующему без аутентификации выполнить произвольный код на сервере. Вполне себе неприятный сценарий, поэтому лучше не затягивать с установкой патча.

Проблема затрагивает версии Exim с 4.97 по 4.99.2, если они собраны с библиотекой GnuTLS и рекламируют STARTTLS вместе с CHUNKING. Сборки на OpenSSL, по имеющимся данным, не страдают — редкий случай, когда можно выдохнуть, но только после проверки конфигурации.

Суть бага — use-after-free во время завершения TLS-сессии при обработке SMTP-трафика BDAT. Exim освобождает TLS-буфер передачи, но затем продолжает использовать устаревшие callback-ссылки, которые могут писать данные уже в освобождённую область памяти. А дальше начинается классика жанра: повреждение памяти, удалённое выполнение кода и очень плохой день у администратора.

Exim широко используется на Linux- и Unix-серверах, в корпоративных почтовых системах, а также в Debian- и Ubuntu-based дистрибутивах, где он исторически часто выступал почтовым сервером по умолчанию.

По данным XBOW, баг был передан мейнтейнерам Exim 1 мая, подтверждение пришло 5 мая, а ещё через три дня уведомили затронутые Linux-дистрибутивы. Исправление уже выпущено в Exim 4.99.3.

Отдельная перчинка — попытка собрать PoC с помощью ИИ. XBOW устроила семидневное соревнование между своей автономной системой XBOW Native и человеком-исследователем, которому помогала большая языковая модель. ИИ смог собрать рабочий эксплойт для упрощённой цели без ASLR и с бинарником non-PIE. Во втором подходе LLM добралась до эксплуатации на системе с ASLR, но всё ещё без PIE.

Победил, впрочем, человек. Исследователь признал, что ИИ сильно ускоряет разбор незнакомого кода, сборку файлов и проверку направлений атаки, но до самостоятельной эксплуатации реального софта без человеческого руля моделям ещё надо подрасти.

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