Как многие уже слышали, за последнюю неделю были опубликованы три новые критические zero-day уязвимости в Adobe Flash Player: CVE-2015-5119, CVE-2015-5122 и CVE-2015-5123. Ключевое слово — "опубликованы", найдены они были (и эксплуатировались) гораздо раньше. Но даже после публикации, все популярные exploit-паки включали в свой состав соответствующие эксплоиты в течение нескольких часов, в то время как Adobe выпускали тривиальные фиксы через несколько дней. Чтобы хоть как-то смягчить проблему, Mozilla даже временно заблокировала Flash в Firefox, чтобы не слишком технически продвинутые пользователи не наловили зоопарк вирусов.
Таким образом, все системы, на которых был включен Flash Player в какие-то моменты времени в течение последней недели, потенциально скомпрометированы. И надо менять все пароли, приватные ключи, etc. К счастью, большинство интернет-компаний не стремятся помогать хакерам расширять свои ботнеты, и поэтому Flash уже почти нигде не используется: Youtube и Facebook показывают видео при помощи HTML5, мобильные устройства вообще его не поддерживают (Стив Джобс давным-давно призывал его убить), нормальные game-developer'ы пишут браузерные игры на JS, даже Unity убрали поддержку этого плагина.
К величайшему сожалению, один из немногих сайтов в интернете, всё ещё использующий Flash, — это Codeforces. Реализовать взломы на JS должно быть очень просто, но администрация всё ещё надеется на ложное чувство безопасности, предоставляемое флешевым плагином (несмотря на все рациональные доводы — декомпилировать обфусцированный JS гораздо сложнее, чем флеш-плагин, который к тому же жутко глючный и не поддерживается по умолчанию в большинстве браузеров). Теперь к этим доводам добавился ещё один: никто не хочет держать у себя в браузере парадную дверь для хакеров. Очень надеюсь, что разработчики Codeforces прислушаются к этому доводу и исправят досадный недостаток своего в остально замечательного проекта.
Автокомментарий: текст был обновлен пользователем ilyakor (предыдущая версия, новая версия, сравнить).
Илья, с днем рождения!
ИМХО, истерия вокруг Flash преувеличена. В последний год было много слышно о не менее страшных уязвимостях (в том числе в openssl, bash, Unity, glibc, Skype, android, iOS, и многое другое). Далеко не все эти уязвимости мгновенно закрывались. Патч для heartbleed я ставил руками на сервера, так как в репозиториях CentOS и Fedora он появился не мгновенно.
При всех своих недостатках Flash — крутая технология, которая взорвала интернет и очень круто опередила время. Поддержка mp3 — 98 год, потоковое видео в 2002-м, настоящие сетевые соединения в 2005-м, h.264 в 2007, аппаратное ускорение в 2011-м. Вспомните в каком состоянии были браузеры и поддержка стандартов в те годы. Я сто раз слышал об убийцах флэша: Java Applets, JavaFX, Silverlight. И где они?
HTML5 — затея отличная, но далеко не все он заменяет и далеко не всегда круто работает. Чтобы писать игры на нем, надо неслабо напрягаться, чтобы выдать нормальный FPS. Вот ты Ваню Попелышева упомянул, ну так почитайте как он нахачивал, чтобы не тормозила простая 2D игра на спрайтах. Я же писал визуализацию к RussianAiCup на HTML5 и так себе развлечение это было.
Призывы выпиливать и запрещать Flash похожи на неконкурентную нерыночную борьбу. Если HTML5 так хорош, то должен победить динозавра из прошлого века и без силовых приемов.
Не знаю, что там Мозилла заблокировала, но у меня в последнем Firefox отлично работает Flash. Он, кстати, оперативно обновился и дыры, видимо, закрыл:
По поводу того, что взломы легко сделать на JS — я не вижу простого хорошего способа хорошо это сделать. Напомню, что:
Конечно, если десктопные браузеры начнут усиленно выпиливать Flash, придется что-то придумывать. Однако при текущем положении дел (какой процент десктопных браузеров поддерживает Flash? 99%?) инвестировать значительные силы в то, что работает желания нет.
Спасибо за поздравление!
Я не отрицаю историческое значение Flash'а. Да, в своё время он сильно помог развитию web'а, но с тех пор положение дел сильно изменилось. Теперь любому wannabe-хакеру доступны очень мощные и функциональные инструменты, не требующие никаких специальных знаний для их использования. В этих условиях любая дыра такого масштаба как последние три во флеше — катастрофа.
Из перечисленных дыр — Heartbleed конечно тоже был катастрофой; остальное (из того что я знаю) — не настолько критично (для успешной эксплуатации уязвимостей вроде ghost и shellshock владелец атакуемой системы должен сделать много глупостей). Но в случае с Heartbleed по крайней мере были предприняты меры чтобы такое не повторилось: проведён независимый security-audit, куча народу перечитала код в поисках подобных багов, etc.
В случае с Flash — Adobe даже не чешется по поводу безопасности, критические уязвимости находят снова и снова, а они даже не торопятся патчи выпускать. Если им было бы не совсем пофиг — давно бы провели security audit и заопенсорсили Flash; но видимо даже на это им жалко ресурсов.
По поводу Java Applets, JavaFX, Silverlight — они ничем не лучше флеша. Браузерные плагины — это костыли, призванные компенсировать недостаток функциональности в базовом API, и если они ещё и с закрытым кодом и кучей багов, — тем хуже. В них нет необходимости в век HTML5. Призывы выпиливать Flash конечно нерыночные — но рыночные методы не всегда работают. Главный пример — вопросы безопасности (как в реальном мире, так и в IT), и это как раз случай флеша.
По поводу флеша в Firefox и "оперативного" обновления: они включили его обратно во вторник, когда Adobe наконец выпустили патч. Только почему-то эксплоит-паки выпустили обновления в 20 раз быстрее.
По поводу взломов в JS: мне кажется, народ не понимает, насколько HTML5+JS крут. Есть же например llvm-to-js конвертеры (некоторые демки там впечатляют), т.е. можно например написать всё на C++ (подключив нужные библиотеки для рендеринга текста), скомпилировать, прогнать через обфускатор и сконвертить в JS. Да, JS получится массивным, но пользователям надо будет его загрузить только один раз. Такое ломать будет гораздо сложнее, чем просто прикрутить OCR или распарсить wire-протокол.
По поводу 99% — доля линукса в мире больше 1%, а среди пользователей codeforces — наверное, ещё больше. При этом там флеш не работает без мучительных плясок с бубном (в Chromium; в Firefox — я вообще не умею нормально его ставить, чтобы получившаяся конструкция не разваливалась после каждого чиха). Не говоря уж о том, что параноики^W люди, серьёзно относящиеся к безопасности, очень не любят запускать проприетарное непонятно что с кучей непонятно каких багов.
Так потом же еще, вроде, были серьезные уязвимости и не один раз. Как раз пример с Heartbleed довольно показателен, что core-библиотека с открытым кодом, которая используется чуть менее чем на всех серверах, имеет жуткие дыры на протяжении лет.
На https://helpx.adobe.com/security/products/flash-player/apsb15-16.html написано, что 8-го выпустили патч. Зачем FF неделю ждал? Про эксплоит-паки — посканировал подручные windows-машины, проблем не нашел. Я уж не смотрел, что нужно точно сделать, чтобы эти дыры проэксплуатировать — может зайти надо было куда (не)надо, чтобы тебе флешку с эксплойтом подсунули?
Не понятно, чем это помогает. Сделай proof-of-concept. В этой демке тоже всё рисуется на канвасе, который значительно проще флэшки взламывается. Т.е. наверное как обфускатор этот подход отлично сработает, но не только в обфускации дело.
Т.е. мой тезис такой: сделать не менее круто чем есть сейчас, требует существенного вложения времени и сил. С посылом из статьи "Реализовать взломы на JS должно быть очень просто" я не согласен. Если тебе просто, то с радостью посмотрю в работающий функциональный прототип.
Установил Chrome из официального канала в Fedora 21. Flash завелся из коробки без каких-либо настроек.
Да, пример очень показательный, — одного code review недостаточно, чтобы обеспечить безопасность; нужно инвестировать очень много усилий в поиски багов и поддержание качества кода. Но если "правильный" подход не идеальный, — это не значит, что надо делать всё "неправильно", как Adobe (т.е. закрытый код сомнительного качества, с большой вероятностью слепленный из костылей и хаков, который никогда не ревьюился).
Эм, это был CVE-2015-5119. С тех пор в течение недели нашли ещё CVE-2015-5122 и CVE-2015-5123 :)
Да, само по себе оно на компьютер не установится, надо зайти на какой-нибудь сайт, который подсунет эксплоит. Если пользоваться только gmail и codeforces и никуда больше не заходить — то да, словить бяку довольно сложно. Но люди же ходят по разным сайтам с флеш-баннерами от кого попало (например новостным), играют во флеш-игры на сомнительных сайтах, смотрят flash-видео (на не-youtube видеохостингах), и т.д. В общем, при активном использовании интернета попасться очень просто.
Ну так оно попиксельно рисует, такое только OCRом ломать можно, точно так же, как и флеш. Про PoC — попробую сделать, когда будет время (возможно, в ближайшие выходные).
Хм, я тоже пользуюсь Федорой, и там в официальных каналах Chrome нет, есть только Chromium (там вообще в репозиториях не-opensource нет, чтобы его использовать, нужно подключать сторонние репозитории с бякой). Я для взломов на codeforces использовал Chromium в связке с PPAPI Flash, выдранным из rpm-ки Chrome'а, что является жутким костылём...
C Flash-ем использование OCR частично затруднено, так как окно для нетривиальных задач показывает не весь код, а только часть, и выдрать весь код как единую картинку сложновато. С канвасом же это делается совсем просто и легко автоматизируется.
Ну я набрал в гугле "fedora install chrome" и поставил как написано в первой же ссылке http://www.if-not-true-then-false.com/2010/install-google-chrome-with-yum-on-fedora-red-hat-rhel/
ОК, обещанный proof-of-concept (пока Firefox-only): https://jsfiddle.net/nd2L0Lrd/
Я особо не заморачивался с обфускацией, так что наверное его можно декомпилировать. У этого прототипа 3 проблемы:
С последними двумя проблемами я умею бороться, если потребуется (можно рендерить только то что видно — тогда и работать будет быстро, и всю программу разом не получить).
Ещё есть очевидная проблема — payload программы для рендеринга защищён методом security through obscurity. Но мне кажется, в данном случае проще прогнать через OCR, чем декодировать payload (я постарался, чтобы это было как можно более мучительно).
Замечу, что я не использовал адских хаков с компиляцией C++ -> JS, упоминаемых мной выше. Тут чисто самописный JS с рисованием на Canvas. Интересно, сможет ли кто-нибудь это сломать простыми трюками (вроде упоминавшейся подмены fillText). Только плз не декомпилируйте — как я упоминал выше, я не заморачивался обфускацией.
У меня не работает: Uncaught SecurityError: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.
В Хроме пока не работает, да. Я это разрабатывал/дебагал в Firefox'е, и т.к. процесс занял вместо нескольких минут несколько часов, мне не очень хотелось в час ночи разбираться, что именно в Хроме пошло не так. Будет время — посмотрю, как это пофиксить, судя по ошибке, должно лечиться каким-нибудь cross-origin атрибутом/header'ом.
Ок, обновил ссылку, теперь должно работать во всех браузерах: https://jsfiddle.net/nd2L0Lrd/1/
Правда, немного подпортился рендерер, и новую версию (наверное) проще сломать, но для proof of concept сойдёт.
UPD. Идея использовать SVG была не очень хорошей, видимо, без Canvas не обойтись.
Часть букв обрезается снизу. Хорошо заметно на букве g.
Кликнул по коду, выбрал открыть изображение в новом табе и нажал горячую клавишу, чтобы увидеть исходный код страницы. После этого код части решения виден практически в явном виде.
Дальше экстеншен думаю уже может его извлечь. Ну или можно накопипастить и потом запустить программу, которая очистит результат от тэгов.
Hex редактор памяти аналогично видит текст описания svg файлов.
А порядок этих svg'шек HEX редактор может получить?
Опс, в этой версии его можно ещё проще достать; не ожидал такой подлости от SVG. Прошлая версия в этом смысле гораздо лучше, буду разбираться, как её заставить в Хроме работать.
Первая версия тоже ломается просто. Сохраняется страничка, потом там, где ты создаёшь svg добавляется console.log с выводом ровно того же, по чему ты строишь svn и мы в результате можем получить блоки кода. Вставив их в новый документ получим текст, правда не подряд, но это мелочи
Ну "не подряд" — это как раз фича. Т.е. моя идея была в том, что даже если подменят функции, которыми я рисую, то получат текст в случайном порядке. А чтобы восстановить порядок — надо разобраться в глобальной логике, что по идее будет очень сложно в обфусцированной версии.
Информация к размышлению. Chrome уже отключил все NPAPI плагины, включая Java. В сентябре их нельзя будет включить даже через настройки для разработчиков. Flash — на очереди. Думаю разработчики Chrome уже следят за быстро падающей частотой его использования и прикидывают сроки его отключения. Silverlight отключили не смотря на то, что оставалось 10% пользователей, которые использовали его хотя бы в раз месяц. Пока что Chrome уже начал отключать все Flash-ролики на странице, которые он не посчитал "основным контентом".
Кроме того, как только Chrome в сентябре полностью отключит NPAPI, у всех Chromium-based браузеров начнутся проблемы, поскольку они не смогут использовать NPAPI Flash установленный в системе и им нужно будет либо просить пользователя позаимствовать PPAPI-Flash из хрома, либо заключать соглашение с Adobe для распространения PPAPI версии. Думаю в Adobe таким соглашениям будут не рады и если согласятся, то запросят денег больше, чем разработчики этих браузеров готовы заплатить. Сколько времени разработчики Chromium-based браузеров готовы поддерживать NPAPI самостоятельно ради Flash'a — большой вопрос.
Проблема Flash'a в том, что у 99% разработчиков Chrome'a нет свободного доступа к его исходникам, а потому они не могут так же эффективно искать в нем уязвимости и проводить рефакторинги, которые должны уменьшить их количество, как в основном браузере.
Лично я уже Flash на своем личном компьютере удалил, остался только встроенный в хром. На рабочем Linux компьютере я просто не стал его в основном браузере ставить.
Судьба Flash-а пока туманна и озвученных roadmap-ов относительно его выпиливания у браузеров нет. Конечно, если пользоваться им станет затруднительно, то заменим его на другие технологии.
Кстати, а что такое PepperFlashPlayer? Его не Google делает?
PepperFlashPlayer и PPAPI-Flash — это одно и тоже. Google может вносить туда изменения (например, если нужно ужесточить сэндбокс), но доступ туда только у избранных разработчиков хрома и поэтому обычно уязвимости там исправляют разработчики из Adobe.
Собственно, скорее всего именно из-за соглашения между Adobe и Google, уязвимости в Flash'e так быстро исправляются.
В частности это говорит о том, что Adobe идут на уступки с закрытостью Flash. Может припечет их и еще больше откроют.
просто в целях пруф-оф-концепт, не для публикации
попробовать, разревёрсить флэш с взломами и показать, что он не даёт никакой дополнительной защиты...
На данный момент эта проблема тоже существует -- swf'ку легко декомпильнуть, шифр легко обратить, так что читерить несложно (лично я просто поленился это дело автоматизировать, только взглянул на код флешки и убедился, что алгоритм там простой ;)).
Не думаю, что ситуация сильно изменится, если сделать JS-решение. Всё равно можно разобрать всё и сделать чит за время одного раунда.
P.S. Надеюсь, это обсуждение не послужит стимулом для того, чтобы автоматизировать фаззеры чужих решений. А если уж делаете их, то делайте только как PoC...
Картинка в тему