В развиваемом проектом QEMU модуле VGA, эмулирующем работу простого графического адаптера, выявлена (https://access.redhat.com/blogs/766093/posts/2309211) уязвимость (CVE-2016-3710 (https://security-tracker.debian.org/tracker/CVE-2016-3710)), потенциально позволяющая осуществить из гостевой системы атаку, которая приведёт к выполнению кода на стороне хост-системы с правами процесса-обработчика QEMU (обычно root, а при запуске в режиме stubdomain (qemu-dm) под отдельным непривилегированным пользователем). Уязвимость проявляется в Xen (http://openwall.com/lists/oss-security/2016/05/10/2) (в режиме HVM c указанной в настройках видеокартой "stdvga"), KVM (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-3710) (qemu-kvm) и других системах виртуализации, использующих компоненты QEMU.
Уязвимости присвоено кодовое имя "Dark Portal". Проблема обусловлена выходом за границы буфера из-за ошибки в реализации кода работы с портами ввода/вывода в режиме эмуляции VGA c поддержкой VESA BIOS Extensions (VBE). В частности, через запись в регистр VBE_DISPI_INDEX_BANK, хранящий смещение адреса текущего банка видеопамяти, возможно обращение к областям памяти, выходящим за границы буфера, так как предлагаемые банки видеопамяти адресуются с использованием типа "byte(uint8_t *)", а обрабатываются как тип "word(uint32_t *)".Исправление доступно в виде патча (https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg011...). Обновления пакетов с устранением уязвимости выпущены для RHEL 7 (https://rhn.redhat.com/errata/RHSA-2016-0724.html), CentOS 7 (https://lists.centos.org/pipermail/centos-announce/2016-May/...), Fedora (https://bodhi.fedoraproject.org/updates/?packages=qemu) и Debian (https://security-tracker.debian.org/tracker/DSA-3573-1) (обновление выпущено только для jessie, для wheezy исправления не будет). Оценить появление обновлений в других дистрибутивах можно на следующих страницах: Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...),
openSUSE (http://lists.opensuse.org/opensuse-security-announce/), SLES (https://www.suse.com/support/update/), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), Gentoo (http://www.gentoo.org/security/en/index.xml), FreeBSD (http://www.vuxml.org/freebsd/), NetBSD (http://www.netbsd.org/support/security/). В качестве обходного пути защиты в RHEL/CentOS предлагается использовать sVirt и seccomp для ограничения привилегий процесса QEMU. В качестве обходного пути защиты для пользователей Xen рекомендуется использовать виртуальную видеокарту "cirrus" (в настройках stdvga=0, vga="cirrus").
URL: http://openwall.com/lists/oss-security/2016/05/10/2
Новость: http://www.opennet.me/opennews/art.shtml?num=44409
>Проблема обусловлена выходом за границы буфераПросто поразительно, что люди умудряются делать с помощью такой, казалось бы, банальной вещи. Я сам сишник/плюсовик, но всегда воспринимал такие ошибки как потенциальный сегфолт, но не более того. Да и не я один такой "тупой". Буквально лет 5 назад по этой теме ничего не было слышно. А теперь чуть ли не каждая вторая уязвимость базируется на этом принципе.
Я до сих пор не понимаю в чём суть. Ну ок: записываем октетами, а считываем по 32 бита. Ладно -- у нас есть возможность впихнуть получателю этих данных 3 лишних байта. Звучит не страшно. Тем более, что эти данные -- видеобуфер. Блин, мистика какая-то...
Рискну предположить, что весь фокус в обработке исключения...
Не рискуйте так больше.
> Буквально лет 5 назад по этой теме ничего не было слышноТы издеваешься что-ли?
Ок, 10. Конкретный срок не важен...
> Ок, 10. Конкретный срок не важен...Ну тогда согласен, действительно, 100 лет назад о них никто не слышал.
>> Ок, 10. Конкретный срок не важен...
> Ну тогда согласен, действительно, 100 лет назад о них никто не слышал.16 лет назад вышла первая версия PAX https://en.wikipedia.org/wiki/PaX_%28Linux%29 защищающая GNU/Linux от атак переполнения буфера.
10 лет назад уже просветлённый народ во всю использовал Hardened Gentoo
Лет 10 назад на этой странице https://grsecurity.net/research.php были ссылки на статьи середины 90 помню там была статья уважаемой M$ о методах защиты от перепполнения буфера в вантузе. Вантуз NT-4.0 (1996г выпуска) имел средства защиты от переполнения буфера.
OpenBSD их имеет с самого начала.
Может другие Юникс (Trusted Solaris?) имели защиту от переполнения буфера ещё раньше.
толку что Microsoft их имел, стоит посмотреть сейчас в 2016 году статистику по уязвимостям - всё тоже самое как и 10 лет назад, сплошные переполнения буфера
Ага, и поэтому ты будешь писать всякую чушь
Угу. Десять. А тридцать не хотите?Переполнение буфера является самым распространённым классом уязвимостей, и причины его кроются в реализации работы со стеком и кучей конкретных языков. Существует и эксплуатируется с незапамятных времён. Тот же червь Морриса был основан именно на этой уязвимости, а он был написан в 1988м.
>работы со стеком и кучей конкретных языков.Скорее самим принципом организации памяти потока исполнения в процессорах.
Помнится мне civ на z80 вообще работала как самомодифицируемый код при обходе карты :)
> Помнится мне SIMCITY на z80 вообще работала как самомодифицируемый код при обходе
> карты :)не civ а simcity, перепутал.
>>работы со стеком и кучей конкретных языков.
> Скорее самим принципом организации памяти потока исполнения в процессорах.Переполнение буфера - фундаментальная проблема архитектуры х86 (фон Неймана), в отличие от Гарвардской архитектуры (Motorola 65000, PIC, Atmel AVR, Intel 8051). Главное отличие Гарвардской архитектуры - "хранилище инструкций и хранилище данных представляют собой разные физические устройства" (Wikipedia)
К сожалению прогресс процессоров пошел по пути единого хранилища кода и данных. Соответственно, уязвимости этого класса неизбежны.
> Соответственно, уязвимости этого класса неизбежны.Вовсе не неизбежны. Есть языки, в которых запись в буфер контроллируется, и если запись пытается выйти за его границы, выдаётся ошибка. Это сказывается на производительности, разумеется. Поэтому, ну к примеру, в Ocaml, эту возможность можно отключать для продакшена, но активно использовать при тестировании.
Хотя конечно, если бы Гарвардская архитектура стала популярной, это бы решило проблему на корню.
> Хотя конечно, если бы Гарвардская архитектура стала популярной, это бы решило проблему
> на корню.Все производители процов уже решили эту проблему,
некоторые изначально: alpha, avr32, ia64, parisc, sparc, sparc64
некоторые через ж: ppc, ppc64
и на конец x86_64, i386 добавили NX bit.Теперь задумайся ИСПОЛЬЗУЕТСЯ ЛИ NX инструкции проца ДЛЯ ПРЕДОТВРАЩЕНИЯ АТАК С ПЕРЕПОЛНЕНИЕМ БУФЕРА В ТВОЕЙ ОС???!!!
Если нет - меняй дилера!
> явном виде создавать области кода, данных ...CPU может посегментно метить память при выделении данные или код. Это чуть жрёт ресурсы и накладывает ограничения на объём памяти.
CPU c NX битом может постранично метить память при выделении - данные или код, причём без потери в производительности!
> Но все основные ОС создают 3 идентичные области,
Если твоя ОС не разделяет данные (RW) и код (RX) в памяти -- смени дилера.
> Соответственно, уязвимости этого класса неизбежны.Уже производители процов исправились и добавили NX бит, им можно метить страницы памяти в которых хранятся данные - запрет на исполнение. Причём БЕЗ ПОТЕРИ В ПРОИЗВОДИТЕЛЬНОСТИ!
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity...
Да, в Ынтерпрайз дистрибутивах ОС с САШ, NX бит не используется, соответственно, уязвимости этого класса неизбежны.
> Уже производители процов исправились и добавили NX бит, им можно метить страницы
> памяти в которых хранятся данные - запрет на исполнение. Причём БЕЗ
> ПОТЕРИ В ПРОИЗВОДИТЕЛЬНОСТИ!Интересно, как это Вас спасёт, если злоумышленник эксплуатирует переполнение буфера для возврата в libc? А никак! :)
> Интересно, как это Вас спасёт, если злоумышленник эксплуатирует переполнение буфера для
> возврата в libc? А никак! :)Для этого есть другая система - RAP!
Ну, этой штуке вообще всего 2 недели от роду.
Сначала посмотрим, как она проявит себя на практике.
> Интересно, как это Вас спасёт, если злоумышленник эксплуатирует переполнение буфера для
> возврата в libc? А никак! :)ASLR - рандомизация расположение библиотек внутри адресного пространства процессов делает атаку переполнение буфера при возврате в libc практически очень сложной.
Защита stack-smashing из GCC - ProPolice тоже затрудняет её.
Использование "Правильных процессоров" SPARC, MIPS хранящий адрес возврата из текущей функции на аппаратных регистрах - сильно затрудняет данный вид атаки.
PowerPC проц не хранит адрес возврата в том же стеке и не даёт к регистру доступ программисту - атака вообще не возможна.
Мой предыдущий ответ о RAP, хоть заминусован, но позволяет предотвратить большой ущерб - объединение нескольких атак данного вида в более сложную. RAP пока не разбирал и непробовал, при следующем обновлении протестирую.
Молодец, почитал русскую википедию, где как обычно написана чушь. Теперь попробуй применить мозг и найди как эксплуатировать переполнение буфера в гарвардской архитектуре. Дам подсказку: стек.
> Дам подсказку: стек.Перекомпиляй всё с поддержкой SSP только добавляй пацанячий флаг -fstack-protector-all
-fstack-protector-strong придумали в Google по закажу АНБ для развода лохов.
офигеть. и причем тут гарвардская архитектура тогда?
> Молодец, почитал русскую википедию, где как обычно написана чушь.Уважаемый, я с Гарвардской архитектурой работал с ассемблером еще на 6502. Ссылку на Википедию дал исключительно для вьюношей.
> Теперь попробуй применить
> мозг и найди как эксплуатировать переполнение буфера в гарвардской архитектуре. Дам
> подсказку: стек.Умерь свое ЧСВ и попробуй включить свой мозг. Подсказка: стек в 6502 аппаратный - просто набор регистров, значения из которых могут указывать только на память инструкций. Попробуй его переполнить, теоретик.
До седин дожил, ума не нажил.
и как ты на гарвардской подменишь/заполнишь адреса возврата в стеке которые не доступны для записи и не доступны для записи через переполнение ( если автор выше правильно описал архитектуру стека на вот той машинке) ?
> Переполнение буфера - фундаментальная проблема архитектуры х86 (фон Неймана), в отличие от Гарвардской архитектуры...Что за бред несёшь, наркоман. Точно такие же проблемы у Гарвардской архитектуры, только переполнения несколько иначе эксплуатируются и с чуточку большей трудоёмкостью.
> Ладно -- у нас есть возможность впихнуть получателю этих данных 3 лишних байта.Балбес, там проблема в адресной арифметике для типов разных размеров, выйти можно на N * 3 байт в адресном пр-ве. Шёл бы уроки делать.
Но ведь код, читающий и пишущий, обычно разнесены. Каким образом тут может накосячить адресная арифметика? Ты думаешь, что кто-то записал сотню байт, а потом пытается читать эту же сотню, но уже 32битных значений? Так ошибиться нелегко.
Или ты, убер-гросс-антибалбес-второкурсник, таки почитал код?
> Но ведь код, читающий и пишущий, обычно разнесены. Каким образом тут может накосячить адресная арифметика?Адресная арифметика позволяет записать куда-нибудь в другое место. А вот что это за другое место... Тут уж как повезёт. Зависит от многих факторов: как далеко за границы буфера можно вылезти, где этот буфер расположен -- в идеале если на стеке, если в куче то как правило сложнее записать данные полезным образом. Но сложнее -- не значит, что невозможно. Например, на жабаскрипте проворачивали такой финт ушами: забивали всю кучу многими копиями небольшого кусочка машинного кода, предварённого многими командами nop. Потом освобождали выделенную память. А потом использовали переполнение буфера, с тем чтобы совершить jmp на плюс-минус рандомный адрес в куче. С довольно высокой вероятностью переход совершался на какой-нибудь из однобайтовых nop'ов, которые процессор услужливо выполнял, добирался до вредоносного кода и выполнял его. Финита ля комедия.
И описание этого я читал в статье Касперски, это было лет десять назад и при всём при том, что статья содержала новые для меня идеи, ничего такого из ряда вон выходящего я в ней не видел. Карл, 10 лет назад! Это уже было рутиной, Карл!
>> Проблема обусловлена выходом за границы буфера
> Просто поразительно, что люди умудряются делать с помощью такой, казалось бы, банальной вещи.
> Я до сих пор не понимаю в чём суть.
> Блин, мистика какая-то...Чтобы понять, в чём суть, можете почитать Козиола "Искусство взлома и защиты систем". Этот класс уязвимостей очень подробно описывается буквально в первых главах.
>> Проблема обусловлена выходом за границы буфера
> Я сам сишник [...] Буквально лет 5 назад по этой теме ничего не было слышно.Шутить изволите? Гляньте архивы bugtraq@ из девяностых, будете сильно удивлены.
Запчем вы мечите бисер пред свиньями, разве не понятно что товарищ троллит.
Не очевидно, что троллит. Тут есть персонажи с альтернативным устройством головы. А ответ же полезен тем, что он публичный и его могут прочитать другие люди.
Что твоей ни в чём не повинной программулинкой могут воспользоваться злые дядьки дабы гадить в машинах юзеров - вот об этом 10 лет назад задумывались лишь единицы особо начитанных кодеров. Проблема-то была, но была мало кому нужна. А теперь это целый чёрный рынок.
> Что твоей ни в чём не повинной программулинкой могут воспользоваться злые дядьки
> дабы гадить в машинах юзеров - вот об этом 10 лет назад задумывались лишь единицы
> особо начитанных кодеров. Проблема-то была, но была мало кому нужна.
> А теперь это целый чёрный рынок.Вообще-то десять лет тому это был уже не просто чёрный рынок (эксплойтами торговали и раньше), а ответвление _организованной_ преступной деятельности, по моим наблюдениям.
А "единицы задумывались" не десять -- как минимум лет двадцать тому уже вполне. Дальше смотреть не берусь, т.к. знаю совсем лоскутно/опосредованно...
Ключевое слово в новости "потенциально". Просто сейчас security circus устраивает истерику вокруг любого переполнения буфера, а уж позволяет оно выполнить код или нет совершенно неважно.
Да, управляемые языки спасут от этой напасти.
Это обещают уже лет 15-20 - допилить яву, убрать утечки памяти, повысить производительность до сравнимой с нативной, ага-ага.Кстате, даже если выполнят обещания, то в новом прекрасном мире отрывается миллион других возможностей, типа атаки через подмену пакетов в репозитариях.
Вас, вендузоедов, ничего не спасёт.
> Уязвимости присвоено кодовое имяОбъясните мне, старпёру, в чём сакральный смысл давать уязвимостям красочные маркетинговые имена? Чтобы потом в описании писать «Не содержит Dark Portal и асбест»?
Вероятно это типовая уязвимость и так банально проще. Это как можно сказать Е500, а можно "пищевая сода". Далеко не каждый человек ассоциирует эти термины. А скажи "секвикарбонат натрия", так это и химика может заставить задуматься.
1. сеСквикарбонат натрия
2. сесквикарбонат натрия - это не пищевая сода
3. пищевая сода - это гидрокарбонат натрия (aka "натрий двууглекислый")
>> Уязвимости присвоено кодовое имя
> Объясните мне, старпёру, в чём сакральный смысл давать уязвимостям красочные маркетинговые
> имена? Чтобы потом в описании писать «Не содержит Dark Portal и
> асбест»?Новая мода, маркетолухи добрались до CVE. Дальше будет ещё хуже.
> Объясните мне, старпёру, в чём сакральный смысл давать уязвимостям красочные маркетинговые имена?До седин дожил, а... Объясняю: http://www.opennet.me/openforum/vsluhforumID3/105391.html#15
опять очередной высер запостил. Все уже и так поняли что ты в любую хрень веришь.
>очередной высер запостил
>в любую хрень веришь.Согласен, про твои седины погорячился, и про "старпёр" -- хрень. Бывает.
>качестве обходного пути защиты для пользователей Xen рекомендуется использовать виртуальную видеокарту "cirrus" (в настройках stdvga=0, vga="cirrus").есть лучше способ: не использовать видеокарту в виртуалке
> Debian (обновление выпущено только для jessie, для wheezy исправления не будет)вот такой хреновый lts до 2018 года, ребята
>> Debian (обновление выпущено только для jessie, для wheezy исправления не будет)
> вот такой хреновый lts до 2018 года, ребятаА откуда уверенность что не забэкпортят?
имхо, если уж LTS, то должно быть в стандартных пакетах, а не бэкпортах
> (обновление выпущено только для jessie, для wheezy исправления не будет).Кто там любил systemd? теперь видите, к чему приводит отход от Unix-way?
Если бы все писали на паскале-подобном языке, то проблем такого плана в принципе не существовало бы в индустрии IT. Но сишники любят вольности, а возможность стрелять себе под ноги считают основополагающим принципом свободы.
да нет, я заметил, если люди ручками не управляют памятью то они даже не знают для чего нужно очистка "мемори"
>для чего нужно очистка "мемори"...освобождение? //Всем Столмана читать!
Ну ведь осилили написать на C++ автоматический гарбидж-коллектор в JVM. Даже несколько видов - с разными стратегиями! А сами-то всё на указателях и смартпоинтерах сидят. "Сапожники без сапог" :))
> Даже несколько видовиногда пишешь даже свой, так что много этих менеджеров управления
Ну вот поэтому софт на плюсах, например, может вернуть неиспользуемую память системе... Для плюсов, чтобы ты знал, реализаций GC - масса. В той же мозилле используется, к примеру. Но в плюсовом мире как-то не принято считать, что одно решение годится для всех... впрочем, что тебе доказывать.
proxmox на форуме написали что у них падает windows в среде эмулияции после патчей, ппц.
Правильный патч. Многоцелевой.
А вы чего ожидали? Это всё, что они могут: написать на форуме и ждать пока кто-то компетентный починит.