LINUX.ORG.RU

Уязвимость во FreeBSD на процессорах AMD


0

0

FreeBSD-SA-06:14.fpu

Затронуты все релизы FreeBSD/i386 и FreeBSD/amd64 при работе на процессорах AMD Athlon, Duron, Athlon MP, Athlon XP, Athlon64, Athlon64 FX, Opteron, Turion и Sempron.

Указанные процессоры при использовании команд fxsave/fxrstor не сохраняют содержимое FPU регистров FOP, FIP и FDP, если ES бит регистра флагов сопроцессора не установлен в единицу, то есть не произошло исключение. Такое поведение документировано AMD, но отличается от процессоров других производителей, которые не обращают внимание на бит ES.

В результате ядро FreeBSD не восстанавливает содержимое регистров FOP, FIP и FDP при переключении контекста.

Как результат, локальный пользователь может отслеживать выполнение кода с плавающей точкой. Теоретически уязвимость может привести к раскрытию конфиденциальной информации.

Пользователям процессоров AMD седьмого и восьмого поколения рекомендуется обновить систему до последнего STABLE или RELENG, или воспользоваться следующими патчами:

[FreeBSD 4.x] ftp://ftp.FreeBSD.org/pub/FreeBSD/CER...

[FreeBSD 5.x, 6.x] ftp://ftp.FreeBSD.org/pub/FreeBSD/CER...

>>> Подробности (для Shaman007: это текстовый файл)

★★★★★

Проверено: Shaman007 ()

Похоже на задукоментированную глупость AMD, на которую долгое время не обращали внимание.

bbk123 ★★★★★
()

И после этого бздишники еще на линукс наезжают!

Даа... Критическая уязвимость, приводящая к раскрытию конфиденциальной информации во ВСЕХ версиях freebsd - это что-то..

anonymous
()
Ответ на: комментарий от anonymous

Ну тогда я предсказываю, что в 2.6.16.9 закроют эту же уязвимость. :)

Sorcerer ★★★★★
()
Ответ на: комментарий от anonymous

Научитесь пользоваться первоисточниками:

commit 9d395d1961a0eeb9e8b1ef2854f3ca8f0b985266
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Tue Apr 18 23:10:14 2006 -0700

    Linux 2.6.16.9

commit 7466f9e72dac13452d871a3fb72fc7bd9c93c864
Author: Andi Kleen <ak@suse.de>
Date:   Wed Apr 19 07:17:31 2006 +0200

    [PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056)
    
    AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
    when an exception is pending.  This means the value leak through context
    switches and allow processes to observe some x87 instruction state of
    other processes.
    
    This was actually documented by AMD, but nobody recognized it as being
    different from Intel before.
    
    The fix first adds an optimization: instead of unconditionally calling
    FNCLEX after each FXSAVE test if ES is pending and skip it when not
    needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP.
    
    This means other processes always will only see a constant value defined
    by the kernel in their FP state.
    
    I took some pain to make sure to chose a variable that's already in L1
    during context switch to make the overhead of this low.
    
    Also alternative() is used to patch away the new code on CPUs who don't
    need it.
    
    Patch for both i386/x86-64.
    
    The problem was discovered originally by Jan Beulich. Richard Brunner
    provided the basic code for the workarounds, with contribution from Jan.
    
    This is CVE-2006-1056
    
    Cc: richard.brunner@amd.com
    Cc: jbeulich@novell.com
    Signed-off-by: Andi Kleen <ak@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.9

bbk123 ★★★★★
()

В винде, наверное, тоже эта уязвимость есть, но закрывать не будут. Поэтому постоянные патчи линуха/бсд - это зло, а неизменность винды - рулез.

anonymous
()
Ответ на: комментарий от anonymous

>Фряха все хереет и хереет...

не верный вывод, верный вывод, что фришники последнее время зашевелились сильнее поэтому и находят много.

anonymous
()

>И после этого бздишники еще на линукс наезжают!

>Даа... Критическая уязвимость, приводящая к раскрытию конфиденциальной информации во ВСЕХ версиях freebsd - это что-то..

И после этого красноглазые не знают, что творится в их любимой системе.

Воистину, надо переименовать `anonymous' в `lamer-red-eyed', может быть, хоть подписываться под сообщениями начнут.

stellar
()
Ответ на: комментарий от stellar

>Воистину, надо переименовать `anonymous' в `lamer-red-eyed', может быть, хоть подписываться под сообщениями начнут.

Вы наверное думаете что 'stellar' (к стати можно переименовать в что нибудь типа damn_ass_screwing_bastard) звучит лучше `anonymous'? Сомнительно...

anonymous
()
Ответ на: комментарий от anonymous

>Вы наверное думаете что 'stellar' (к стати можно переименовать в что нибудь типа damn_ass_screwing_bastard) звучит лучше `anonymous'? Сомнительно...

1) Да, уверен. Поэтому мой никнейм - stellar, а не damn_ass_screwing_bastard.

2) Да, это очень смелая и мужественная позиция -- анонимно выкрикивать всякие глупости. ;)) Ведь после написания очередной чуши очень легко сделать вид, что писали ее не Вы. Отличная гражданская позиция.

stellar
()

Да,частота фиксов особенно в линуксе немного "грустит" (2.6.16. 123456789!), но с другой стороны - закрытые дыры - это все-таки _закрытые_ дыры.

Valmont ★★★
()
Ответ на: комментарий от Valmont

> Да,частота фиксов особенно в линуксе немного "грустит" (2.6.16. 123456789!), но с другой стороны - закрытые дыры - это все-таки _закрытые_ дыры.

не грустит а парит пересобирать каждый день ядро, а то что меньше дыр это гуд

им еще надо патчи с промежуточными релизами выпускать каждый день новый rc патча а в конце недели финальный

AleX ★★★
()
Ответ на: комментарий от AleX

Мне нравиться фраза "Теоретически уязвимость может привести к раскрытию конфиденциальной информации. " Это типа теоритически мы можем изменить гравитационное поле земли и вся ваша страна окажеться под водой "Жириновский" что то США не спешит такие теоритические уязвимости закрывать...думаю и Фря особо не спешит ) Потому что по большому счету нафиг никому не нужно.

TRZ_ua
()
Ответ на: комментарий от baka-kun

> AMD purposely designed the implementation of the FXSAVE and FXRSTOR instructions in the above manner to significantly improve the performance of context-switching.

И теперь из-за них этот самый performance of context-switching пришлось немного ухудьшить програмными средствами. Я с них тащусь :-))

bbk123 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.