Comments 217
Лол.
Патсаны, расскажите, как выполнить произвольный код после БСОДа?)
Мы исследуем причину почему Safari x64 вызывает BSOD. На данный момент такой код ловится антивирусом как Exploit:Win32/BlueFrame
В исходном сообщении сказано только о BSOD. Откуда данные про выполнение произвольного кода?
twitter.com/#!/w3bd3vil/status/148454992989261824
twitter.com/#!/w3bd3vil/status/148454992989261824
В сообщении по ссылке, которую я указал как источник.
На secunia.com/advisories/47237 написано «Memory Corruption Vulnerability» где здесь «arbitrary code execution»?
Андрей, я что-то не так понимаю или по ссылке в разделе Description (3 абзац от раздела) сказано примерно следующее:
Successful exploitation may allow execution of arbitrary code with kernel-mode privileges.
Successful exploitation may allow execution of arbitrary code with kernel-mode privileges.
Ключевое слово «may», то есть «вероятно». Пока иного не доказано. Эксплоита способного исполнять код не обнаружено.
Более того сам MS еще официальных результатов исследования не опубликовал.
Так что рассказывать про исполнение кода пока преждевременно.
Более того сам MS еще официальных результатов исследования не опубликовал.
Так что рассказывать про исполнение кода пока преждевременно.
Скорее всего в Secunia следуют принципу лучше перебдеть, чем недобдеть. Даже если эксплойта не обнаружено, то отделам по IT-безопасности предприятий лучше готовиться к худшему. На всякий пожарный случай.
А Apple работает над проблемой, нет информации? Всё-таки проблема двойная. И кто в ней виноват ещё неизвестно: то ли вы кривой код Safari, работающий с библиотекой, то ли сама библиотека глючная.
А Apple работает над проблемой, нет информации? Всё-таки проблема двойная. И кто в ней виноват ещё неизвестно: то ли вы кривой код Safari, работающий с библиотекой, то ли сама библиотека глючная.
Всегда следует придерживаться простого правила — если что-то лезет в интернет, то оно должно обладать минимальными привелегиями.
по-моему тут речь про дыру где-то в районе GDI, так что права приложения пофигу.
ЗЫ Исходя из вашего тезиса, с какими правами должны работать драйвера сетевухи? Они-то в интернет лазят так, как никто другой.
ЗЫ Исходя из вашего тезиса, с какими правами должны работать драйвера сетевухи? Они-то в интернет лазят так, как никто другой.
может, я не прав, но справедливости ради… сами драйвера никуда не лезут, они лишь обеспечивают работу устройства.
Ну что, кто смелый? tort8.com/static/bsod.html
Я спасовал. Сейчас виртуалку поставлю и посмотрю.
Нечего там смотреть.
Рекомендую проспаться. Ясно написано, что нужен Safari же.
что-то вроде «Мы пока не научились писать вирусы, установите пожалуйста Safari и запустите его сами» :)
Если не научатся эксплуатировать эту дыру другим способом, можно спать спокойно — сафари на винде довольно редкий гость (кроме верстальщиков).
Если не научатся эксплуатировать эту дыру другим способом, можно спать спокойно — сафари на винде довольно редкий гость (кроме верстальщиков).
> Патча на данный момент не существует.
Существует. Любой другой браузер, же! :)
Существует. Любой другой браузер, же! :)
Сначала спроси, кто пользуется Safari под Windows 7 x64.
На Маке тоже есть проблема, Safari 5.1.2 выжрал всю доступную память и завис.
хм, а у меня на 10.7 safari 5.1.2 при просмотре этой html-страницы ведёт себя нормально
Safari 5.1.1 на 64-битной OS X 10.7.2 жрал-жрал память, доходило до 600 мб, но потом прыгал на 35 мб, снова до 600, снова на 35, немного грузил процессор — до 16%, потом загрузка опускалась до 0, адресная строка и строка поиска работали, на клики правой кнопкой отвечал с задержкой секунд на 10.
Полёт нормальный.
Подтверждаю. На Lion сожрал больще 5 гиг и завис…
Так и не нашел проблему описанную jj_killer
При этом было открыто 11 вкладок в 4-х окнах, я хз что там у Вас жрёт оперативку.
Вероятно у Вас 512 оперативы на весь мак?
При этом было открыто 11 вкладок в 4-х окнах, я хз что там у Вас жрёт оперативку.
Вероятно у Вас 512 оперативы на весь мак?
Процесс Safari Web Content выжирает в первые секунд 30, потом опускается до уровня 200–500 МБ и дискомфорта особо не доставляет, но я просто привык, что все работает моментально. Оперативы у меня 12 ГБ.
Нахожу сие явление в вашем случае весьма странным. Изменений в скорости работы или резкого всплеска нагрузки на что-либо я не заметил не в первые 30 секунд не в последующие 45 минут открытой страницы.
Процесс начинает жрать память если скролить сие дело с остервенением. По крайней мере к падениям и висякам как было сказано выше, на маке вся эта петрушка не приводит.
И как вообще случился айфрейм такой высоты?
Firefox даже не моргнул :)
Не то, чтобы дыра будет обладать популярностью (сафари, да еще на х64), но неаккуратненько как-то.
А чего не так с x64? Для меня сейчас редкость встретить х32, а не х64.
64 обычно стоит на новых ноутбуках и брендовых десктопах, а кто ставит сам (или кому ставят знакомые) предпочитают вроде 32. Если вообще не XP :)
Ясно. У меня, просто, наобарот знакомые сносят х32, докупают оперативы и ставят х64, даде на ноутах с 4 Гигами ставят х64.
Необходимости «обычному пользователю» сейчас использовать х64 я не вижу (если Firefox не компилировать с оптимизациями :) ). Софта, который бы был чисто х64, не имея 32-битной версии, не встречал. С другой стороны, использовать 32-бит на новом железе хотя бы с двумя гигами тоже особо незачем. Сам, сменив железо недавно, поставил 64-бит (правда не винду, а линукс, но не суть) — тоже проблем не вижу, даже с флэшем, с которым намучался года 3-4 назад на 64-бит линуксе.
В общем, если специальных задач не стоит, а ось предустановлена, то сносить её, имхо, чтоб изменить разрадность незачем.
В общем, если специальных задач не стоит, а ось предустановлена, то сносить её, имхо, чтоб изменить разрадность незачем.
Ну, ради разрядности наверное не стоит, но для добавление оперативной памяти… Ну и даже, если брать аспект безопасности судя по документации:
Kernel Patch Protection: Frequently Asked Question
«Kernel patch protection in the x64-based versions of Microsoft Windows Server 2003 SP1, Microsoft Windows XP, and later versions of Microsoft Windows for x64-based systems protects code and critical structures in the Windows kernel from modification by unknown code or data. This paper answers frequently asked questions about kernel patch protection in Windows.»
Ну, и «DEP is “always on” for 64bit processes on 64bit versions of Windows and it cannot be disabled. „
Kernel Patch Protection: Frequently Asked Question
«Kernel patch protection in the x64-based versions of Microsoft Windows Server 2003 SP1, Microsoft Windows XP, and later versions of Microsoft Windows for x64-based systems protects code and critical structures in the Windows kernel from modification by unknown code or data. This paper answers frequently asked questions about kernel patch protection in Windows.»
Ну, и «DEP is “always on” for 64bit processes on 64bit versions of Windows and it cannot be disabled. „
Другой вопрос, что 32 битная версия работает значительно медленнее, с PS CS5 это так.
«если специальных задач не стоит» — фотошоп это всё таки профессиональный софт.
У меня складывается впечатление, что 99.9% населения пользуются компьютерами для двух строчек в блокноте, поиграть в игрушки и посидеть вконтактике, а вечером глянуть порно.
Да, я профессионал и у меня досататочно много профессионального софта. В том числе и собственной разработки имеется. Но я лично знаю немало людей, не относящихся к ИТ профессионалам, или профессионалам другой специфики, использующих тяжелый софт, которые ставят х64 винду и получают стабильную и быструю систему.
Смысл в том, что я пока не провел собственные замеры, не думал, что и 32битный софт при условии многозадачности работает под x64 зачастую стабильнее и быстрее. Удивительно, но факт. Речь, конечно, о корректно написанном софте.
Да, я профессионал и у меня досататочно много профессионального софта. В том числе и собственной разработки имеется. Но я лично знаю немало людей, не относящихся к ИТ профессионалам, или профессионалам другой специфики, использующих тяжелый софт, которые ставят х64 винду и получают стабильную и быструю систему.
Смысл в том, что я пока не провел собственные замеры, не думал, что и 32битный софт при условии многозадачности работает под x64 зачастую стабильнее и быстрее. Удивительно, но факт. Речь, конечно, о корректно написанном софте.
У меня такое же впечатление, плюс ещё игры. А многозадачность как таковая им и не нужна, раньше хоть для плеера нужна была, а теперь и музыка вконтакте есть.
Субъективно я этого не заметил после перехода на 64-бит. glxgears тоже не заметил )
Субъективно я этого не заметил после перехода на 64-бит. glxgears тоже не заметил )
я не субеъктивно, я с секундомером померял — у меня стояла Windows Server 2003, когда готовился переходить на Win7 поставил сначала 32 битную, протестировал свой софт, потом 64 битную, те же тесты провел. Убедился, что быстрее, или как минимум не медленнее все, что мне нужно работает, остановился на 64 битной.
Медленнее оно и не должно быть. :) Быстрее — маловероятно. Я именно про 32хбитный софт.
на Itanium было медленнее, из-за эмуляции x86. Если бы в винде были накладные расходы для 32битных процессов, могло бы быть медленнее.
DDR3 4gb сейчас стоит 500р. Имеет ли смысл ставить в новый комп меньшее количество и 32х-битную систему? Или имеет ли смысл ставить 4гб+ и терять часть ее из-за 32х-битности? Таки выходит что никуда обычному пользователю от 64 не деться.
Многие покупают компы готовые или берут до 4-х гигов (включительно). Вот, например, первый попавшийся из активно рекламирующегося в Питере магазина www.ric.spb.ru/shop/catalog/tovar_detail.php?code=83662 — 2 гига. Я затрудняюсь сказать, имеет ли смысл ставить на него 64-бит. По моим наблюдениям за последний месяц, как я поставил 64 бит, даже серфить там будет некомфортно, а он позиционируется как игровой. У меня сейчас только хром (вместе с флешем) жрет 2 гига.
Ну как же… DOS 6.22, Prince of Persia…
Чем не игровая машина?
Чем не игровая машина?
Не уверен, что DOS 6.22 на нем запустится без бубна. Где-то начиная то ли со старших (в смысле поновее) 4-х пней, то ли с SATA винтов, то ли просто с больших винтоы у DOS'а (а также вин95/98/Me) проблемы наблюдались. FreeDOS поумнее в этом отношении.
Никто не запрещает запустить с дискеты. :)
Комп продается с линуксом, а это уже сосем игровая машина получается. Увлекательное времяпрепровождение гарантировано.
По поводу памяти:
— Сколько занимает винда?
— Сколько находит — столько и занимает.
Комп продается с линуксом, а это уже сосем игровая машина получается. Увлекательное времяпрепровождение гарантировано.
По поводу памяти:
— Сколько занимает винда?
— Сколько находит — столько и занимает.
Вот именно с дискеты (тогда они еще не вымерли) и не запускалось.
Не знаю… Только что запустил 6.22 с дискеты (точнее — с виртуального FDD, эмулированного боксом Zalman VE 200)
dl.dropbox.com/u/3894209/DSC_0111.JPG
Машинка, сами понимаете, современная — на Core i7.
dl.dropbox.com/u/3894209/DSC_0111.JPG
Машинка, сами понимаете, современная — на Core i7.
2 гига для 64-битной мало. Убедился на своем опыте.
Работаю в vis studio. Открыто много всего — браузеры, sql-manager, скайп, icq, почта, photoshop… Занято 3гб. Всего 4гб.
Ну и зачем больше 4-ёх?
Ну и зачем больше 4-ёх?
По работе очень часто открыто до 3-х студий, фотошоп, браузер, второстепенные программы, исполняются скрипты, и все одновременно. И если например мне захочется поиграть, я просто запускаю игру не закрывая все это. На 12 гигах оперативы все летает. Сомневаюсь что для того же хватит <=4Gb.
А еще если пара виртуалок по 4Гб каждая… В некоторых ситуациях и так приходится извращаться.
Батлфилд 3 с виндой и браузером кушают как за здрасте 4 гига ровно. Сворачивать игру чтобы покопаться в браузере уже нельзя. А вовремя смены карт приятно ютуб посмотреть и инет почитать — чего на 4х гигах уже не сделаешь.
А другу, например, и 8 гигов было мало для фотошопа.
А другу, например, и 8 гигов было мало для фотошопа.
Скорость игры зависит в первую очередь от загрузки процессора. Давеча ставил батл 3-ий, так проц под 100% был занят. Если в фоне такое кол-во прог запущено как у вас, и не дай бог тормознутый флеш баннер в браузере — никак вы не поигретесь даже со 100Гб памяти. Память она только для хранения, а все операции по данными в памяти проходят через процессор. И чем больше эти объемы тем медленнее будет работать система в целом.
Если поставить больше памяти — будет и занято больше. На ноуте 4 гига, на настольной — 8. Одни и те же задачи потребляют разное количество памяти в абсолютном значении. Винда в свободном полете: на ноутбуке ест около гектара, на настольной — полтора, а то и больше.
Тем более что 32-юитный софт отлично себе работает.
Если человек сам не разбирается то пользуясь слухами может поставить все, что угодно.
На деле Win7x64 для многих приложений работает занчительно эффективнее чем Win7x32. В частности это касается Photoshop (для меня важно), MS Expression Media 2 и пр.
На деле Win7x64 для многих приложений работает занчительно эффективнее чем Win7x32. В частности это касается Photoshop (для меня важно), MS Expression Media 2 и пр.
В моём окружении всё наоборот — 64 в два раза больше 32х, значит лучше.
x64 стоит у всех, у кого 4Гб памяти и более. А это вообще не редкость нынче.
В народ потихоньку идет с новыми компьютерами, но именно стоит пока все же больше 32хбитных ОС, чем 64хбитных.
Смотря кого считать. Если офисные компы — безусловно да. А вот статистика того же стима показывает, что самая популярная у геймеров (условно) ось — Windows 7 64 bit, стоящая у 42.21% (и доля растет).
Доля геймеров не так уж и велика, относительно общего числа компьютеров. Офисных больше. Но с тем, что 64 бита идет в народ и популярность растет — я не спорю. Достаточно глянуть количество ноутов, продаваемых с 64хбитными ОС и с 32хбитными.
Все-таки не стоит забывать, что стим скорее пристанище «хардкор» геймеров, чем школьников, которым родители на 1-е сентября купили б/у комп, который-то на момент выпуска 5 лет назад был бюджетным. Я согласен, что на мощное железо с мозгами от 4 Гб ставить 32-бит ось сейчас особого смысла нет. Но ещё пару лет назад были проблемы и у 64-бит осей с выполнением 32-бит приложений, и с разработкой 64-бит приложений (включая драйвера). Сейчас, видимо, и писать стали лучше, и оси более совместимые.
А каков смысл ставить 64, если памяти меньше 4 гиг?
64 версия винды, да и любое приложение, кушают больше памяти (почти в 2 раза) чем 32-битная версия.
В итоге, запуская свои любимые программы на 64 винде память будет расходоваться больше.
64 версия винды, да и любое приложение, кушают больше памяти (почти в 2 раза) чем 32-битная версия.
В итоге, запуская свои любимые программы на 64 винде память будет расходоваться больше.
Как я уже ответил выше (Мой комментарий), теоретически х64 безопаснее.
Хотя бы чтобы в будущем поставить 8 гигов и не обломаться. Уже есть не мало приложений и игр, коим мало 4-х гигов.
А еще не забывайте, что в Win 7 32 для одного приложения отведено лишь 2 гига памяти (что правда исправляется одной консольной командой).
А еще не забывайте, что в Win 7 32 для одного приложения отведено лишь 2 гига памяти (что правда исправляется одной консольной командой).
Одной командой исправляется только лимит. Чтобы приложение могло занимать больше 2х Гб оно еще должно быть слинковано с /LARGEADDRESSAWARE (это в студии). По умолчанию эта опция выключена. Да и не дает консольная комманда 4Гб в большинстве случаев (у меня на ноуте, например, 3 — потолок)
не знал про компиляцию с поддержкой этой фичи.
Просто для Battlefield 3 нужно было это значение включать, чтобы игра не вылетала.
Просто для Battlefield 3 нужно было это значение включать, чтобы игра не вылетала.
На 32битной системе /LARGEADDRESSAWARE дает 3 гига, на 64битной 32битным приложениям — 4.
Не работает! Вернее работает и ничего не вылетает :(
(Safari 5.0.5 @ Win 7 x64)
(Safari 5.0.5 @ Win 7 x64)
Вариант для тех кто спасовал, но ооочень интересно pix.am/HexU/
да, действительно словил:
Ушел в BSOD, Chrome 16, Win 7 x32 o_O
Попробовал — работает, качественный такой BSOD)
Safari 5.1.2, Windows 7 64-bit
Safari 5.1.2, Windows 7 64-bit
Видео bsod'а: youtu.be/Vf2mKyltOoM
Зашел через Safari под Mac OS X. Естественно, никакого BSoD, однако сам браузер подвис на несколько секунд :]
Под Бубунтой полет нормальный )))))
> web-страница [...] содержащая iframe и просматриваемая браузером Safari [...] подтверждена 64-битная версия Windows 7
ОМГ, 99% компьютеров под угрозой.
ОМГ, 99% компьютеров под угрозой.
не очень понятно как эту уязвимость можно эксплуатировать. Ведь там только цифры, как туда еще и впихнуть вредоносный код? парсер браузера же не пропустит.
Параллельно помимо этой статьи была открыта еще статья про хранение паролей в Chrome. Каково же было моё удивление по возвращению, как я думал, на эту статью, когда я увидел этот комментарий от 
skive!
skive!
Всегда было интересно как находят подобные уязвимости? А именно, почему 18082563, а не 18082564?
Спокойно.
Даня, ты просто прокручиваешь этот пост дальше.
Тебе завтра к 1й паре, а лаба по ТОЭ еще не досчитана.
Прокручиваешь, я сказа…
Даня, ты просто прокручиваешь этот пост дальше.
Тебе завтра к 1й паре, а лаба по ТОЭ еще не досчитана.
Прокручиваешь, я сказа…
>и позволяет злоумышленнику выполнить произвольный код на атакуемой системе
Об исполнении какого именно кода идет речь?
Об исполнении какого именно кода идет речь?
В данном конкретном случае — вымышленного. За уши притянуты все грехи win32k.sys. Об адекватности автора всё ясно говорит слово «компроментация» в заголовке и общеапокалиптичное настроение всей новости.
Ага, особенно учитывая, что DoSится в том числе и Safari on MacOSX. Но уязвимость все равно в Windows 7 x64 и ни в коем случае не в Safari.
Если бы Сафари падал в одиночку, про винду бы никто ни слова не сказал.
Ошибка в Safari может привести к краху системы. Существуют сотни и тысячи программ, способных из под администратора привести к краху системы — драйверы, программы криво работающие с оборудованием и т.д.. Теоретически программу, убивающую систему, можно сделать и в Linux, и в MacOs. Я случайно кривыми ручками делал кернел паник в линуксе под dingoo a320 (вернее не я а мои программы на си). Ошибку в коде можно совершить везде, просто тут ошибка серьёзнее, на низком уровне общения с графической системой.
не пишите, пожалуйста о том, в чем не разбираетесь, судя по этому комментарию и куче ваших комментариев ниже. Сафари, работающее от пользователя, вызывает крах системы — значит там есть код, который вызывает данный крах, по сути эксплуатирует уязвимость в операционной системе в некоторых условиях. Изучить эту уязвимость — и её можно найти в тысячах других программ под Windows и использовать для DoS'а системы или даже (возможно) выполнения произвольного кода. Разграничение прав на доступ к ресурсам — одна из задач операционной системы. Сафари в данном случае очень сбоку прилеплено, код в сафари может быть и даже скорее всего абсолютно правильный и корректный, но система обрабатывает его неправильно, что создает её уязвимость и вызывает крах.
злоумышленники могут выполнить джаваскрипт-код, которым показать перед синим экраном очень обидный alert
Интересно, как тот хакер этот прикол нашел? Вряд ли перебором всех возможных высот фрейма и проверкой во всех браузерах на всех системах… В сафари открытый код только у движка, но с хромом не валится. В памяти копался и закономерности искал? Вобщем, я в шоке.
Автор объясняет, почему так происходит:
> It's the NtGdiDrawStream which is being called multiple times...leading to a not so interesting crash.
> It's the NtGdiDrawStream which is being called multiple times...leading to a not so interesting crash.
Я бы перименовал заголовок в «Критическая уязвимость Safari: BSOD и компроментация системы»
способность приложения вызвать BSOD это не уязвимость Safari ниразу
Утверждаете, что невозможно написать кривое ПО, вызывающее BSOD?
возможно != должно быть возможно.
По идее ни одна софтина не должна быть в состоянии вызывать аварийный останов системы. Если она способна — в системе где-то уязвимость. Серьезная. Позволяющая, фактически DOS атаку.
Представьте, что подобные «ошибки» есть в нескольких софтинах, включая системы виртуализации. А потом Вяся Пупкин тыкает по ссылочке с хабра на виртуальном десктопе в облаке Amazon вырубая все облако. Вы и тогда скажете, что это проблема Safari?
По идее ни одна софтина не должна быть в состоянии вызывать аварийный останов системы. Если она способна — в системе где-то уязвимость. Серьезная. Позволяющая, фактически DOS атаку.
Представьте, что подобные «ошибки» есть в нескольких софтинах, включая системы виртуализации. А потом Вяся Пупкин тыкает по ссылочке с хабра на виртуальном десктопе в облаке Amazon вырубая все облако. Вы и тогда скажете, что это проблема Safari?
DoS-атака (от англ. Denial of Service, отказ в обслуживании) — атака на компьютерную систему с целью довести её до отказа, то есть, до такого состояния, что правомочные пользователи системы не могут получить доступ к предоставляемым системой ресурсам (серверам, сервисам), либо этот доступ затруднён.
Под MacOS этот доступ затруднён — DOS налицо. При чём тут Windows?
Как я уже говорил, существуют фрагменты кода, способные вызвать BSOD под Windows, и cernel panic под Linux. Если этот фрагмент кода поместить в код Safari — ничего не изменится — ПО будет вызывать ошибки. Это не проблема операционной системы.
Представьте, что Вяся Пупкин запуслил несколько вирусов, напрямую, двойным кликомпо файлам, в облаке Amazin. Его виртуальный комп повис и перезагрузился. Это опять не ошибка системы, её попросил так сделать машинный код.
Под MacOS этот доступ затруднён — DOS налицо. При чём тут Windows?
Как я уже говорил, существуют фрагменты кода, способные вызвать BSOD под Windows, и cernel panic под Linux. Если этот фрагмент кода поместить в код Safari — ничего не изменится — ПО будет вызывать ошибки. Это не проблема операционной системы.
Представьте, что Вяся Пупкин запуслил несколько вирусов, напрямую, двойным кликомпо файлам, в облаке Amazin. Его виртуальный комп повис и перезагрузился. Это опять не ошибка системы, её попросил так сделать машинный код.
Если падает браузер — проблема в браузере. Если падает система — проблема в системе.
Если в ПО есть код, роняющий систему (а такой код, повторюсь в третий раз, написать возможно под любой системой), это проблема кода, вернее проблема наличия такого кода именно в ПО.
Это подтверждает действие такого кода под MacOS.
Это подтверждает действие такого кода под MacOS.
У меня под OS X всё работает, память не жрёт.
Если код, запущенный с привилегиями обычного пользователя способен уронить систему (BSOD, kernel panic и т.п.), это проблема системы. Теоретическую возможность написания такого кода конечно никто не отрицает. Но любой подобный опубликованный код всегда вызывает внимание разработчиков ОС. И если проблема не в каком-нибудь криво написанном драйвере сторонних разработчиков, а именно в ОС, то как правило появляется исправление.
Причем здесь MacOS?
Имеем Windows с Safari. Заведя пользователя на специально сформированную страницу вызываем отказ системы (BSOD Windows).
Натуральная DoS.
Не должно существовать фрагметов кода, вызывающих BSoD под win или panic под линем.
Если бы непривелигированный пользователь под линуксом мог вызывать panic всей системы, миллионы школьников уже валили бы большу часть шаред хостинга не использующего виртуализацию.
Имеем Windows с Safari. Заведя пользователя на специально сформированную страницу вызываем отказ системы (BSOD Windows).
Натуральная DoS.
Не должно существовать фрагметов кода, вызывающих BSoD под win или panic под линем.
Если бы непривелигированный пользователь под линуксом мог вызывать panic всей системы, миллионы школьников уже валили бы большу часть шаред хостинга не использующего виртуализацию.
MacOS при том, что она тоже подвержена той же уязвимости, просто результат немного отличается.
MacOS не подверженна данной уязвмиости. Я только что спокойно открыл в Safari приведенную выше ссылку и спокойно закрыл Safari. Да safari страл жрать ресурсы, однако система (и другие пользователи системы) продолжили работу.
Watchdog'и используемые на многопользовательских системах быстро прибили бы такой процесс.
Поведение Win отличается в корне — полный крах.
Watchdog'и используемые на многопользовательских системах быстро прибили бы такой процесс.
Поведение Win отличается в корне — полный крах.
Ваша MacOS не подвержена. Моя Windows тоже. Я тоже открыл в Safari страницу и спокойно её закрыл. О чём тут вообще может быть речь?
Т.е. по вашему если падает MacOS — то она подверженна уязвимости. А если Windows, то это «Критическая уязвимость Safari»?
О неееет конечно. Это именно по Вашему — я про уязвимость систем молчу. Я говорю про браузер. Я то понимаю, что если ошибка проявляется под двумя системами — это ошибка ПО.
Однако такие фрагменты кода существуют. Сабж — тому доказательство. Если нет возможности общаться с оборудованием на низком уровне, драйверы просто не будут работать. А такое общение подразумевает возможность устроить BSOD основанный на ошибку в железе.
rundll32 user,disableoemlayer разумеется тоже уязвимость (ибо возможно, более того, должно быть возможно, оставлено нарочно).
Программы всегда могут крашить то, к чему имеют доступ. Едва ли вы согласитесь использовать браузер, который будет тормозить, из-за того что работает в какой-то виртмашине или написан на .NET или JAVA (что по сути обозначает то же самое.
Внося дополнительную прослойку мы всегда тормозим процесс и тут приходится находить баланс между безопасностью и скоростью и удобством работы.
А так, давайте запретим выполнение всех программ написаны на ассемблере(драйвера и прочее) ведь им ещё проще закрашить систему.
По мне так правильнее аккуратнее тестировать код. особенно когда сбоит не на одной системе, как сказано выше
Внося дополнительную прослойку мы всегда тормозим процесс и тут приходится находить баланс между безопасностью и скоростью и удобством работы.
А так, давайте запретим выполнение всех программ написаны на ассемблере(драйвера и прочее) ведь им ещё проще закрашить систему.
По мне так правильнее аккуратнее тестировать код. особенно когда сбоит не на одной системе, как сказано выше
Вы сейчас заете способы закрашить аутаульный RHEL6 из юзерспейса, если я дам вам доступ?
Я не хакер и даже не рядом. но у меня есть большое подозрение, что закрашить юзерспейс или по крайней мере гуйню подвесить там можно. Я так понимаю там есть какой-то супервизор, который это незаметно для вас отработает(должен отработать) и все будет ок. Но вот не всегда есть супервизор, к сожалению. И не всегда разумно его туда вклинивать.
А если вы его вклинили и дали сторонним разработчикам до него доступ, не удивляйтесь, если они этот супервизор уронят
А если вы его вклинили и дали сторонним разработчикам до него доступ, не удивляйтесь, если они этот супервизор уронят
Даже между закрашить юзерспейс одного пользователя и закрашить всю систему — это большая разница.
Еще раз, представьте себе, сайтами которые лежат на шаред хостингах (а там их большая часть) в которых любой школьник мог бы закрашаить всю систему?
Или это был-бы отличный метод DOS атаки, купил хостинг на том-же сервере и кильнул систему. ахахаха.
Еще раз, представьте себе, сайтами которые лежат на шаред хостингах (а там их большая часть) в которых любой школьник мог бы закрашаить всю систему?
Или это был-бы отличный метод DOS атаки, купил хостинг на том-же сервере и кильнул систему. ахахаха.
весь вопрос, до куда вы разрешили дотянутся конкретной проге.
А у вас на shared hosting под RHEL пользователи запускают в своих окружениях Safari? Если нет то тогда к чему вы этот пример привели?
А локальных и удаленных DOS атак и эскалаций привилегий вплоть до root можно и для RHEL найти пачку. Например вот такой
Red Hat has updated libxfont (privilege escalation). lwn.net/Articles/472847/
bugzilla.redhat.com/show_bug.cgi?id=555658
bugzilla.redhat.com/show_bug.cgi?id=754398
Перед написанием комментариев крайне рекомендуется изучать Red Hat Bugzilla тогда иллизии в неуязвимости любой версии любого ПО от RedHat отпадут сами собой.
А локальных и удаленных DOS атак и эскалаций привилегий вплоть до root можно и для RHEL найти пачку. Например вот такой
Red Hat has updated libxfont (privilege escalation). lwn.net/Articles/472847/
bugzilla.redhat.com/show_bug.cgi?id=555658
bugzilla.redhat.com/show_bug.cgi?id=754398
Перед написанием комментариев крайне рекомендуется изучать Red Hat Bugzilla тогда иллизии в неуязвимости любой версии любого ПО от RedHat отпадут сами собой.
Если есть кусок кода, вызывающий DoS, какая разница из какой аппликухи оно вызвано?
Ваши ссылки это ответ на вопрос: «Вы сейчас заете способы закрашить аутаульный RHEL6 из юзерспейса»?
Ключевое слово — актуальный.
RHEL приведен в качестве примера организации, затыкающей дырки быстрее, чем новость о них постят на хабре и школьники начинают веселуху.
Ваши ссылки это ответ на вопрос: «Вы сейчас заете способы закрашить аутаульный RHEL6 из юзерспейса»?
Ключевое слово — актуальный.
RHEL приведен в качестве примера организации, затыкающей дырки быстрее, чем новость о них постят на хабре и школьники начинают веселуху.
Исполнение кода в режиме ядра — баг Safari? У тебя неправильные приоритеты. Safari может быть вообще не причем в этой ситуации, хотя это не факт конечно, я особо не разбирался.
Резюмируя: Safari пытается вывести на экран невозможное, а дальше уже зависит от ОС. Как писали выше: OS X тормозит, а Win 7 x64 падает. Виноваты все!
Мне интересно, как находят такие дыры? Неужели просто случайность?
Сразу вспомнилось как в своё время можно было вызвать BSoD в Win98 атрибутом bg со значением con\con :)
а теперь интересно как скоро будет патч от мелкософта? ))
так то проверил, мне сокрушил систему данный фрейм…
так то проверил, мне сокрушил систему данный фрейм…
И всё таки мне кажется, что патч будет и от Apple, и в первую очередь. Иначе под макосями так и будет память жрать.
только что проверял — не жрет ничего
Мда. Как бы так объяснить уже в третий раз.
У меня под Windows тоже ничего не происходит, однако это не отменяет того, что некоторые связки MacOS+Safari+64 битное железо подвержены этому эффекту.
У всех Макоси разные, и сафари разные, у некоторых процессор 32х битный. Понятно, что не у всех воспроизведётся. Я понимаю, у многих маков железо схожее, и системы похожие, но версии то ПО разные. Если у Вас не воспроизводится — не значит, что проблемы как таковой нет.
У меня под Windows тоже ничего не происходит, однако это не отменяет того, что некоторые связки MacOS+Safari+64 битное железо подвержены этому эффекту.
У всех Макоси разные, и сафари разные, у некоторых процессор 32х битный. Понятно, что не у всех воспроизведётся. Я понимаю, у многих маков железо схожее, и системы похожие, но версии то ПО разные. Если у Вас не воспроизводится — не значит, что проблемы как таковой нет.
Подвержены атаке только версии Сафари с 5.1. На 5.0 не воспроизводиться.
Это все Сафари виноват, а Винда и так дырявая.
Неужели никто не сказал ещё этого слова?
Ладно, в комментариях, но в заголовке и тегах писать «x64» вместо x86-64 — это, мягко говоря, странно. Скажите, вы ведь думаете, что x86 — это восьмидесятишестибитная архитектура, да? %)
Интересно, вот тут в комментах много пишут что опасность вымышленная и маловероятная, так как необходим Сафари.
А кто может гарантировать что эту ошибку нельзя повторить с помощью какой то другой программы — ведь действительно проблема где-то в ОС, раз какой-то особенный код сафари может закрешить.
Просто на Сафари было легче всего найти, где еще… кто знает.
Плохо что патча пока нет.
А кто может гарантировать что эту ошибку нельзя повторить с помощью какой то другой программы — ведь действительно проблема где-то в ОС, раз какой-то особенный код сафари может закрешить.
Просто на Сафари было легче всего найти, где еще… кто знает.
Плохо что патча пока нет.
Попробовал. Работает! :)
В винде есть извесная проблема с GDI, каждая система имеет лимит примерно 15000 GDI объектов, при их исчерпании виндовз не сможет даже message box показать. Я так подозреваю проблема как раз этого плана. Простого решения эта проблема не имеет, потому что даже в Linux єсть ограничения на количество сокетов, открытых файлов.
єсть ограничения на количество сокетов, открытых файлов.
установленное как дефайн в исходном коде, который всем доступен
установленное как дефайн в исходном коде, который всем доступен
Есть общий лимит на систему, и есть лимит на приложение. Исчерпания лимита файловых дескрипторов для одного приложения не означает исчерпание файловых дескрипторов для всей системы.
Зачем искать какого-то конкретного пользователя? Если уязвимостью научаться пользоваться, то добавят в паки скриптов и все… будут «перебираться» скрипты, пока не пробьется какая-то уязвимость.
Меня всегда веселило, когда люди, которые мало понимают в эксплуатации уязвимостей ядра NT — пишут такие посты.
BSOD != Arbitrary Code Execution
стабильный rce exploit врядли кто-то выложит в паблик, так как достаточно сложно написать стабильный эксплоит, но возможно.
Уязвимость связана с системным вызовов NtGdiDrawStream — который используется Safari.
И для справки, уязвимость старая, proof:https://bugzilla.mozilla.org/show_bug.cgi?id=320430
BSOD != Arbitrary Code Execution
стабильный rce exploit врядли кто-то выложит в паблик, так как достаточно сложно написать стабильный эксплоит, но возможно.
Уязвимость связана с системным вызовов NtGdiDrawStream — который используется Safari.
И для справки, уязвимость старая, proof:https://bugzilla.mozilla.org/show_bug.cgi?id=320430
Хотел было сказать что виндовс как всегда на высоте, но тут и криворукость эппл сыграла. Но одно дело браузер, а другое операционка. К сожалению менеджмент Балмера крут и люди вынуждены в большинстве своём терпеть эту пакОСь.
А вот и детальный анализ от Alex Ionescu:
The bug happens due to a NineGrid request coming through GdiDrawStream sent on behalf of the UX Theme DLL which handles Windows Themes starting in XP and later.
Webkit browsers (along with IE8 — but not IE9, it would seem) attempt to render HTML elements on the page using the native skin of the OS. In this case, in the drawControl function (see www.opensource.apple.com/source/WebCore/WebCore-658.28/rendering/RenderThemeWin.cpp), DrawThemeBackground is called, which handles skinning of OS controls.
A 96 (0x60) byte buffer is sent (parameter 2 and 3 of GdiDrawStream are the size and buffer address, parameter 1 is the HDC).
Draw Steam buffers begin with a magic value, followed by a series of commands identified by a 32-byte market. Here is the stream sent with the special iframe when viewed in Safari:
44727753 = 'DrwS' = DrawStream Magic
Command Buffers:
#0: 00000000 3b01017a // Destination DC (hdc) *** Must match HDC in GdiDrawStream argument 1 ***
// Destination Clip (ERECTL):
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom *** Multiply by 2, and you get the «magic» value used in the iframe PoC ***
#1: 00000001 058506a3 // Source Surface (pso) *** Dumped the surface from kernel mode, got a 13x5 32BPP bitmap which is the Luna/Aero scrollbar slider control ***
#2: 00000009 // Destination Clip (ERECTL): *** Should match the Destination Clip of the Target
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom
// Source Clip (ERECTL): *** Should be within the bounds of the surface (which is 13x5 in this case)
00000000 // Left
00000000 // Top
0000000e // Right
00000001 // Bottom
// NINEGRID_BITMAP_INFO *** Documented in RDP docs. Should fit within the surface and destination.
00000001 // Flags (DSDNG_STRETCH)
0000000a // Left Width
00000003 // Right Width
00000000 // Top Height
00000000 // Bottom Height
00000000 // Transparent
Here is the raw dump:
0: kd> dds @r8 l18
00000000`003be664 44727753
00000000`003be668 00000000
00000000`003be66c 2b0108d5 // HDC, this will change from dump to dump
00000000`003be670 0000011b
00000000`003be674 00000011
00000000`003be678 0000012c
00000000`003be67c 0089f580
00000000`003be680 00000001
00000000`003be684 018503c2 // Bitmap Surface, this will change from dump to dump
00000000`003be688 00000009
00000000`003be68c 0000011b
00000000`003be690 00000011
00000000`003be694 0000012c
00000000`003be698 0089f580
00000000`003be69c 00000000
00000000`003be6a0 00000000
00000000`003be6a4 0000000e
00000000`003be6a8 00000001
00000000`003be6ac 00000001
00000000`003be6b0 0000000a
00000000`003be6b4 00000003
00000000`003be6b8 00000000
00000000`003be6bc 00000000
00000000`003be6c0 00000000
What are you essentially seeing is an iframe that has a particularly interesting height, that when the scrollbar is being drawn and themed, a math error in the NineGrid transform causes an out-of-bounds write. This PoC would work in IE 8, but IE 8 has a well known CSS bug where it has a maximum pixel limit (around 1342177), which is why it doesn't immediately manifest itself.
*OTHER HEIGHTS ARE EXPLOITABLE*, and some may be small enough such that even IE 8 hits the NineGrid height corner case.
IE9 does not seem to theme controls using UxTheme at all, and its scrollbar behavior is different from IE 8, so even though the pixel limit is no longer there, the PoC did not work. Firefox was not tested.
*NOT ONLY IFRAMES ARE VULNERABLE*. Testing with an HTML of the same height resulted in a crash in Safari as well.
What this means is that *any* client, local or remote, that does skinning of the controls (i.e.: almost all of them — even a button on a flash PDF) could result in a NineGrid transform that hits this bug. It's not at all specific to WebKit.
The bug happens due to a NineGrid request coming through GdiDrawStream sent on behalf of the UX Theme DLL which handles Windows Themes starting in XP and later.
Webkit browsers (along with IE8 — but not IE9, it would seem) attempt to render HTML elements on the page using the native skin of the OS. In this case, in the drawControl function (see www.opensource.apple.com/source/WebCore/WebCore-658.28/rendering/RenderThemeWin.cpp), DrawThemeBackground is called, which handles skinning of OS controls.
A 96 (0x60) byte buffer is sent (parameter 2 and 3 of GdiDrawStream are the size and buffer address, parameter 1 is the HDC).
Draw Steam buffers begin with a magic value, followed by a series of commands identified by a 32-byte market. Here is the stream sent with the special iframe when viewed in Safari:
44727753 = 'DrwS' = DrawStream Magic
Command Buffers:
#0: 00000000 3b01017a // Destination DC (hdc) *** Must match HDC in GdiDrawStream argument 1 ***
// Destination Clip (ERECTL):
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom *** Multiply by 2, and you get the «magic» value used in the iframe PoC ***
#1: 00000001 058506a3 // Source Surface (pso) *** Dumped the surface from kernel mode, got a 13x5 32BPP bitmap which is the Luna/Aero scrollbar slider control ***
#2: 00000009 // Destination Clip (ERECTL): *** Should match the Destination Clip of the Target
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom
// Source Clip (ERECTL): *** Should be within the bounds of the surface (which is 13x5 in this case)
00000000 // Left
00000000 // Top
0000000e // Right
00000001 // Bottom
// NINEGRID_BITMAP_INFO *** Documented in RDP docs. Should fit within the surface and destination.
00000001 // Flags (DSDNG_STRETCH)
0000000a // Left Width
00000003 // Right Width
00000000 // Top Height
00000000 // Bottom Height
00000000 // Transparent
Here is the raw dump:
0: kd> dds @r8 l18
00000000`003be664 44727753
00000000`003be668 00000000
00000000`003be66c 2b0108d5 // HDC, this will change from dump to dump
00000000`003be670 0000011b
00000000`003be674 00000011
00000000`003be678 0000012c
00000000`003be67c 0089f580
00000000`003be680 00000001
00000000`003be684 018503c2 // Bitmap Surface, this will change from dump to dump
00000000`003be688 00000009
00000000`003be68c 0000011b
00000000`003be690 00000011
00000000`003be694 0000012c
00000000`003be698 0089f580
00000000`003be69c 00000000
00000000`003be6a0 00000000
00000000`003be6a4 0000000e
00000000`003be6a8 00000001
00000000`003be6ac 00000001
00000000`003be6b0 0000000a
00000000`003be6b4 00000003
00000000`003be6b8 00000000
00000000`003be6bc 00000000
00000000`003be6c0 00000000
What are you essentially seeing is an iframe that has a particularly interesting height, that when the scrollbar is being drawn and themed, a math error in the NineGrid transform causes an out-of-bounds write. This PoC would work in IE 8, but IE 8 has a well known CSS bug where it has a maximum pixel limit (around 1342177), which is why it doesn't immediately manifest itself.
*OTHER HEIGHTS ARE EXPLOITABLE*, and some may be small enough such that even IE 8 hits the NineGrid height corner case.
IE9 does not seem to theme controls using UxTheme at all, and its scrollbar behavior is different from IE 8, so even though the pixel limit is no longer there, the PoC did not work. Firefox was not tested.
*NOT ONLY IFRAMES ARE VULNERABLE*. Testing with an HTML of the same height resulted in a crash in Safari as well.
What this means is that *any* client, local or remote, that does skinning of the controls (i.e.: almost all of them — even a button on a flash PDF) could result in a NineGrid transform that hits this bug. It's not at all specific to WebKit.
Привет из восьмёрочки. (Курсор остался, но двигать им нельзя.)
Sign up to leave a comment.
Критическая уязвимость Windows 7 x64: BSOD и компрометация системы