The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

12.06.2012 21:18  Опасные уязвимости в Xen и FreeBSD, проявляющиеся на 64-разрядных CPU Intel

В гипервизоре Xen найдена критическая уязвимость позволяющая пользователю гостевой системы организовать выполнение кода на стороне управляющей хост-системы. Проблеме подвержены 64-разрядные хост-системы на базе процессоров Intel. Эксплуатация уязвимости возможна только из паравиртуализированных гостевых систем, базирующихся на 64-разрядном ядре. После успешной эксплуатации привилегированный пользователь гостевой системы, а в некоторых конфигурациях и непривилегированный пользователь гостевой ОС, может получить контроль над хост-системой. Проблема связана с возможностью создания условий для генерации исключения в неподходящем состоянии процессора в процессе возврата из системного вызова (SYSRET).

Системы с процессорами AMD вышеотмеченной уязвимости не подвержены, тем не менее, системы с некоторыми старыми моделями 64-разрядных CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка в микрокоде, могут быть использованы для инициирования отказа в обслуживании (блокирование работы хост-системы). Кроме того, в Xen устранена ещё одна уязвимость, дающая возможность пользователю 32- или 64-разрядной паравиртуализированной гостевой системы инициировать крах данного гостевого окружения.

Исправления для всех трёх упомянутых уязвимостей пока доступны в виде патчей. Проследить за выходом обновлений популярных дистрибутивов можно на данных страницах: Ubuntu, Mandriva, Gentoo, openSUSE, CentOS, Scientific Linux, Fedora, RHEL и Debian.

Во всех поддерживаемых версиях FreeBSD устранена идентичная по своей сути уязвимость, позволяющая локальному пользователю выполнить свой код с привилегиями ядра системы. Проблема проявляется только в сборке FreeBSD/amd64 на 64-разрядных процессорах Intel. FreeBSD/amd64 на системах с процессорами AMD, 32-разрядная сборка FreeBSD/i386, а также сборки FreeBSD для других процессорных архитектур уязвимости не подвержены.

