Mac OS X уязвима перед атаками из-за с устаревшей версии Git

Mac OS X уязвима перед атаками из-за с устаревшей версии Git

Mac OS X уязвима перед атаками из-за с устаревшей версии Git

Независимая исследовательница Рейчел Крол (Rachel Kroll) сообщает, что даже новейшие версии Mac OS X уязвимы перед атаками злоумышленников. Распространяющийся в составе операционной системы Git по умолчанию поставляется в виде сильно устаревшей версии, которая содержит две опасные уязвимости.

Крол пишет, что в составе El Capitan поставляется устаревшая и проблемная версия Git — 2.6.4. Дело в том, что версии Git ниже 2.7.3 содержат две опасные уязвимости: CVE-2016-2324 и CVE-2016-2315. Обе они связаны с переполнение буфера хипа и позволяют атакующему удаленно исполнить произвольный код на компьютере жертвы. Злоумышленнику достаточно спрятать вредоносный код в своем репозитории, заманить туда жертву, и дело сделано, пишет xakep.ru.

Исследовательница указывает и на тот факт, что пользователь не сможет просто самостоятельно обновить Git или как-то его ограничить. Благодарить за это нужно новейшие методы защиты Apple. Изучив бэкэнд El Capitan Крол обнаружила, что /usr/bin/git является ссылкой и уводит в Xcode: /Applications/Xcode.app/Contents/Developer/usr/bin. Только через этот бинарник можно «запретить» уязвимый Git.

«Если вы зависите от такого компьютера, я искренне вам сочувствую», — пишет Крол. — «Этот пост написан в попытке заставить их [Apple] что-то предпринять, потому как данная проблема актуальна для многих важных для меня людей. Фактически они в заднице до тех пор, пока Apple не создаст и не предоставит им патч».

Разумеется, всегда остается вариант установить свежую версию Git вместо встроенной, но это не до конца решает проблему. Дело в том, что встроенная и уязвимая версия никуда из системы не исчезнет. К тому же, в некоторых приложениях путь /usr/bin/git может быть жестко прописан, так что система всё равно использует устаревшую версию, а пользователь даже не узнает об этом.

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

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

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

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

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

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

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

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

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