The OpenNET Project / Index page

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

Уязвимость в прошивках AMI MegaRAC, вызванная поставкой старой версии lighttpd

14.04.2024 22:35

В прошивках MegaRAC от компании American Megatrends (AMI), которые применяются в контроллерах BMC (Baseboard Management Сontroller), используемых производителями серверов для организации автономного управления оборудованием, выявлена уязвимость, позволяющая неаутентифицированному атакующему удалённо прочитать содержимое памяти процесса, обеспечивающего функционирование web-интерфейса. Уязвимость проявляется в прошивках, выпускаемых с 2019 года, и вызвана поставкой старой версии HTTP-сервера Lighttpd, содержащей неисправленную уязвимость.

В кодовой базе Lighttpd данная уязвимость была устранена ещё в 2018 году в версии 1.4.51, но исправление было внесено без присвоения CVE-идентификатора и без публикации отчёта с описанием характера уязвимости. В примечании к выпуску, было упомянуто об устранении проблем с безопасностью, но основное внимание было акцентировано на уязвимости в mod_userdir, связанной с использованием символов ".." и "." в имени пользователя.

В списке изменений также была упомянута проблема с обработкой HTTP-заголовков, но данное исправление было пропущено разработчиками прошивки и не перенесено в состав продукта, так как примечание о потенциальном устранении уязвимости класса use-after-free присутствовало лишь в тексте коммита, а в общем списке изменений не было указано, что ошибка приводит к обращению к памяти после освобождения.

Уязвимость позволяет прочитать содержимое памяти за пределами выделенного буфера. Проблема вызвана ошибкой в коде слияния HTTP-заголовков, применяемом при указании нескольких экземпляров HTTP-заголовка "If-Modified-Since". При обработке второго экземпляра заголовка lighttpd выделял новый буфер, чтобы вместить объединённое значение и освобождал память под буфер, в который было помещено значение из первого заголовка. При этом указатель con->request.http_if_modified_since не изменялся и продолжал указывать на уже освобождённую область памяти.

Так как данный указатель использовался при операциях сравнения содержимого заголовка If-Modified-Since, результат которых приводил к генерации разных кодов возврата, атакующий мог путём перебора угадать новое содержимое памяти, которую ранее занимал первый буфер. Проблема могла использоваться в сочетании с другими уязвимостями, например, для определения раскладки памяти для обхода механизмов защиты, таких как ASLR (рандомизация адресного пространства).

Наличие уязвимости подтверждено в серверных платформах Lenovo и Intel, но данные компании не планируют выпускать обновления прошивок из-за истечения времени поддержки, использующих данные прошивки продуктов, и низкого уровня опасности уязвимости. Проблема проявляется в прошивках к платформам Intel M70KLP и Lenovo HX3710, HX3710-F и HX2710-E (уязвимость присутствует среди прочего в последних версиях прошивок Lenovo 2.88.58 и Intel 01.04.0030). Дополнительно сообщается, что уязвимость в lighttpd также проявляется в прошивках к оборудованию Supermicro и в серверах, на которых используются BMC-контроллеры компаний Duluth и ATEN.

  1. Главная ссылка к новости (https://www.binarly.io/blog/li...)
  2. OpenNews: Уязвимости в прошивках AMI MegaRAC, позволяющие удалённо выполнить код на уровне BMC-чипа
  3. OpenNews: Атака PMFault, позволяющая вывести из строя CPU на некоторых серверных системах
  4. OpenNews: PixieFAIL - уязвимости в сетевом стеке прошивок UEFI, применяемом для PXE-загрузки
  5. OpenNews: Уязвимость в прошивках BMC-контроллеров, затрагивающая серверы многих производителей
  6. OpenNews: LogoFAIL - атака на UEFI-прошивки через подстановку вредоносных логотипов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60982-ami
Ключевые слова: ami, bmc, lighttpd, intel, lenovo, supermicro
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (37) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 23:05, 14/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Забавно, что lighttpd преподносит себя как "_secure_, fast, compliant, and very flexible web server". Secure в их понимании видимо скрытое устранение уязвимостей без лишней огласки. А ведь если копнуть там  можно нарыть и такие прекрасные вещи https://redmine.lighttpd.net/issues/2700 для которых до сих пор нет CVE.
     
     
  • 2.6, YetAnotherOnanym (ok), 23:35, 14/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То ли дело программные продукты, которые преподносят себя как "_insecure_, slow, incompliant and very rigid". У них-то такого никогда не может быть.
     
     
  • 3.8, Аноним (8), 23:54, 14/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > То ли дело программные продукты, которые преподносят себя как "_insecure_, slow, incompliant and very rigid". У них-то такого никогда не может быть.

    У них есть одно существенное преимущество по сравнению с lighttpd: честность.

     
     
  • 4.21, Аноним (21), 08:29, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как ты это преимущество монетизируешь?
     
     
  • 5.35, Аноним (8), 15:10, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Репутация — очень ценный актив любой нормальной компании.
     
  • 5.36, scriptkiddis (?), 21:04, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А таким как ты бы весь мир монетизировать, все в монетках
     
  • 4.25, YetAnotherOnanym (ok), 09:11, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это очень важно в эксплуатации, да.
     
     
  • 5.32, Аноним (-), 10:51, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, прикинь это важно.
    Если разраб пытается замести уязвимости под ковер, то это проблема на порядок больше, чем софтина где их больше, но их нормально закрывают.

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

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

     
  • 2.13, Аноним (13), 00:55, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так это не проблема с безопасностью была, а для кого надо функция. Кому надо функция перестала быть нужна, вот её и убрали. А кто софт бесплатно юзает, а сам его не аудирует - тот сам виноват. AS IS, читать лицензию надо.
     
     
  • 3.16, Аноним (16), 07:32, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Простой пользователь не обязан знать как работает программа.
     
     
  • 4.20, Прадед (?), 08:25, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так он и не знает
     
  • 4.29, Аноним (29), 10:28, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Незнание как работает программа не освобождает от ответственности за её использование.
     
     
  • 5.30, Прадед (?), 10:33, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Шах и мат, юзер
     
  • 2.40, тыквенное латте (?), 21:35, 16/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    никакого скрытого устранения уязвимостей, от которых тебя зохекают, не вриЖ
    lighttpd.net/2016/1/2/1.4.39/


    Что до идти выпрашивать CVE в 2015 году - ну так сесуриту войтхэккеры для чего существуют?
    Он взял и написал в чейнджлоге, и сделал новость. Как и полагается. А белки-истерички могут идти.

     
  • 2.41, Аноним (41), 20:21, 17/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    История про упаковку всего и вся в один блоб. Содержимое блоба никто не знает, автор не обновляет, самостоятельно тоже ничего не доступно.

    Сам по себе lighttpd тут не особо причём. Дело в способе использования зависимостей автором блоба.

     

  • 1.4, Аноним (4), 23:06, 14/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Вообще конечно прикольно. Фикс был готов много лет назад, но вендо его пропустил. А теперь не будет обновлять, потому что срок поддержки вышел. Это для таких компаний наверно хотели ввести ответственность за дыры в стороннем ПО, которое они заюзали у себя
     
     
  • 2.5, нах. (?), 23:32, 14/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И внезапно - вреда от этой увизгвимости - никакого. Какой вредный вендор, не хочет херней пострадать.

     
  • 2.11, Карлос Сношайтилис (ok), 00:13, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То что вендор не будет исправлять уязвимость в продукте, у которого истек EOL, в принципе нормально, кроме того, из вины в поставке дырявой версии нет.

    А вот господа из lighttpd поступили не просто по-свински, а, буквально, совершили диверсию.

    У всех крупных организаций существует процесс обнаружения уязвимостей ПО. Уровень разный, но база – проверка наличия CVE по номеру версии. Если CVE не опубликована, а исправлена втихую, то подобные сканеры не будут ругаться и версия уйдет в поставку.

    PS: Не зря я вчера писал, что ребятки не вызывают доверия из-за кривого сайта. Да, звучит смешно, но чуйка не подвела.

     
     
  • 3.12, Аноним (4), 00:49, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Их вины в поставке дырявой версии нет? Ахахах, серьезно? А  чья тут вина, что дырявая версия в их продукте оказалась?

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

     
     
  • 4.14, Карлос Сношайтилис (ok), 01:37, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Они тоже не обязаны, прикинь?

    Срок поддержки истёк, делайте чо хотите.

    А вот если бы разработчики Lighttpd не крысятничали, то пользователи получили бы обновление.

    Но имеем что имеем – никто не виноват, но все – в заднице.

     
     
  • 5.15, Аноним (15), 02:42, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Пришли какие-то мажоры , заюзали Lighttpd по тихому (весь доход лично себе), а крайние теперь апстрим? Смешно...
     
     
  • 6.19, Карлос Сношайтилис (ok), 08:22, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё так, если лицензия позволяет, мажоры будут юзать и всю прибыль забирать себе.
    Лицензию выбирают разработчики и это их выбор.
     
     
  • 7.22, Аноним (21), 08:33, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так и какие уязвимости публиковать тоже васян выбирает. Тем более он может с того что втихую добавил и в тихую убрал получить больше дохода чем эти корпы. А крайние пользователи, которых нагнули.
     
     
  • 8.24, Карлос Сношайтилис (ok), 08:40, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вероятность этого не нулевая, но я всё же думаю, что разработчики просто портит... текст свёрнут, показать
     
  • 5.17, Аноним (17), 08:00, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Они тоже не обязаны, прикинь?
    > Срок поддержки истёк, делайте чо хотите

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

     
     
  • 6.23, Карлос Сношайтилис (ok), 08:36, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну расскажи нам про волшебные сканеры подобных ошибок, а то про них никто не знает, все только "отмазки детского сада" лепят.

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

     
  • 5.31, Аноним (31), 10:46, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >А вот если бы разработчики Lighttpd не крысятничали, то пользователи получили бы обновление.

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

     
  • 3.27, Аноним (27), 09:36, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То ли дело angie, там даже по 15 рублей платят?
     

  • 1.7, Аноним (7), 23:49, 14/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если ставить BMC контроллер слушать не в локалке а в инет, то тут уже не вендор, а такого админа надо гнать мокрыми тряпками.
     
     
  • 2.9, Аноним (8), 23:55, 14/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Банальный DNS rebind — и локальная дыра становится глобальной.
     
     
  • 3.10, Аноним (7), 00:11, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И как ты дальше будешь хекать мой сервер через это? Тут нужно знать адресс хоста BMC для которого делать rebind,
    потом найти CSRF (например добавить юзера), заставить админа кликнуть на левую ссылку, а потом тыкнуть в консоль,
    которая в тех версиях еще в Java аплете. Ну так себе цепочка.
     
     
  • 4.26, Аноним (27), 09:28, 15/04/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.33, Аноним (33), 10:57, 15/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Наличие уязвимости подтверждено в серверных платформах Lenovo и Intel, но данные компании не планируют выпускать обновления прошивок из-за истечения времени поддержки, использующих данные прошивки продуктов, и низкого уровня опасности уязвимости.

    Правильно, зачем фиксы, иди и купи новый сервер. И эти говноеды ещё что-то кукарекают про выбросы CO2! Прикинь, если делать меньше новых серверов и дольше использовать старые, будет меньше выбросов CO2! Ах, да, тогда корпорации заработают меньше баксов. Да же Microsoft выпускало фиксы для своей “протухшей” винды!

     
     
  • 2.34, Аноним (34), 13:26, 15/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому надо беречь свои железки, ухаживать и обслуживать их, чтоб служили дольше. И в перспективе ваще перейти на NetBSD оно даже на 80386 до сих пор работает
     

  • 1.37, Аноним (37), 00:31, 16/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне кажется, что тут вариант только договорится, что после ЕОЛ +х лет открываем код. Кому нужно - скачает, пофиксит, оьновит.

    Кому не нужно, не скачает и не оьновит. Я с трудом понимаю, какой такой код будет актуален через, скажем 6-10 лет после ЕОЛ, что его будет зашкварно открывать.

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

     
     
  • 2.38, Омномном анон (?), 16:47, 16/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда никто не будет покупать новые железки и вендоры разорятся
     
  • 2.39, Аноним (-), 16:59, 16/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне кажется, что тут вариант только договорится, что после ЕОЛ +х лет
    > открываем код. Кому нужно - скачает, пофиксит, оьновит.

    Договориться это про деньги?
    Ну тогда все просто немножко подорожает)

    > Я с трудом понимаю, какой такой код будет актуален через, скажем 6-10 лет после ЕОЛ, что его будет зашкварно открывать.

    А если у тебя в текущик железках код на 80% состоит из старого?
    Как ты объяснишь например инвесторам, что ты подарил 20 лет наработок миру и теперь китайцы радостно потирают руки?

    > Правда я зашквар может быть в другом, но это уже - и другой вопрос.

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


     

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



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

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