The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в сетевых библиотеках языков Rust и Go, позволяющая обойти проверку IP-адресов, opennews (??), 08-Авг-21, (0) [смотреть все]

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


340. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  –1 +/
Сообщение от Аноним (340), 08-Авг-21, 23:00 
Абсолютно нет. Вообще-то такой язык есть - Ada.
Ответить | Правка | Наверх | Cообщить модератору

347. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Прохожий (??), 08-Авг-21, 23:30 
И на нём нельзя сделать никаких ошибок? Советую думать головой, прежде чем что-либо озвучивать на публику.
Ответить | Правка | Наверх | Cообщить модератору

359. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  –2 +/
Сообщение от Аноним (340), 09-Авг-21, 01:23 
Конечно нельзя, особенно с формальной верификацией
Ответить | Правка | Наверх | Cообщить модератору

405. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Аноним (-), 09-Авг-21, 09:01 
> Конечно нельзя, особенно с формальной верификацией

Ариан-5 готов с этим поспорить. Так то самый дорогой баг в истории человечества :P

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

432. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Аноним (-), 09-Авг-21, 12:45 
>> формальной верификацией
> Ариан-5 готов с этим поспорить.

/0
Жопочтец294, ты?

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

479. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  –1 +/
Сообщение от Урри (ok), 09-Авг-21, 17:58 
> Ариан-5 готов с этим поспорить.

С чем поспорить? Ариан-5 самоуничтожился не из-за программного бага, а из-за несоответствущего оборудования. Ada тут вообще никаким боком.

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

Для анонимов еще проще: код для armv8 запустили на armv5, с соответствущим результатом.

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

547. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +1 +/
Сообщение от Аноним (-), 10-Авг-21, 09:40 
> С чем поспорить? Ариан-5 самоуничтожился не из-за программного бага, а из-за несоответствущего
> оборудования. Ada тут вообще никаким боком.

Вообще-то баг таки был целиком программный. Несоответствующее оборудование? Ох, лол. Это не вы писали софт ракетам #$%шащимся о небесную твердь с Восточного? Там тоже "космодром несоответствующий".

> Вкратце: на ариан-5 был переиспользован код для предыдущих ракет, который корректно(!)
> работал согласно поставленной задаче. Но из-за того, что железо было другое,
> оборудование вело себя иначе, выходя на неправильную траекторию.

Вообще-то там был integer overflow. Потому что оборудование вело себя иначе, а чудо-программисты со всей их безопасТностью об этом не подумали. Самое интересное что в теории ада вроде должна была это поймать, но они вручную заоверрайдили. Примерно как хрустики с unsafe.

> Для анонимов еще проще: код для armv8 запустили на armv5, с соответствущим результатом.

Идиотская аналогия для целочисленного переполнения, имхо. И, между нами, девочками, ВЫ НИКОГДА НЕ ДОЛЖНЫ СЛЕПО ДОВЕРЯТЬ ДАТЧИКАМ, БЖАД. Это "внешний мир" и он может сделать что угодно. И если кто кодил софт в других допущениях, его, так-то, уволить надо было, и даже не за аду, и даже не за оверрайд фичи в ней.

Говоря за себя - я работая с датчиками всегда оцениваю worst case технической размерности данных которая оттуда может приехать. Мало ли что железо решит отколоть. Если при этом будет overflow, откровенно левое значение после него может быть сожрано за что-то весьма валидное, система возьмет это в оборот, но поскольку это мусор, одному Ктулху известно что будет дальше. В управляющих системах - ничего хорошего.

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

560. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  –1 +/
Сообщение от Урри (ok), 10-Авг-21, 12:12 
Аноним считает, что если запустить код для armv8 на armv5, то ошибка в работе будет программная. Аноним совсем глупый пошел.

> Вообще-то там был integer overflow.

Меньше википедию читайте. Мы лет 10 (или 15) назад, я уже не помню, довольно тщательно пережевывали эту ситуацию. Переполнение там правильно обрабатывалось, все как надо. Проблема была в том, что команды управления оборудование обрабатывало неправильно.

Прямой пример: управление рулевой колонкой фокуса, перенесенное на самосвал. Обработка команды поворота слишком медленное, ввиду чего как ты не пытайся компенсировать недостаточный поворот, ничего не получится.

> ВЫ НИКОГДА НЕ ДОЛЖНЫ СЛЕПО ДОВЕРЯТЬ ДАТЧИКАМ, БЖАД. Это "внешний мир" и он может сделать что угодно.

А как датчикам можно доверять "не слепо"? Попросить ардуинку в окошко выглянуть, что ли? Что это, вообще, за бред?

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

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

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

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

603. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +1 +/
Сообщение от Аноним (-), 11-Авг-21, 09:47 
> Аноним считает, что если запустить код для armv8 на armv5, то ошибка
> в работе будет программная. Аноним совсем глупый пошел.

Я бы сказал что аналогия идиотская.

> Меньше википедию читайте. Мы лет 10 (или 15) назад, я уже не
> помню, довольно тщательно пережевывали эту ситуацию.

1) Источник ваших данных?
2) То что вы там где-то пережевывали лично мне не видно.
3) Поэтому извольте какие-то более материальные пруфы.

А со всякими Сакральными Знаниями можете курнуть бамбук. Информация такого плана должна быть обоснована и подтверждена. Чем-то более существенным чем понт на форуме.

> Переполнение там правильно обрабатывалось, все как надо.

А почему другие источники утверждают что команда заоверрайдила проверку и в результате при переполнении целого начался бред?

> Проблема была в том, что команды управления оборудование обрабатывало неправильно.

Пруф данных сведений, вы, конечно же, предоставите? Можно какой-нибудь официальный отчет тех кто это расследовал, или что вам там удобно.

> Прямой пример: управление рулевой колонкой фокуса, перенесенное на самосвал. Обработка
> команды поворота слишком медленное, ввиду чего как ты не пытайся компенсировать
> недостаточный поворот, ничего не получится.

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

> А как датчикам можно доверять "не слепо"?

Ну вот так.

1. Смотри, в ADC заявлено что он 12 бит, но регистр можно читать как u16 или u32, реальный размер регистра такой. Если железо однажды вернет более 12 битов (технически может) - на этом можно погореть. Если не сделать проверок сразу, математика возьмет в оборот, после всяких переполнений может получиться что-то правдоподобное. Однако по факту оно является бредом. А как проверять? В том случае, допустим, if (sample > 0xFFF) {hardware fault}. Вот так мы круто и резко знаем что он нас на...вает.

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

3. Если мы примерно представляем себе поведение объекта и валидные диапазоны, выход за эти диапазоны является индикатором проблем того или иного свойства. Ну, например, flight software в таком случае по нормальному должно сообщить пилоту что не понимает что за д#рьмо творится и отдать штурвал в failsafe режиме, и это уже проблема пилота, он имеет больше шансов. Более приземленные объекты логично привести в безопасное состояние (fail safe) и репортить отказ. А дальше разбираться что за нахрен.

> Попросить ардуинку в окошко выглянуть, что ли? Что это, вообще, за бред?

Эм... можно и чуть попродвинутее, так то.

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

Мне нравится такой подход. Но вылетел бы он за "давайте проигнорируем". Я разве настаивал что эту ситуацию игнорить надо? При обнаружении левых показаний надо скорее всего перейти к fail safe вообще-то. Но так то прикольно считать всех д@билами, в принципе, опеннете это понимаемо, что уж :)

> Датчикам он решил не доверять.

Доверять нельзя никому. Особенно в ответственных применениях. Ни софту, ни железу, в том числе и датчикам. Иначе на этом можно жестко погореть, а раз в год и палка стреляет. Вы вообще firmware safety guidelines крупных производителей читали?

> Датчики показывают, что пациент поджаривается от значений, которые источник в принципе
> выдать не может? Алярма, все выключить, громко звенеть и требовать срочных спасателей!

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

> Потому что раз в год и источник может выдать то, на что не расчитан.

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

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

Ну это уже какая-то конкретика, и у вас, видимо, какое-то фирмваре сделало часть упомянутого. И оно именно дублированное? А не х3 хотя-бы? Если датчиков только 2, нельзя понять кто гонит. Хотя для вырубания операции достаточно.

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

565. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +1 +/
Сообщение от Аноним (-), 10-Авг-21, 12:46 
>> нельзя, особенно с формальной верификацией
> Вообще-то там был integer overflow. Потому что оборудование вело себя иначе, а
> чудо-программисты со всей их безопасТностью об этом не подумали. Самое интересное
> что в теории ада вроде должна была это поймать, но они
> вручную заоверрайдили. Примерно как хрустики с unsafe.

Mama mia. Какой же ты все таки невежа с ЧСВ > 9000
*потрясенное_молчание.жпг*

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

518. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Прохожий (??), 09-Авг-21, 22:41 
Ок. Что вы можете сообщить при этом о стОимости разработки такого ПО?
Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

520. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Прохожий (??), 09-Авг-21, 22:55 
1. Если уж вы заявляете о формальной верификации, причём здесь тогда Ada? Формальная верификация не привязана ни к какому языку, не правда ли?

2. Модель, по которой идёт верификация не может быть ошибочной?

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

575. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  +/
Сообщение от Аноним (575), 10-Авг-21, 17:03 
>Формальная верификация не привязана ни к какому языку, не правда ли?

Привязана. У Ada это Spark.

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

451. "Уязвимость в сетевых библиотеках языков Rust и Go, позволяющ..."  –2 +/
Сообщение от Аноним (451), 09-Авг-21, 16:35 
> Абсолютно нет. Вообще-то такой язык есть - Ada.

Ещё один язык на котором ничего не пишут.

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

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

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




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

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