Одновременно выпущено уведомление об исправлении уязвимости во входящем в базовую поставку FreeBSD DNS-сервере BIND. Проблема проявляется при обработке полей rdata нулевой длины и выражается в крахе процесса или утечке областей памяти сервера. Кроме того, сообщается об устранении серьёзной ошибки в IPv6-стеке FreeBSD, которая может привести к краху ядра при большой сетевой нагрузке. Стек IPv4 данной проблеме не подвержен.

  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: freebsd, security, ipv6, amd64, xen
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 22:29, 12/06/2012 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS
     
     
  • 2.7, Аноним (-), 01:48, 13/06/2012 [^] [ответить]    [к модератору]
  • +1 +/
    > жаль нет эксплоита готового, поэкспериментировал бы на Amazon AWS

    Сплойт может скоро появиться, а амазон вряд ли оперативно дыру прикроет.

     
  • 1.2, Аноним (-), 22:53, 12/06/2012 [ответить] [показать ветку] [···]    [к модератору]
  • –3 +/
    > которая может привести к краху ядра при большой сетевой нагрузке.

    Greetings going to Netflix </sarcasm>.

     
     
  • 2.4, Ваганыч (?), 00:19, 13/06/2012 [^] [ответить]    [к модератору]
  • +1 +/
    Дружище, как бы не я не относился к бсд, но "сарказьм" надо проявлять, только поняв, для начала, о чем новость. А то выходит петросянство.
     
     
  • 3.6, Аноним (-), 01:46, 13/06/2012 [^] [ответить]    [к модератору]
  • +/
    Судя по вашим сомнениям, вы еще не поняли.
     
     
  • 4.8, Ы (?), 02:18, 13/06/2012 [^] [ответить]    [к модератору]  
  • +2 +/
    Мы поняли что у тебя есть шелл на Netfilx box'ах ... товариЩь пертосян :-)
     
  • 1.9, Аноним (9), 03:18, 13/06/2012 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    всётки опенбсдшная параноййя на стабильность привязанность к амд сказалась , с... весь текст скрыт [показать]
     
  • 1.10, arcade (ok), 11:34, 13/06/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?
     
     
  • 2.11, Ваня (??), 12:57, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > В гипервизоре Xen найдена критическая уязвимость ...
    > Проблема связана с возможностью создания условий для генерации исключения в неподходящем состоянии процессора в процессе возврата из системного вызова (SYSRET)

    Ошибка в Xen.

     
     
  • 3.14, arcade (ok), 13:23, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    А почитать внимательно? http://www.securityfocus.com/archive/1/523076/30/0/threaded
     
     
  • 4.18, Ваня (??), 13:58, 13/06/2012 [^] [ответить]    [к модератору]  
  • +1 +/
    II. Problem Description

    FreeBSD/amd64 runs on CPUs from different vendors. Due to varying
    behaviour of CPUs in 64 bit mode a sanity check of the kernel may be
    insufficient when returning from a system call.

    Описание проблемы: "a sanity check OF THE KERNEL may be insufficient"

    Можете дополнительно посмотреть на CVS, где английским по белому указано что ошибка в модуле trap.c, т.е. в модуле обработчика исключений.

    Мне каждого здесь в его какашки носом тыкать??

     
     
  • 5.20, arcade (ok), 14:31, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > II. Problem Description
    > FreeBSD/amd64 runs on CPUs from different vendors. Due to varying
    >  behaviour of CPUs in 64 bit mode a sanity check of
    > the kernel may be
    >  insufficient when returning from a system call.
    > Описание проблемы: "a sanity check OF THE KERNEL may be insufficient"
    > Можете дополнительно посмотреть на CVS, где английским по белому указано что ошибка
    > в модуле trap.c, т.е. в модуле обработчика исключений.

    Да, именно об этом был мой вопрос. И в Xen, и в FreeBSD фиксили неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна.

    > Мне каждого здесь в его какашки носом тыкать??

    А не могли бы вы разговаривать повежливее а не на уровне пятого класса школы?

     
     
  • 6.21, Ваня (??), 14:41, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна

    Хмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка связана с обработкой исключения ядром.

    Про процессор я написал выше: в нём десятки флагов, влияющих на его поведение и работу. Неверная их настройка (или надежда "на авось" и отказ от их настройки с сохранением значений по умолчанию) приводят к неожидаемым ситуациям, что и случилось.

     
     
  • 7.24, arcade (ok), 15:10, 13/06/2012 [^] [ответить]    [к модератору]  
  • +1 +/
    >> неспецифическое поведение sysret на процессорах Intel, которая не проверяла адрес возврата хотя по спекам вроде как должна
    > Хмм... Из какого астрала вы инфу черпаете? Ни в статье, ни в
    > приведённой вами выше ссылки ничего подобного нет. Везде указано что ошибка
    > связана с обработкой исключения ядром.

    Да вот коммент из кода:

    If the user-supplied value of %rip is not a canonical address, then some CPUs will trigger a ring 0 #GP during the sysret instruction.  However, the fault handler would execute with the user's %gs and %rsp in ring 0 which would not be safe.  Instead, preemptively kill the thread with a SIGBUS.

    А в спеке такого поведения нет: http://www.nalanda.nitc.ac.in/industry/AppNotes/AMD/21086.pdf

    Да и вообще неожиданное исполнение кода из юзерлянда это просто подарок.

    > Про процессор я написал выше: в нём десятки флагов, влияющих на его
    > поведение и работу. Неверная их настройка (или надежда "на авось" и
    > отказ от их настройки с сохранением значений по умолчанию) приводят к
    > неожидаемым ситуациям, что и случилось.

    С моей стороны это выглядит немного иначе. Изначально syscall/sysret как и sysenter/sysexit вводились чтобы заменить call/ret/iret вместе со всем набором проверок которые нужно было произвести для их вызова. А теперь получается что нет, всё равно нужно городить икебану самому потому что есть edge cases...

     
     
  • 8.26, Ваня (??), 15:29, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    1. спецификации выложены на intel.com и amd.com.
    2. спецификации размазаны аж по 20 (?) 500-страничным документам, где неверное прочтение любой (!!) строки может в корне повлиять на правильность результата.
    3. intel и amd используют различную терминологию, поэтому правильно читать оба документа, не забывая понимать кто что под каким словом понимает.

    Ещё ни разу никто не уличил ни intel, ни amd в нарушении спецификаций. Если интересно - можете создать тренд на f.osdev.org и подождать, уверен вам покажут где это описано.

    SYSENTER/SYSEXIT/SYSCALL/SYSRET вводились для ускоренной передачи управления между уровнями процессора и отхода от прерываний (с учётом того что прерывания сейчас через MSI, которое MMIO, это более чем логично).

    Шаманство с состояниями процессора и флагами было всегда. Маскируемые прерывания, немаскируемые, исключения во время вызова обработчика прерывания, прерывание во время вызова другого прерывания, приоритет прерываний, и т.п. Почитай тот же f.osdev.org где начинающие ОС-кодеры описывают свои злоключения, там добрая треть проблем из-за настройки механизма прерываний.

     
     
  • 9.27, ананим (?), 16:08, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    >Ещё ни разу никто не уличил ни intel, ни amd в нарушении спецификаций.

    там вон вверху ссылка на пдф с упоминанием 121 ошибки.
    специально для ваней:
    Sequential Execution Across Non-Canonical Boundary
    Causes Processor Hang
    Description
    The processor will hang when the following conditions are met:
    • The processor is in 64-bit mode
    • The code segment limit = 0xFFFF_FFFF
    • The last byte of the current instruction is located at 0x7FFF_FFFF_FFFF
    • The next sequential instruction fetch is attemped at 0x8000_0000_0000
    The correct behaviour is to cause #GP (general protection exception).
    Potential Effect on System
    The system hangs.
    Suggested Workaround
    The operating system should not allocate the page at the boundary of canonical address space.

    так вот, это и есть нарушение спецификации. :D

     
  • 6.28, Аноним (-), 16:13, 13/06/2012 [^] [ответить]     [к модератору]  
  • +/
    Это Ваня, который гадит на форумы в обмен на наборы байтиков от MS Как-то наивн... весь текст скрыт [показать]
     
  • 2.12, Ваня (??), 13:02, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой программистов, считающих частные случаи общими.

    Так напр. никто не обещал что при включении ПК оперативная память будет заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1 стало параметром, который нужно ещё получать по определённой методике, а в спецификации версии 1.3 изменили методику получения.

     
     
  • 3.15, arcade (ok), 13:26, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > А то что ошибка проявляется лишь в Intel связано исключительно с ошибкой
    > программистов, считающих частные случаи общими.

    syscall/sysret изначально появился в процессорах AMD. Intel пришлось скопировать эти инструкции после выхода спецификации amd64 так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.

    > Так напр. никто не обещал что при включении ПК оперативная память будет
    > заполнена 0х00000000, хотя обычно это именно так. Никто не обещал что
    > процессор будет в каком-то конкретном состоянии (установленные/сброшенные флаги), хотя
    > обычно они всегда одинаковые. И т.д. "Радости" добавляет напр. что в
    > спецификации версии 1.0 что-то было константой, а в спецификации версии 1.1
    > стало параметром, который нужно ещё получать по определённой методике, а в
    > спецификации версии 1.3 изменили методику получения.

    Никто не обещал что при реализации инструкций инженеры Intel будут следовать каким-то спецификациям.

    PS: Честно, я подозреваю что не в инженерах дело. Нужно было срочно выпускать новый проц чтобы поднять неосвоенную нишу рынка.

     
     
  • 4.16, Ваня (??), 13:39, 13/06/2012 [^] [ответить]     [к модератору]  
  • –1 +/
    Невежество 8470 1, а конкретно Первоначально для вызова функций ОС приложени... весь текст скрыт [показать]
     
     
  • 5.17, arcade (ok), 13:58, 13/06/2012 [^] [ответить]     [к модератору]  
  • +1 +/
    gt оверквотинг удален Поздравляю, вы знаете историю Я не стал писать сразу не... весь текст скрыт [показать]
     
     
  • 6.19, Ваня (??), 14:02, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s technology into its client and server software

    Ваша версия перевода: так как Microsoft открыто заявила что либо Intel идёт лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо берёт готовый спек от AMD.

    Простите, но в оригинале сказано СОВЕРШЕННО другое.

    Аналогично по второму переводу.

     
     
  • 7.22, arcade (ok), 14:49, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > Оригинал: Microsoft forced Intel to adopt AMD’s approach, building support for AMD’s
    > technology into its client and server software
    > Ваша версия перевода: так как Microsoft открыто заявила что либо Intel идёт
    > лесом со своей то-ли пятой, то-ли шестой версией 64-битных инструкций, либо
    > берёт готовый спек от AMD.
    > Простите, но в оригинале сказано СОВЕРШЕННО другое.

    Возможно я малость и перегнул палку, но всё сводится к одному:

    1. Intel выпустил Itanium. Microsoft выпустил винду под него.
    2. AMD выпустила AMD64. Microsoft выпустил винду под него.
    3. Intel выпустил IA-32e (по моему это так называлось, но могу сильно гнать). Когда Intel пришёл к Microsoft ему было сказано что на одну 64-bit'ную платформу от Intel винда уже портирована и начинать процесс портирования заново никто не будет.

    > Аналогично по второму переводу.

    Это не перевод а личное мнение.

     
     
  • 8.25, Ваня (??), 15:17, 13/06/2012 [^] [ответить]    [к модератору]  
  • –1 +/
    1 и 2 ДА
    3 почти

    Интел продвигал Itanium, AMD продвигал AMD64. Каждый считал что за их технологией будущее, а конкурент с треском провалится. В пользу Intel'а говорило превосходство над AMD (AMD всегда был отстающим) и действительно интересная и масштабируемая аппаратная платформа, в пользу AMD - совместимость. Когда победа AMD64 стала очевидной, она была реализована Intel сначала под названием "IA32-e", затем переименована в "EMT64T", затем в "Intel64".

    Майкрософт, она здесь если и была, то лишь как заинтересованное лицо (пусть и весьма влиятельное). Скорее готов допустить (форбс это всё же больше сплетни и сопли; их больше интересует стоимость акций и то что на неё влияет, чем всё прочее) что Майкрософт попросил обе компании побыстрее закончить вражду и найти компромисс. В конечном счёте необходимость х64 понимали все, вопрос стоял лишь в том какой из двух путей выбрать.

     
  • 7.23, angra (ok), 14:55, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    Не бойся, выдай нам свой СОВЕРШЕННО другой перевод.
     
  • 2.13, Andrey Mitrofanov (?), 13:04, 13/06/2012 [^] [ответить]    [к модератору]  
  • +/
    > Я правильно читаю новость? В интеловских процессорах обнаружена бага которую решили считать фичей?

    Не-а. С куста паравиртуализации _продолжают сыпаться плоды. (И да, брат Ван +1.)

     
  • 1.30, PnD (??), 11:18, 19/06/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Прошла неделя. Ну, сусь вне зачета - они собс-но xen и пилят.
      RHEL-5 (CentOS, SL): "This issue did not affect the versions of the kernel-xen package as shipped with Red Hat Enterprise Linux 5 as we did not have support for sysenter and compat (32bit) version of syscall instructions for PV guests..."
      И ниипёт ;)

      Дебианщики упорно тестят патч на стабильность в сиде, а вот убунтовцы не постеснялись вкатить везде включая LTS. Что по сути верно - натягивая апдейт (и ребутая) ксено-хостинг, Вы наверное знаете, что делаете.

     
  • 1.31, Андрей (??), 13:30, 04/07/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    >>CPU AMD Athlon 64 и AMD Opteron, в которых не устранена 121 ошибка в микрокоде

    :D тонко так :D а почему бы рядышком на аналогичный файлик от Intel  ссылочку не выложить? :D

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2019 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor