The OpenNET Project / Index page

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



"Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо выполнить код на уровне BMC-чипа"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо выполнить код на уровне BMC-чипа"  +/
Сообщение от opennews (??), 22-Июл-23, 12:18 
Исследователи из компании  Eclypsium выявили две узявимости в контроллерах BMC (Baseboard Management Сontroller), оснащённых прошивками MegaRAC от компании American Megatrends (AMI), которые применяются многими производителями серверов для организации автономного управления оборудованием. Уязвимости позволяют неаутентифицированному атакующему получить доступ к управляющему окружению BMC и выполнить свой код на уровне прошивки через отправку специально оформленного запроса на HTTP-порт управляющего интерфейса Redfish (пришёл на смену IPMI). Как правило, доступ к BMC открывается только для локальной сети или сети датацентра, но случается, что его не закрывают и для обращения из глобальной сети. Эксплуатация уязвимостей в BMC также может быть произведена при наличии доступа к локальной операционной системе с целью повреждения оборудования. Проблемы устранены в обновлениях прошивки  AMI MegaRAC BMC SPx_13.2 и SPx_12.4...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59479

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +12 +/
Сообщение от Аноним (1), 22-Июл-23, 12:18 
Бэкдор оказался бэкдором, какая неожиданность.
Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –4 +/
Сообщение от лютый арчешкольник... (?), 22-Июл-23, 16:07 
Ну расскажи как например торговать дедиками без данного "бэкдора" или просто иметь тыщи серваков
Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +3 +/
Сообщение от Аноним (-), 22-Июл-23, 16:43 
> Ну расскажи как например торговать дедиками без данного "бэкдора" или просто иметь
> тыщи серваков

Теперь можешь и не торговать, как говорится - "налетай, подешевело!" :)

Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 22-Июл-23, 16:43 
э... готов предоставить тебе консультативную помощь при условии согласования оплаты. Дорого, надежно, проверено временем.

То есть, собственно, когда серваков уже "тыщи" (а не первая тысяча) - oob становится уже неэффективен и маловостребован - не набегаешься за каждым. Да и тысячи портов недешево обойдутся.

Поэтому как раз в таких местах его запросто может не быть вообще.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

35. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от pofigist (?), 23-Июл-23, 10:37 
Угу... Расскажи ка мне как ты будешь строить кластеры виртуализации без hf или сделаешь hw без bmc
Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –2 +/
Сообщение от пох. (?), 23-Июл-23, 12:20 
Я пока не вижу предложений по оплате.

"кластеры виртуализации" без oob управления, что характерно - вот прямщас вижу.
(хотя это ни разу не попадает в целевую аудиторию первоначального предложения - системы с числом машинок измеряемых в тысячах)

Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от pofigist (?), 23-Июл-23, 13:52 
Кластеры всяческих рогов и копыт - неинтересны.
А как ты будешь строить кластеры без блейдов, hw и FC - мне очень интересно узнать. Чисто чтоб поржать.
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от пох. (?), 23-Июл-23, 14:01 
как раз у рогов и копыт вполне может получиться как ты любишь - подорого, красиво, модно и молодежно. Купят целых два блейда и целый один свитч (но это неточно, можно ж соединить порт-в-порт) и целую одну полку.

Хотя точно так же можно было бы сделать и из г-на, и оно, в целом, даже работает как минимум не хуже, только вот не получится перекинуть ответственность на продавца блейда, полки и свитчей, тебе не понравится.

Но там выше рассуждали о тысячах (а не первой тысяче даже) машинков. И все это - да, делают без блейдов, без oob, и тем более без FC. Оно в этих масштабах либо не работает либо уже не нужно низачем.
Если у тебя отвалился сервер с номерком 8421 - ты не будешь ковыряться заходить на него в консольку. Тебе просто не до того. К тому же никто потери бойца даже и не заметит, скорее всего.


Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от pofigist (?), 23-Июл-23, 14:58 
> Если у тебя отвалился сервер с номерком 8421 - ты не будешь ковыряться заходить на него в консольку.

facepalm.jpg

BMC нужен вовсе не для того чтоб "заходить и ковыряться в консольке". Почитайте уж наконец что такое hardware fencing, для чего он нужен и как реализуется.

Кластеры с "тысячами нод" без блейдов и FC наверное можно сделать, но... Обнаружится много интересного - начиная с того что ~40 нод, которые влезают в стандартную стойку, не укладываются ее стандартное энегопотребление и кончая тем что к ним идет слишком много проводов... А радиотехника это наука о контактах. А iSCSI имеет некоторые особенности реализации, которые просто не позволят ей работать в таких масштабах. А все остальное - имеет еще худщую латентность. И RDMA в Eth конечно есть, но ее поддержка настолько сырая, что ее выжимать можно... И много чего веселого.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от пох. (?), 23-Июл-23, 18:25 
ни для чего он не нужен.
Читатель, с подвальным опытом.

> Обнаружится много интересного - начиная с того что ~40 нод, которые влезают в стандартную стойку,
> не укладываются ее стандартное энегопотребление и кончая тем что к ним идет слишком много
> проводов...

вот ведь дятел... То есть тебе никогда либо не приходило в голову посчитать или померять, либо в твоем подвале считать нечего?

На самом деле - с точностью до наоборот. После второй корзины выясняется что потребление этой хрени не укладывается, а еще, внезапно, не укладывается нагрузка на пол. И тут начинает понемногу доходить что толку от сверхплотного размещения в этих масштабах нет, вред один. И ставишь ты эти корзины с кучей спэйсеров, которые охлаждению помогают, но как-то так себе.

И про iscsi свой тоже забудь, это тоже так не работает.

Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от pofigist (?), 23-Июл-23, 18:58 
Нагрузка на пол не укладывается? Ну теперь все понятно - вы типичный представитель "подвального ДС" родом из нулевых.
Вы конечно веселые самоделкины, особенно меня радовали ваши так называемые СХД, но... не надо учить дядю, проектировавшего, развертывавшего и обслуживавшего Tier IV DC
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 23-Июл-23, 22:04 
У дяди черезмерно задранное чсв. Даже если раз в жизни ему дали приложиться к проекту единственного DC.

Нагрузку на пол ты конечно тоже в своем ДЦ считал? А, не, конечно же не ты.

Электрику ты явно никогда и не считал, и не мерял.

Что ж ты там такое тогда понапроектировал, спрашивается?

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от pofigist (?), 24-Июл-23, 09:08 
Для того чтоб считать - есть инженеры. А я руковожу.
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –3 +/
Сообщение от пох. (?), 24-Июл-23, 09:19 
"Он ни на каком инструменте не играет, он руководитель - как Вы!"

Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от Аноним (65), 24-Июл-23, 19:31 
лол, можно подумать ты считал хоть что-то из упомянутого выше считал, и даже если захотели бы не смог, потому что ты обычное трепло-троечник с 8 классами образования от силы, а серверные если и видел, то в роли грузчика
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

72. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от pofigist (?), 25-Июл-23, 10:08 
О, типовой инженер, типа вас - считает все правильно. Но есть нюансы...
Один Правильно посчитал мощность потребления - 2МВт
Другой правильно посчитал мощность охлаждения - 1МВт
И на вопрос "А куда денется 1МВт?" хором отвечают "На полезную работу!"
После попыток выяснить какую полезную работу в физическом смысле выполняет комп - началось мычание про вентиляторы, лампочки и микроволновое излучение...

Вот для отлавливантя таких нюансов расчетов - я и нужен.😉

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

60. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Всем Анонимам Аноним (?), 24-Июл-23, 17:18 
Прежде чем оплату спрашивать "дорого", хорошо бы почитать хотя бы что такое redfish API или, к примеру, iDRAC API и как они используются при установках 500 серверов за раз.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

61. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 24-Июл-23, 17:59 
Прежде чем вякать - хорошо бы научиться не только "читать", но и работать.

Обрати внимание, намек - для установки 500 серверов, за раз, или каждый отдельно и с индивидуальным сетапом - это все - совершенно не требуется. Более того - ничем неоправданный ненужный геморрой.

Как показывает опыт любимого немецкого провайдера - и для десятков тысяч (причем - индивидуально устанавливаемых) тоже необязательно.

Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от Аноним (65), 24-Июл-23, 19:33 
доооо, о работе (языком, видимо) нам рассказывает первостепенное местное трепло
Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +2 +/
Сообщение от pofigist (?), 25-Июл-23, 10:37 
Развернуть 500 серверов с помощью какого-нибудь ансибля - не проблема. Правда необходимо чтоб в бивисе была настроена сетевая подсистема... Ее можно настроить тем же ансиблем. Через BMC разумеется. Ну или ручками. Без вариантов 😉
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

74. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от пох. (?), 25-Июл-23, 10:46 
> Развернуть 500 серверов с помощью какого-нибудь ансибля - не проблема.

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

Признайся честно - ты в ойти из автопрома пришел, да? Автоваз или покруче - кенигсбергский цех какой-нибудь?


Ответить | Правка | Наверх | Cообщить модератору

81. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от pofigist (?), 26-Июл-23, 09:18 
Автомобили не имеют привычки разваливаться на ходу. В оличае от ваших поделий.
Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от пох. (?), 26-Июл-23, 09:32 
лол. Ты и автомобилист такой же. Прав у тебя нет, я надеюсь?

(с-ка, я ведь угадал что ты с автоваза. Те тоже вряд ли когда-либо ездили на чем-то кроме заводского автобуса по маршруту дом-завод-наливайка. Руководителя, понятно, возют на индивидуальном.)

P.S. та хрень про которую я ниже рассказывал, с табличкой "не перезагружать" - не "моя", а вполне себе такой poweredge. Ентер-прайсненько, как ты любишь, наффсе. И, что бы вы думали? Оно - вотъ! Развалилось на ходу. Спасибо что это не отвалившееся вместе со ступицей колесо твоего автотаза, никого не убьет.

Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от pofigist (?), 27-Июл-23, 09:05 
Никогда не работал в автомобильной промышленности. Так что извини, но гадалка из тебя тоже никуда не годная.
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

91. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (-), 26-Июл-23, 22:22 
> Автомобили не имеют привычки разваливаться на ходу. В оличае от ваших поделий.

Неправда ваша. Я видел как у ТАЗа на ходу отвалилосо колесо.

Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 27-Июл-23, 09:48 
>> Автомобили не имеют привычки разваливаться на ходу. В оличае от ваших поделий.
> Неправда ваша. Я видел как у ТАЗа на ходу отвалилосо колесо.

видел он, суко. Как вот тебе такое, илон  маск - ты на горном серпантине руль влево - а правое колесо - направо? А вниз лететь с километр - вооон там где-то метрах в полста висит остаток фуры, тоже, видимо, направо поехала. До низу, заметим, даже и не долетела. С нетазами тоже слуцяетсо.

Не, в принципе-то, конечно, ничего особенного, "нормальный рабочий момент".

Гораздо хреновее такое вот нло самому поймать. Ну или кардан отвалившийся от впереди несущейся фуры, тоже прикольно.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

67. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от onanim (?), 24-Июл-23, 22:23 
Есть такие конторы, на баш-скриптах по айпишнику, из самого говна что удалось раздобыть на авито. Зато админу наверное по кайфу красноглазить.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

41. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (-), 23-Июл-23, 17:41 
> э... готов предоставить тебе консультативную помощь при условии согласования оплаты. Дорого,
> надежно, проверено временем.

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

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

52. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от анон (?), 24-Июл-23, 03:45 
То-то я думаю, почему в центробанке всё так херово... Помню один из случаев в цб, сели седовласые дедки и давай рассказывать, что общепринятое(мировое) определение микросервисов их не устраивает, да ималоинтересно, им надо своё определение в документах написать. Видимо пох был один из тех баклажанов, ну либо у них там целая когорта таких "экспертов"
Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от Аноним (-), 25-Июл-23, 06:50 
> э... готов предоставить тебе консультативную помощь при условии согласования оплаты. Дорого,
> надежно, проверено временем.

Майкрософту свои услуги предложи, безопасТничек! А то во как https://servernews.ru/1090415 - походу случилось ЭТО: как я понимаю у майкрософта хватило ума сделать бааааальшой AD. Кто-то резонно рассудил что большому кораблю - большую торпеду. И сломал абажур. И судя по отмазочным коментам майков - видимо и тот большой ADъ заодно как раз раздербанили. А вот это красиво. Судя по тому как майки отмазываются у них там на самом деле ж@па полная. Но не могут же они на публику сказать это.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

55. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от torvn77 (ok), 24-Июл-23, 13:42 
>Ну расскажи как например торговать дедиками без данного "бэкдора" или просто иметь тыщи серваков  

BMC это искусственно навязанная технология для того чтобы АНБ,ФБР и прочие могли безпрепятственно извлекать информацию из любого компьютера.  
Реально же возлагаемые на BMC задачи можно решить так:  
1. В сетевую карту через jtag заливается сертификат цифровой подписи для заверки управляющих пакетов WoL.
2. Сам протокол WoL помимо спец пакета для пробуждения компьютера дополнительно получает пакет для принудительной перезагрузки.

Всё это позволит делать удалённую загрузку И перезагрузку хостов(ПК или серверов)

4. В  ядре Linux производится замена устаревшей initramfs на накатывание initrd на раздел zram соответствующего размера.

5. В GRUB добавляется клиент DHCPsec(если этого протокола нет то он разрабатывается) с сертификатом удостоверяющего DHCP сервер и sFTP для безопасной загрузки образа ядра и initrd с базовой системой.(по уму это надо бы встроить в БИОС)  

6. Вместо доступа к BMC осуществляется доступ по находящемуся в initrd sshd

7. В случае необходимости удалённого доступа к шинам IPMI,JTAG,SMBus и прочим системным шинам используется отдельное работающее через сеть прокси-устройство.  
Доступ к остальным портам не нужен так если компьютер работает нормально то можно зайти по SSH, а если он повис то его всё равно надо перегружать, всё иные действия на прямую с железом через прямой доступ к оборудованию по системным шинам следует делать через отдельное прокси-устройство.  

Думаю что всё это и проще, и дешевле, и надёжнее, чем то, что есть сейчас, но так не сделали так как это снизит возможности по созданию бекдоров.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

56. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от InuYasha (??), 24-Июл-23, 13:52 
Это ты всё здорово, конечно, описал. Только мне надо удалённо залезть в BIOS, посмотреть графики питания и логи замены хардов. Затем прогрузить виртуальный блюрей-привод чтобы установить винду, при этом глядя в экран. Если что - и ребутнуть. Но вы пилите свой initwtf.
Но если что - все компы это ваше АНБ,ВСБ,МосЗад и РКН. Так что, есть там БМК, нет - разница не велика.
Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 24-Июл-23, 15:05 
> посмотреть графики питания и логи замены хардов.

Заходите по ssh и смотрите.

>Если что - и ребутнуть.

Если вы внимательно читали то вторым пунктом предусматривается дополнение протокола WoLsec пакетом для удалённой перезагрузки компьютера.

>  мне надо удалённо залезть в BIOS

По уму прямой доступ к компьютеру и БИОС на многокомпьютерных кластерах вам нужен только один раз для включения сетевой загрузки и установки сертификатов ваших серверов WoLsec,DHCPsec,DNSsec и sFTP|https.
Все остальные ОБОСНОВАННЫЕ для кластера поводы решаются либо через ssh в систему либо свидетельствуют о аппаратных поломках компьютера.

>Затем прогрузить виртуальный
> блюрей-привод чтобы установить винду, при этом глядя в экран.

А зачем вам винда в качестве основной ОС на сервере или ноде кластера?  
Что вы на ней там будете делать?  
И разве не будет удобнее И надёжнее её поставить в виртуальную машину, что сделает виртуальный блюрей просто ненужным?

И может вам лучше взять openbmc и обычную десктопную материнку, это будет и проще, и дешевле, чем дорогущее медленное серверное железо.

Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от onanim (?), 27-Июл-23, 09:48 
наркоман? openbmc - это прошивка для трёх с половиной процессоров BMC, которых на обычных десктопных материнках не бывает
Ответить | Правка | Наверх | Cообщить модератору

100. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 27-Июл-23, 12:09 
а ты сомневался?


Так-то на обычных не бывает вообще никаких bmc (у норкоманов в головах просто каша, слышали звон но отличать bmc от ME и ME от AMT не обучены)

А серверные построены в общем-то на полутора чипах, только вот перепрошить их (на васян-прошивку) не так просто, да и зачем неясно - традиции-с, видать, типа подкованной блохи - нихрена не видно, нахрен не надо, и работавшая до того вещь - работать перестала.

Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 24-Июл-23, 18:05 
> Это ты всё здорово, конечно, описал. Только мне надо удалённо залезть в
> BIOS, посмотреть графики питания и логи замены хардов. Затем прогрузить виртуальный
> блюрей-привод чтобы установить винду, при этом глядя в экран.

одного не пойму - как при таком плотном графике ты еще и работать успеваешь?

Вот правда - я мог бы поверить если бы услышал - "ubuntu", там не знаешь что хуже - руками по кнопкам шлепать или городить адскую е..нину для ее и только ее уникальной автоматизации, но зачем тебе часами разглядывать экран  с очень содержательной надписью "Getting files ready for installation"?


Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

57. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от Андрей (??), 24-Июл-23, 14:05 
Где-то я уже это видел... О! Автоваз!
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

62. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 24-Июл-23, 18:01 
> BMC это искусственно навязанная технология для того чтобы АНБ,ФБР и прочие могли

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

Кроме мифов и легенд скоро вообще ничего не останется.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

68. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 25-Июл-23, 02:01 
> уровень опеннета... впрочем, чего вы хотите

А вы пробовали подумать о том, насколько оправдано та сложность, с какой BMC сделан сейчас?  
Почему его надо делать суперсложным образом как супервизор системы, а не простым как отдельное устройство как это сделано в openbmc сейчас?

Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от onanim (?), 27-Июл-23, 09:49 
>> уровень опеннета... впрочем, чего вы хотите
> А вы пробовали подумать о том, насколько оправдано та сложность, с какой
> BMC сделан сейчас?
> Почему его надо делать суперсложным образом как супервизор системы, а не простым
> как отдельное устройство как это сделано в openbmc сейчас?

точно наркоман. ты вообще в курсе, что любой BMC - это "отдельное устройство", а openbmc - это попытка сделать открытую прошивку для этих закрытых устройств?

Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 27-Июл-23, 11:48 
> ты вообще в курсе, что любой BMC - это "отдельное устройство"

В курсе, но только вот много лет я читаю вопли о том что ради всяких благ его стали встраивать внутрь процессора и дали полный доступ ко всему оборудованию компьютера.

> а openbmc - это попытка сделать открытую прошивку для этих  закрытых устройств?

Возможно я смешал в одно два разных проекта(была новость о том что делают BMC на одноплатнике, скорее всего малинке )

Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от onanim (?), 28-Июл-23, 09:24 
> В курсе, но только вот много лет я читаю вопли о том
> что ради всяких благ его стали встраивать внутрь процессора и дали
> полный доступ ко всему оборудованию компьютера.

это Intel ME, а не BMC, совершенно другой бэкдор.
ME предоставляет доступ к твоему компьютеру для АНБ и для Интела, а BMC - для АНБ и для производителя BMC

Ответить | Правка | Наверх | Cообщить модератору

104. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 28-Июл-23, 11:58 
> это Intel ME, а не BMC, совершенно другой бэкдор.

Как я понял из древних статей МЕ это обрезанные ошмётки от интегрированного ВМС для серверных и воркстейшных материнок, в которых он первоначально и внедрился и только потом пришёл и на десктоп.

Тогда народ возмущался что ВМС из отдельного стал интегрированным и работает через ту же сетевую карту, что и стоящая на воркстейшене/сервере ОС и его никак не удалить.

Как я помню из-за скандала разработчики дали заднюю и по этому МЕ и стал обрезком, а так ВМС переехал бы туда.

Ответить | Правка | Наверх | Cообщить модератору

70. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (-), 25-Июл-23, 06:59 
> BMC это искусственно навязанная технология для того чтобы АНБ,ФБР и прочие могли
> безпрепятственно извлекать информацию из любого компьютера.

А точно ими? Или это бывает как-то так: ты тут, датацентр - у черта на рогах, и тут у тебя при установке, апгрейде и проч оси что-то пошло не так. Нет, конечно можно подорваться съездить в датацентр - но это не просто и не быстро и даунтайм будет огого.

А можно зайти по oob-management, перекатать операционку - и все завертится.

> 1. В сетевую карту через jtag заливается сертификат цифровой подписи для
> заверки управляющих пакетов WoL.

Подразумевает наличие у сетевки проца. С доступом к сети. And we're back to square one. А чем еще цифровые подписи чекать как не процом с фирмварой?!

> 2. Сам протокол WoL помимо спец пакета для пробуждения компьютера дополнительно
> получает пакет для принудительной перезагрузки.

Потом окажется что фаер или роутер имели что-то против экзотичных пакетоа - и таки поедем в датацентр лично?

> 4. В  ядре Linux производится замена устаревшей initramfs на накатывание
> initrd на раздел zram соответствующего размера.

В Linux можно цеплять хоть что как initrd - даже рут в squashfs вгружаемой как initrd можно. Но что делать если это добро или сам кернел повредились и система не грузится? В датацентр ехать?

> В GRUB добавляется клиент DHCPsec(если этого протокола нет

А если GRUB не взлетает то чего? Да что там - вы даже менюшкой GRUB так сразу по сети не очень то порулите. Хотя для эстетов есть Google serial VGA BIOS, где в принципе уже можно попытаться что-то такое - но ведь у вас же не оно? :)

> 6. Вместо доступа к BMC осуществляется доступ по находящемуся в initrd sshd

А что делать если этот initrd поврежден?

> 7. В случае необходимости удалённого доступа к шинам IPMI,JTAG,SMBus
> и прочим системным шинам используется отдельное работающее через сеть прокси-устройство.

И чем это будет отличаться от - внезапно - BMC?

> Думаю что всё это и проще, и дешевле, и надёжнее, чем то, что есть сейчас,

Как бы груз легаси и совместимости есть. А еще есть соображения чтобы работало по сети в более-менее любом сетапе. И не повреждалось (т.е. в ROM/flash и обычно не трогается). Иначе вы таки поедете при случае в датацентр...

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

75. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 25-Июл-23, 12:48 
С одной стороны вы подумали немного над изложенными мной идеями и даже заметили некоторые недостатки, но тем не менее не поняли что предложенное составляет цельную систему и ответ на ваш вопрос уже есть в другом пункте предложения.  
Начну с вопросов которые вы задали от того, что прочитали невнимательно:  

>Подразумевает наличие у сетевки проца.

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

>Потом окажется что фаер или роутер имели что-то против экзотичных пакетов - и таки поедем в датацентр лично?  

Обычай блокировать экзотические пакеты связан с отсутствием в ранних протоколах и службах сетевой безопасности как понятия, причин блокировать пакеты секюрных протоколов нет, тем более если такие протоколы по умолчанию отключены(если вы внимательно читали то могли бы заметить что чтобы WoLsec включился в сетевую карту надо заливать сертификат).  
Во вторых админы датацентра знают какие службы и пакеты используются для удалённого администрирования и будут разрешать доступ пакетов WoLsec так же как и сейчас разрешают доступ к BMC или ssh(тоже ведь можно порезать ради заботы о пользователях).

>В Linux можно цеплять хоть что как initrd - даже рут в squashfs вгружаемой как initrd можно. Но что делать если это добро или сам кернел повредились и система не грузится? В датацентр ехать?

Если вы внимательно читали то ядро и initrd грузятся по FTPs с удалённого сервера, и ни что не мешает так же грузить и menu.lst в котором вы можете прописать всё что вам нужно.  
Но вы правы, это может быть удобно админам кластеров и ДЦ, но не удобно владельцам локалхостов в арендованных у ДЦ ячейках.  
Но я понял как убрать этот недостаток и раскажу о этом в конце поста:  

>А если GRUB не взлетает то чего?  

Если GRUB заработал то сложно представить обстоятельства при которых он вдруг перестанет работать, особенно если он стоит на отдельном носителе.  
Но вы правы, тут я не последователен, протоколы DNSsec,FTPs и DHCPsec должны быть интегрированы в БИОС(сейчас для удалённой загрузки используются их несекюрные версии, причём DNS в БИОС нет вообще)

А теперь пожалуйста читайте внимательно:  

>И чем это будет отличаться от - внезапно - BMC?

Тем что этот блок будут ставить только те, кому для контроля сервера по какой-то причине нужен аппаратный отладчик, остальным имхо хватит и удалённого включения с перезапуском по WoLsec.  
Но вы правы, я предложил не самое оптимальное решение и этот вопрос натолкнул на правильное решение, которое в своё время и следовало сделать.  
Я отлично понимаю что такое устройство по сути есть внешний BMC, про главный недостаток которого вы не указали: ему нужен дополнительный порт, что и стало причиной столь лёгкого внедрения BMC интегрированных в компьютер.  
Да и провода WoL от сетевой карты выглядят как нелепость
Обдумывая как быть с этим дополнительным портом я понял одну вещь:  
На сетевой карте просто надо сделать отдельный порт на который отправлять все предназначенные для BMC паеты, для отличия которых помечать IP пакет особым образом.  

То есть предлагаемая система теперь выглядит так:  

1. WoLsec не нужен, просто на сетевой карте делается отдельный внутрикорпусный порт на который отправляются все пакеты имеющие пометку BMC и дублируются пакеты DNS,DHCP и их секюрных версий.
2. А там пользователь сам решает какой BMC ему использовать, такой что умеет только нажимать кнопки Powe/Reset и поддержку последовательного COM порта для взаимодействия с БИОСом.
Или такой что ещё умеет в эмуляцию монитора,клавиатуры и блюрея.
Или такой что имеет на борту софт для отладки программ и оборудования и умеет в шины JTAG, SMBus, IPMI и что там есть ещё.
Или не использовать BMC вообще(например сервер размещён не в ДЦ, а локально)
3. Поддержка удалённой загрузки в БИОС не нужна так как соответствующий функционал делается соответствующим внешним BMC, всё что должен уметь БИОС это только грузить GRUB с отдельного небольшого накопителя(возможно эмулируемого BMC).  

Всё получается максимально просто, не дорого, и разделённым на понятные и подбираемые под нужды пользователя функциональные блоки.

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

Ответить | Правка | Наверх | Cообщить модератору

80. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (80), 26-Июл-23, 01:46 
> С одной стороны вы подумали немного над изложенными мной идеями и даже
> заметили некоторые недостатки, но тем не менее не поняли что предложенное
> составляет цельную систему

BMC тоже являет собой цельную систему. Только еще это может быть с сильно меньшими допущениями относительно свойств железок. И при нормальном подходе (опенсорсная доверяемая фирмвара) ничем таким не плохо. Всякие гуглы и фэйсбуки подтвердят.

А фирма AMI как всегда проприетарный "благодетель", который "решает проблемы" для тех сам вон так не может, с характерным AMI_SW в результате. И куда их проприетарное нечто ни сунь, одно и то же получится.

> Сетевые карты по стандарту умеют в защищённую передачу пакетов,

По какому еще стандарту? Чтоб вот прямо произвольную сетевку?

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

Я не понимаю чем фирмварь проца на сетевке будет лучше фирмвари BMC кроме того что навязана конкретная архитектура. Видимо, чтобы у имплементеров было меньше гибкости в том как это делать. Почему это станет секурнее - черт знает. И нет, делать _железку_ для счета RSA или даже эллиптики скорее всего не станут. Нагрузят на вспомогательный сервисный проц который в чипе уже был, допишут фирмвару еше пожирнее, добавив еще и это. Чтобы чип не переделывать, юзанув существующие, и не увеличивать его площадь. Операция же редкая. Часто вы на BMC логинитесь?

> Обычай блокировать экзотические пакеты связан с отсутствием в ранних протоколах и службах
> сетевой безопасности как понятия, причин блокировать пакеты секюрных протоколов нет,

Вы пойдете по всему глобусу объяснять всем бизнесам, транзитным роутерам и чему там еще какие они нехорошие и что дескать фаеры, наты или что там у них надо перенастроить? Без этого вон тот хмырь внезапно обнаружит что доступа - нет. Именно в тот момент когда он потребуется. И стало быть - ехать в ДЦ.

> могли бы заметить что чтобы WoLsec включился в сетевую карту надо
> заливать сертификат).

Весь этот WoLsec удобнее всего имплементить как BMC смотрящий на траф в фоне и - врубающий основную систему. По произвольным программируемым критериям. А то что фирмвар мутный и кривой, так он и у этих такой же будет. Даже хуже - BMC бывают и открытые, а ЭТО будет confidential proprietary на уровне фирмвари.

> Во вторых админы датацентра знают какие службы и пакеты используются для удалённого
> администрирования и будут разрешать доступ пакетов WoLsec

Осталось еще все системы по пути которые процессят пакеты убедить. Потому что если оно заткнется на каком-то корпоративном нате, домашнем роутере, фаере или чем - таки это поездка в ДЦ. Вы же не попросите скажем вон того сотового оператора перенастроить для лично вас их NAT в темпе вальса? Значит доступа не будет - опа, едем в ДЦ.

> Если вы внимательно читали то ядро и initrd грузятся по FTPs с
> удалённого сервера, и ни что не мешает так же грузить и
> menu.lst в котором вы можете прописать всё что вам нужно.

В этом месте возникают вопросы наличия этого сервера, его доступности, кто его содержит и проч. Это +1 точка отказа, а система получается не самодостаточная. И в комплект к серверу надо докупать другой сервер, после чего возникает вопрос - "а что если он помрет?". Сейчас некоторые BMC - тот же линух только зашитый в флешке, что как-то более удачно чем вгрузка по сети. А то что проприетарщики опять все поняли по своему - они и вон то поймут так же. Даже хуже имхо.

> Но вы правы, это может быть удобно админам кластеров и ДЦ, но
> не удобно владельцам локалхостов в арендованных у ДЦ ячейках.

Кроме того я не понимаю как обеспечивается живость сервера сервирующего initrd и проч. А если он помрет, целая толпа серверов курнет бамбук пока его не заменят? Конечно можно redundancy нарулить, но в этом месте мы начинаем хотеть по сути целую ОС в качестве загрузочной фирмвары... и почему она будет лучше чем то что сейчас? Предпосылки какие?

> Если GRUB заработал то сложно представить обстоятельства при которых он вдруг перестанет
> работать, особенно если он стоит на отдельном носителе.

Да мало ли, апдейт на него приехал - и оказался кривой. А поскольку он тоже мини-операционка, в нем вулны бывают или неприятные баги. И я могу вспомнить штуки три апдейтов на оный за последнее время. И среди кучи машин, на 1 таки пошло кое-что не так и оно таки перестало грузиться. Это наполовину мой факап - конфиг не failsafe был. Но от этого ехать в ДЦ нифига не радостнее.

> Но вы правы, тут я не последователен, протоколы DNSsec,FTPs и DHCPsec должны
> быть интегрированы в БИОС(сейчас для удалённой загрузки используются их несекюрные версии,
> причём DNS в БИОС нет вообще)

DNSSec вообще фуфельный (RSA-1024 врядли долго осталось). FTPs это вообще нечто мало кем используемое, он вообще сочетает минусы всех мыслимых технологий и застрянет на первом же фаере и нате. Да и DHCPsec это нечто экзотическое. Сразу +20 к граблям администрирования. Оно админам надо?

>>И чем это будет отличаться от - внезапно - BMC?
> Тем что этот блок будут ставить только те, кому для контроля сервера
> по какой-то причине нужен аппаратный отладчик, остальным имхо хватит и удалённого
> включения с перезапуском по WoLsec.

Как вы уже поняли будет соблазн интегрировать все в фирмвару сетевки или чего там и получится тот же BMC только похабнее. Чем WoL вообще помогает от "система не грузится" черт его знает.

> Но вы правы, я предложил не самое оптимальное решение и этот вопрос
> натолкнул на правильное решение, которое в своё время и следовало сделать.

Как вариант - нечто типа coreboot/uboot с (относительно) неизменным Linux в системной флехе и вот он может грузить ... в принципе что угодно как угодно. Даже и покруче GRUB. В принципе такой сетап и без BMC может обойтись и довольно сложно убить. Но апдейты и на это иногда надо будет, с тем же риском кирпича. И таки low power проц способный и включить основную систему и перекатать образ оси независимо от живости основного - по своему гибкое и красивое решение. С минимумом ограничений. Единственный реальный критерий с которым затык - опенсорсность фирмвары, пожалуй. Вон те, толстые, так себе и сделали. И это неплохо для них работает. Просто они не продают свои сервера на публику, они для себя это все.

> Я отлично понимаю что такое устройство по сути есть внешний BMC, про
> главный недостаток которого вы не указали: ему нужен дополнительный порт, что
> и стало причиной столь лёгкого внедрения BMC интегрированных в компьютер.

Ну как бы если есть внешнее устройство - всегда возникает идея сэмулировать его функции тем что уже было. Результат тот же но дешевле и сердитее.

> На сетевой карте просто надо сделать отдельный порт на который отправлять все
> предназначенные для BMC паеты, для отличия которых помечать IP пакет особым образом.

Это к сожалению накладывает еще больше лимитов на архитектуру железа. А вон то вообще никак особо не лимитирует структуру основной системы.

> 1. WoLsec не нужен, просто на сетевой карте делается отдельный внутрикорпусный порт
> на который отправляются все пакеты имеющие пометку BMC и дублируются пакеты
> DNS,DHCP и их секюрных версий.

Собссно у BMC часто и есть отдельный порт, по примерно тем же соображениям. Зачем ему на пути основного трафика стоять вообще хз. Хотя из экономии соблазнительно через 1 порт все и вся делать, так получается какой-нибудь гаденыш типа ME и vPro/AMT... основная проблема в том что это напрочь прориетарная фирмвара, от интеля, жестко подписаная их ключами и незаменяемая. А доверять тем господам под дулом пистолета^W^W ключа в efuses - такое себе.

> 2. А там пользователь сам решает какой BMC ему использовать, такой что
> умеет только нажимать кнопки Powe/Reset и поддержку последовательного COM порта для
> взаимодействия с БИОСом.

Собссно и сейчас никто не запрещает что-то такое делать. Вон та идея похожа на BMC только с кучей допущений и почему-то завязаный на именно сетевку. Для менеджмента много трафа не надо, так что быть частью крутой сетевки ему вообще опционально.

> Или такой что ещё умеет в эмуляцию монитора,клавиатуры и блюрея.

Это как-то сложно уж очень. И зачем блюрей? Можно просто usb mass storage device + usb hid. Дофига одноплатниов на линухе такое на раз изобразит.

> Или такой что имеет на борту софт для отладки программ и оборудования
> и умеет в шины JTAG, SMBus, IPMI и что там есть ещё.

Любой одноплатник с линем. И получится BMC очередной :)

> Или не использовать BMC вообще(например сервер размещён не в ДЦ, а локально)

Вообще вы меня навели на мысль: загрущчик не трогать, им стартить "readonly" linux а оттуда уже что угодно и как угодно наруливать а потом kexec(). В принципе даже есть похожие штуки. Но для сохранности ЭТОМУ лучше таки в флешке жить, а не в основном стораже. На всякий случай.

> 3. Поддержка удалённой загрузки в БИОС не нужна так как соответствующий функционал
> делается соответствующим внешним BMC, всё что должен уметь БИОС это только
> грузить GRUB с отдельного небольшого накопителя(возможно эмулируемого BMC).

Если уж эмулировать накопитель можно с него не BIOS а что поприличнее бутануть типа линуха небольшого. А для мазохистов - BMC может и JTAG в принципе сносно GPIO изобразить но подывать через него x86 вы точно не захотите. Дебажнуть совсем непонятки еще может быть, но не более.

> Всё получается максимально просто, не дорого, и разделённым на понятные и подбираемые
> под нужды пользователя функциональные блоки.

На самом деле BMC открытых есть - просто вон тем неймется, как же это без них и их проприетари то :)

> И вот если бы так сделали то это было бы нормально и
> вызывало минимум вопросов и обвинений в создании бекдоров, так как не
> давало возможностей для их создания и навязывания.

Вообще ряд похожих штук есть. Но есть и вот сабж, с каким-то самоназваным "стандартом" чтобы под его эгидой проприетару всучивать.

Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 25-Июл-23, 19:38 
> А точно ими? Или это бывает как-то так: ты тут, датацентр - у черта на рогах

бывает и проще - ты тут, оно вон через коридор за двойным шлюзом (поэтому в общем не слышно) но войти туда ты почему-то не хочешь. И тем более провести там пол-часика раком-боком на карачках на полу под стойкой (желательно в наушниках для стрельбы и шлеме с замкнутой системой дыхания) разбираясь чего это оно вот. Или даже не разбираясь рутинно обновить биос потому что в новом вроде твою проблему обещали порешать.

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

> Подразумевает наличие у сетевки проца. С доступом к сети. And we're back to square one.

причем в ранних интеловских ME так и было. Но потом оказалось что безопасности это не добавляет, а контроля над системой у сетевухи нет и если оно вдруг не включилось - возвращаемся к походу вот туда.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

78. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 26-Июл-23, 00:21 
>> Подразумевает наличие у сетевки проца. С доступом к сети. And we're back to square one.
> причем в ранних интеловских ME так и было.

Когда ты пешком под стол ходил, а БИОС надёжно хранились в диодных матрицах ПЗУ и ни каких МЕ не было и в помине у сетевой карты 3Com был трёхпиновый разъём с обозначением WoL для которого был комплектный кабель который должен был вставляться в такой же разъём на материнской плате и как я понимаю он должен был работать аналогично кнопке Power, но только в том случае если в БИОС сделана соответствующая настройка.  
Правда производители материнок этот разъём на свою продукцию никогда не ставили и по этому так этот WoL и усох до того, что он есть сейчас.  

>оно вон через коридор за двойным шлюзом (поэтому в общем не слышно) но войти туда ты почему-то не хочешь. И тем более провести там пол-часика раком-боком на карачках на полу под стойкой  

Даже если отвлечься от моих фантазий о FTPs то прямо сейчас ты можешь [с помощью DHCP сообщить БИОС с какого tFTP сервера грузить pxegrub v0.97](https://www.gnu.org/software/grub/manual/legacy/grub.html#Ne...) и держать grub.cfg,ядро и инитрд на удобном тебе компьютере.  
Это особо хорошо при отладке, так как для обновления инитрд достаточно отмонтировать его образ, после чего можно перегружать кнопкой Reset отлаживаемый компьютер.  

Конечно tFTP и DHCP не безопасны, да и GRUB и сейчас по моему не умеет в DNS, но ведь я и предложил его доразвить до полной функциональности с FTPs,DHCPsec DNSsec(это всё реально существующие протоколы)

С чего вы оба пишите с умным видом про всякие трудности в  то время как то что я предлагаю их хорошо и удобно решает?

Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 26-Июл-23, 09:48 
> Правда производители материнок этот разъём на свою продукцию никогда не ставили

ставили, просто ты был нище6род и не мог себе позволить не китайское безымянное г-но.
Проблема что этот разъем предполагал что питание у системы как бы выключено, только вот как бы не совсем, а те блоки так редко умели. Иначе сетевая плата, знаешь ли, не работает и не сможет принять твой волшебный пакет.
Дальше отдельная история с довести управление питанием всего блока до чудо-коннектора (нет, решение в лоб не очень подходит, глючная сетевая плата не должна спалить блок, она должна не работать только сама по себе).

Причем, как ты правильно прочитал в викивракии - это управление - само управляемое (чтобы тебе не повключали чего не надо кто не надо - хотя на деле разумеется - так себе была заshita - любой васян в локальной сети мог) - и, как ты думаешь, кто и что должно им - управлять и как?

Т.е. этот предок AMT (это именно оно) умел примерно ничего (включил, молодец - а теперь надо выключить и без поездки в караганду) но при этом требовал кучу специальных костылей И в сетевухе И в матери ТОЛЬКО ради включить питание.

Поэтому когда задачки стали посложнее - уже мало вкл-выкл, а надо, к примеру, посмотреть логи ECC прежде чем решать, поедешь ты таки в караганду с запасным модулем, или обойдется - сделали нормальное _универсальное_ инженерное решение. Если нам надо управлять разными деталями системника - сделаем универсальные протоколы и универсальные механизмы этого управления, пригодные для всего и сразу.
И отдельный доступ к ним, в обход стандартной сетевухи, подальше от васянов в соседнем порту.

И только уже потом появились блейды, которые вообще не имеют никаких интерфейсов в принципе. Их там некуда стало размещать, места и так мало, и не нужны они никому вообще, не набегаешься. Разумеется, поскольку решение изначально универсальное - никто не стал для standalone городить какое-то отдельное.

Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 26-Июл-23, 12:25 
>Поэтому когда задачки стали посложнее - уже мало вкл-выкл, а надо, к примеру, посмотреть логи ECC прежде чем решать, поедешь ты таки в караганду с запасным модулем, или обойдется - сделали нормальное _универсальное_ инженернзиое решение.  

Если комп не в состоянии загрузить ядро и initrd который ничего не имеет кроме sshd и утилиты для чтения логов ECC то в караганду придётся ехать в любом случае, потому что такое возможно только при полной аппаратной поломке одного из узлов компьютера.  
А если он такой базовый initrd прогруить может и всякие утилиты, в том числе для чтения логов ECC с него доступны то зачем добавлять в процессор не лишний функционал который может потенциально позволить утащить из твоего компа расположенные в ОЗУ пароли или ключи шифрования?  

Это базовая логика в которую по непонятной причине неспособны большинство компьютерщиков и вот приходится тебе объяснять то, о чём ты должен подумать и сам.  

Хотя конечно посмотреть лог сбоев на непрогружаемом компьютере полезно так как можно сразу приехать с нужными запчастями.
Но разве для этого нужен встроенный в процессор BMC?  
Нет, для этого достаточно чтобы логи писали на spi флешку.
Тогда зачем весь этот встроенный BMC с доступом ко всем устройствам и ОЗУ компьютера?  
И даже если такой доступ нужен, то почему не ограничились набором шин подключаемых к отдельному миникомпьютеру что не только безопаснее, но и удобнее?

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

>а теперь надо выключить и без поездки в караганду  

Для этого достаточно чтобы ВНЕШНИЙ BMC мог удалённо через оптопару замкнуть контакты кнопок питания и сброса, как максимум если тебе ну ни как в ОС не поставить сервер ssh  то ещё эмулировать дисплей и клавиатуру.  
Всё остальное это ненужное усложнение требующие огромных затрат на разработку и упорный энтузиазм в которой заставляет задуматься о причинах его(энтузиазма) появления и стойкого существования.

И главное, я ведь не говрю что у тебя не должно быть возможности подключить к своему компу через JTAG и IPMI удалённый отладчик и делать всё что тебе захочется.  
Ради бога, ставь платку, подключай.  
Но у других должна быть возможность этого не делать, потому как некоторые админы перед отправкой сервера в ДЦ специально механически отрывают у материнки все неиспользуемые порты, на всякий случай, чтоб чего не вышло.

Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 26-Июл-23, 14:39 
> Если комп не в состоянии загрузить ядро и initrd который ничего не имеет кроме sshd и утилиты для
> чтения логов ECC то в караганду придётся ехать в любом случае, потому что такое возможно только

в твоем игрушечном варианте - да. В моем - нет. Вон не грузится та хрень - и хрен с ним.
(управление питанием там осталось, оно видимо в шасси а не в самом лезвии) Обычная операционка пока жива, значит поводов ехать нету.

> то зачем добавлять в процессор не лишний функционал

ты из тех бабушек что до сих пор системный блок называешь - процессором?

BMC - ничего никуда не добавляет, это отдельный компьютер с собственным процессором сбоку от основного (поэтому и его фейл ничего не рушит - сдох и х-й с ним. У китайского блейда можно сресетить отдельно от лезвия, у американского хрен тебе.) Его задача - обеспечить удаленное управление и диагностику, независимое от того что там происходит с основной системой, есть ли у нее для этого драйверы и приложения и не рассыпалась ли она сама по себе или с небольшой помощью глюков аппаратуры.

Наиболее близкий и понятный тебе васян-аналог - это если мы подоткнем к входам-выходам сервера какой-нибудь рпи-подобный уродец, только еще умеющий притворяться разными usb-устройствами и перехватывать картинку с видеовыхода (если бы он у той штуки на самом деле существовал), и попутно управлять розеткой, чтоб в крайнем случае физически отрубить питание.
Но это тоже неточно - у него не будет доступа к логам платформы (и вот те ошибки ecc или сбои FC-контроллера придется ловить через операционку, а она может ничего не поймать или грохнуться так что и не соберешь с нее причину).


> И главное, я ведь не говрю что у тебя не должно быть возможности подключить к своему компу
> через JTAG и IPMI удалённый отладчик и делать всё что тебе захочется.  
> Ради бога, ставь платку, подключай.  

нет, извини, нет. У меня их около двух сотен штук сейчас. А бывало и за тысячу.
Как ты думаешь, мне очень хочется попердолиться по настоящему, с каждым (даже если б была теоретическая возможность, т.е. имей те платы настоящие коннекторы)?
Сколько в таком раскладе у тебя будет самодельных кривых контактов и какова вероятность что каждый третий отвалится еще при перевозке?

> Но у других должна быть возможность этого не делать, потому как некоторые админы перед
> отправкой сервера в ДЦ специально механически отрывают у материнки все неиспользуемые порты,

мне кажется, вот такие больные и должны страдать.

Ответить | Правка | Наверх | Cообщить модератору

86. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 26-Июл-23, 15:51 
> лезвии) Обычная операционка пока жива,

Значит ты или твоё средство автоматизации может на неё зайти и выполнить удалённые действия.


> BMC - ничего никуда не добавляет, это отдельный компьютер с собственным процессором
> сбоку от основного

Не только в этой ветке, а во всей теме под BMC подразумевается комплекс из встроенного в  ЦПУ небольшого процессора и запускаемого в БИОС/EFI гипервизора системы, к которым можно получить доступ из сети через отправив специальные пакеты на сетевой интерфейс материнской платы.  

Против используемого тобой варианта BMC как внешнего устройства никто не возражает.  
Даже я не возражаю что ты бы понял если бы более внимательно читал мои посты.

Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 26-Июл-23, 17:11 
> Значит ты или твоё средство автоматизации может на неё зайти и выполнить удалённые действия.

но если повиснет любимая системдрянь при перезапуске - уже не зайдешь. Так и будешь вслепую гадать - там еще тикает какой-нибудь глобальный таймаут и есть шансы через пол-часа увидеть консоль, или уже все и можно собираться в дорогу. Прошлый раз повезло.

Поэтому ситуация мягко говоря нехорошая и требует рано или поздно ремонта или замены. Но не катастрофа.

> Не только в этой ветке, а во всей теме под BMC подразумевается комплекс из встроенного в  ЦПУ
> небольшого процессора

я не знаю кем и какими дятлами там что-то "подразумевается", но bmc - baseboard management controller. Ни в какое "цпу" он не встроен, он от него по максимуму изолирован, совершенно отдельное явление. Подключен к южному мосту стандартным pci (помимо отдельного usb и прочего) и к куче всяких spi внутри отдельных компонент.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 26-Июл-23, 19:26 
>я не знаю кем и какими дятлами там что-то "подразумевается",  

А ты бы относился к другим с большим вниманием, так глядишь и не смешил народ беготнёй за собственными иллюзиями.

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от Oe (?), 22-Июл-23, 18:03 
Дык 99% таких серверов используются для скам проектов, всяких там прокси ферм для коллцентров и т.п. Что плохого в том что они получили по заслугам?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

31. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +4 +/
Сообщение от Аноним (31), 22-Июл-23, 20:55 
Богатое у тебя воображение. По заслугам как обычно получат самые не причастные, а те у кого скам и коллцентры о своей безопасности нормально так беспокоятся.  
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +11 +/
Сообщение от Аноним (2), 22-Июл-23, 12:28 
Всем про это говорили, но находились те кто в это не верили. Не удивлюсь что они не поверят даже после выхода официальной новости. Разве может быть искоробочное решение небезопасным.
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +4 +/
Сообщение от Sw00p aka Jerom (?), 22-Июл-23, 13:19 
DMTF’s Redfish® is a standard designed to deliver simple and secure management for converged, hybrid IT and the Software Defined Data Center (SDDC).

главное написать волшебное слово "secure"

ps: RIP K.M.

Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от Аноним (7), 22-Июл-23, 15:04 
K.M. - да, жалко. А вот кое-какому геймеру будет стекловатой. Он, наверное, на респаун надеялся, когда с такими серьёзными людьми повёлся.
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от Аноним (18), 22-Июл-23, 17:05 
Может вы ещё и в TPM не верите?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +3 +/
Сообщение от Sw00p aka Jerom (?), 22-Июл-23, 17:09 
> Может вы ещё и в TPM не верите?

не хочу задевать чувства верующих, поэтому воздержусь от ответа на данный вопрос :)

Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (5), 22-Июл-23, 14:44 
> …"No Auth" при обращении с IP-адресов внутреннего интерфейса или интерфейса USB0.

Шо, опять?

Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от пох. (?), 22-Июл-23, 16:39 
В смысле? Это-то штатная фича, нахрена еще один ауф в закрытой сети для oob management?

Нештатная в том что внезапно слепоглазая система плохо отличает где там usb0, а где васян из Гондураса.

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –4 +/
Сообщение от Oe (?), 22-Июл-23, 15:27 
Да кому нужны эти ваши сервера в 2023 кроме двух с половиной китов? Да и 99% серверного кода перемещено на клиентскую сторону. Ну не закажет полтора человека новомодных сушЕй, не вызовет лучшее из лучших такси, ох, какая беда то
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +3 +/
Сообщение от Аноним (10), 22-Июл-23, 15:59 
Если тебе не надо высылай мне адреса, можно даже с паролями доступа.
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +2 +/
Сообщение от Аноним (19), 22-Июл-23, 17:07 
Не напишет бред на опеннете...
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

23. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –2 +/
Сообщение от Oe (?), 22-Июл-23, 17:51 
Дык для опеннета достаточно перешитого андроид свистка. Крупные компании юзают сервера от китов, где таких проблем с BMC не возникает
Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 23-Июл-23, 13:53 
э... блжд...

(хотя... да... у меня с декабря не работает одна из консолей в шасси. "От жырных котов", да.
Капот открывали, по колесу стучали - не работает. Хз что с ней, linoops наверное у ей внутре. Нет удаленного управления, нет проблемы, съели, хаксоры?! Проблема правда в том что этот сервер не всегда успешно загружается. Но я уже повесил на него красивую табличку "не перезагружать!" - ачивка выполнена.)


Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от Аноним (-), 23-Июл-23, 17:43 
> Но я уже повесил на него красивую табличку "не перезагружать!"
> - ачивка выполнена.)

А это видимо complete solution уровня бох^W пох :). Экспертиза в системной интеграции, не какая-то фигня.

Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  –1 +/
Сообщение от пох. (?), 23-Июл-23, 18:29 
ну да, ты-то умеешь лучше. А, нет, этот -  опять только в перепрошивку свистков умеет...

Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (71), 25-Июл-23, 07:04 
> ну да, ты-то умеешь лучше. А, нет, этот -  опять только
> в перепрошивку свистков умеет...

Не, я таки умею в решение системных проблем в моих системах. И все же менее ламерскими способами чем табличка.

Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 25-Июл-23, 16:11 
>> ну да, ты-то умеешь лучше. А, нет, этот -  опять только
>> в перепрошивку свистков умеет...
> Не, я таки умею в решение системных проблем в моих системах. И

которые сам себе и создал? Ну да, ну да. Как за уровень свистков выберешься - приходи снова.


тогда и посмотрим, кто тут "неламер".

Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (-), 26-Июл-23, 18:53 
> которые сам себе и создал? Ну да, ну да. Как за уровень
> свистков выберешься - приходи снова.

Пох ну тебе ли с твоим фееричным скиллом прострела пяток говорить о создании себе проблем? :) Ты умудряешься найти более 9000 системных проблем там где их быть вообще не должно.

> тогда и посмотрим, кто тут "неламер".

Быть неламером по твоим стандартам - это, кажись, ну такое себе. У тебя очень странные понятия о подобных вещах. А как инженер я таки буду презирать тех кто "решил проблему" перевалив ее на окружающих табличкой.

Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 26-Июл-23, 20:54 
> Ты умудряешься найти более 9000 системных проблем там где их быть вообще не должно.

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

> А как инженер я таки буду презирать тех кто "решил проблему

которую сам бы ты не смог решить вообще никак - стоял бы и мигал глазками - "это мы не проходили, у свистка такого нет". Ну вот у кого какие "стандарты".

Ответить | Правка | Наверх | Cообщить модератору

92. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от Аноним (-), 26-Июл-23, 22:43 
> согласно фантазиям живущих в подвале перешивальщиков андроидных свистков,
> знакомых с окружающим миром в основном по викивракии.

Согласно - тадам! - твоим же собственным сообщениям. Где ты все время ноешь как у тебя в линухе ничего не работает и фиксишь проблемы развесовкой табличек.

Возможно ты хотел сказать какой линух плохой. Но кросс-корелируя с своим опытом и другими идеями насчет фиксов проблем - и тем фактом что таких проблем у других обычно нет, вывод скорее сдвигается в пользу твоей отборнейшей ж@порукости и некомпетентности. Ты как обычно облажался со своим хитрым планом.

Более того - ты сам же и дискредитировал свои увещевания про юниксвэй своими же рассказами что юзаешь винду. По поводу чего твое мнение как и что должно быть в линухе вообще не заслуживает внимания: майкрософту рассказывай как пилить фичи, имхо.

>> А как инженер я таки буду презирать тех кто "решил проблему
> которую сам бы ты не смог решить вообще никак - стоял бы
> и мигал глазками - "это мы не проходили, у свистка такого
> нет". Ну вот у кого какие "стандарты".

Я довольно креативный и мощный когда вопрос касается решения проблем. Особенно с опенсорсным софтом. И как-то вот обычно более продвинутые методы получаются. Это и есть основание для презрения к твоей технической компетенции - а точнее, ее отсутствию. Извини но это тот случай когда за человека говорят дела, как он решил проблему. Если вот так - ну, ок, ты вообще не инженер. Табличку на сервер с таким же успехом может и уборщица налепить. Не больно какой уровень чтобы им козырять на публику. Но ты настолько зазнался что даже такие мелочи осознать не способен.

Ответить | Правка | Наверх | Cообщить модератору

93. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 26-Июл-23, 23:44 
> Согласно - тадам! - твоим же собственным сообщениям. Где ты все время
> ноешь как у тебя в линухе ничего не работает и фиксишь

чувак - это называется - опыт. Когда человек может рассказать как что-то может пойти не так в том что тебе кажется образцово работающим. Нет, не только в линуксе. Вот коммерческое решение за много денег тоже, оказывается, может оказаться не совсем идеальным, и я полагаю полезным (не тебе) людям об этом знать, а не слепо верить что там особая магия.
А как оно просто работает - рассказывать неинтересно.

> Более того - ты сам же и дискредитировал свои увещевания про юниксвэй
> своими же рассказами что юзаешь винду. По поводу чего твое мнение

меня не интересует мнение обо мне местных психопатов, тебе что неясно-то?

Я юзаю разные инструменты, выбор в разрезе шва6одки или коммерческих решений - вообще не рассматривается.
Только и исключительно пригодность этих инструментов для конкретного дела.

> Я довольно креативный и мощный когда вопрос касается решения проблем. Особенно с

особенно с. Если проблема _известным_и_привычным_тебе_ опенсосным софтом не решается вообще никак - ты верещишь "это мы не проходили, это нам не задавали".

> опенсорсным софтом. И как-то вот обычно более продвинутые методы получаются. Это

Пока что у тебя только хорошо сказочки о более продвинутых методах получаются.
А как спросишь что конкретное - так опять "это мы не проходили", и внезапно опенсосный софт еще и делится на правильный и неправильный и его тоже чинить не надо, потому что ты так сказал.

> и есть основание для презрения к твоей технической компетенции - а
> точнее, ее отсутствию. Извини но это тот случай когда за человека
> говорят дела, как он решил проблему. Если вот так - ну,

как ты бы решал эту проблему? Ах, ну да, ну да, это не твоя проблема, вот твои перешитые свистки...

> ок, ты вообще не инженер. Табличку на сервер с таким же успехом может и уборщица налепить

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

Я кстати подобный (попроще-подешевле) сервер когда-то использовал для легкого троллинга соискателей должностей админов и прочего девляпса. Потом перестал, а то работать некому.

(ага-ага, глазками хлоп-хлоп... это мы не проходили... и условия работы тут у вас какие-то не такие... пугаются и дальше начинают путаться в показаниях даже там где на самом деле что-то знают и умеют и это производит плохое впечатление на начальство.)

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от penetrator (?), 22-Июл-23, 22:53 
а ты свой мусор куда написал? он хранится где?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

48. Скрыто модератором  +/
Сообщение от C00l_ni66a (ok), 23-Июл-23, 19:51 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. Скрыто модератором  +1 +/
Сообщение от Аноним (9), 22-Июл-23, 15:46 
Ответить | Правка | Наверх | Cообщить модератору

11. Скрыто модератором  +4 +/
Сообщение от Аноним (10), 22-Июл-23, 16:00 
Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором  +/
Сообщение от Аноним (19), 22-Июл-23, 17:08 
Ответить | Правка | Наверх | Cообщить модератору

22. Скрыто модератором  +2 +/
Сообщение от Аноним (-), 22-Июл-23, 17:45 
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

26. Скрыто модератором  +/
Сообщение от Аноним (26), 22-Июл-23, 18:38 
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

27. Скрыто модератором  +/
Сообщение от Аноним (2), 22-Июл-23, 19:00 
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от InuYasha (??), 24-Июл-23, 15:14 
Кстати, была же, вроде, альтернатива в виде открытого проекта. OpenBMC.
Кто-нибудь вообще пробовал?
Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +1 +/
Сообщение от медвед (?), 24-Июл-23, 18:07 
> Кстати, была же, вроде, альтернатива в виде открытого проекта. OpenBMC.
> Кто-нибудь вообще пробовал?

А вот признайся мужык - ты ведь сюда - не на охоту ходишь?!


Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от torvn77 (ok), 26-Июл-23, 01:23 
> Кстати, была же, вроде, альтернатива в виде открытого проекта. OpenBMC.
> Кто-нибудь вообще пробовал?

Кому надо пробовал, но даже если ей пользоваться то как удалить из компа проприетарный BMC?

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

102. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от InuYasha (??), 27-Июл-23, 14:07 
Вообще - довольно легко. По крайней мере, на обычных тачках. Если ты о "залить нулей" - да. Если про "отпаять БМК" - то тоже да. Причём, у меня есть мамки, на которых он вообще выниматеся, как и ТПМ. Очень люблю эти мамки.
Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от onanim (?), 27-Июл-23, 09:57 
> Кстати, была же, вроде, альтернатива в виде открытого проекта. OpenBMC.
> Кто-нибудь вообще пробовал?

это открытая прошивка для закрытого процессора :)

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

101. "Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо вып..."  +/
Сообщение от пох. (?), 27-Июл-23, 12:12 
процессор там положим обычный arm, и на него наверное даже спеки можно где-то откопать (но это неточно).

Вот где ты возьмешь спеки на его взаимодействие с разнообразными интерфейсами основного компа - хотел бы я знать.
ну даже найдешь ты методом тыка шину и окажется она обычным i2c - а дальше что?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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