https://ns.opennet.dev/openforum/vsluhforumID3/116041.html Раскрыта (https://blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-details/) детальная информация о 13 уязвимостях, выявленных в ходе аудита TCP/IP-стека открытой операционной системы FreeRTOS (https://www.freertos.org/), последнее время развиваемой (https://www.opennet.ru/opennews/art.shtml?num=47649) компанией Amazon. Шесть уязвимостей потенциально позволяют организовать выполнение кода через отправку специально оформленных IP- и TCP-пакетов, а также сетевых запросов с использованием протоколов DNS, LLMNR и HTTPS. Восемь уязвимостей могут привести к утечке содержимого памяти процессов-обработчиков. Одна уязвимость может применяться для отравления кэша DNS (подстановки фиктивных значений).<br><br><br>ОС FreeRTOS поставляется под лицензией MIT и в основном применяется на различных микроконтроллерах, встраиваемых устройствах, системах промышленной автоматики и оборудовании интернета вещей (IoT). Уязвимости устранены начиная с выпуска 1.3.2 (https://github.com/aws/amazon-freertos/release), всем пользователям у https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#63 Thu, 13 Dec 2018 07:35:00 GMT &gt; https совершенно не оправдан, это я согласен полностью. TCP/IP - можно придумать <br>&gt; юзкейс, хотя как правило он в подобных системах реализован на уровне <br>&gt; внешней железки. А вот TLS очень даже оправдан. С учётом того, <br>&gt; что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным <br>&gt; по ресурсам.<br><br>TLS много памяти ест, с процессором обычно особых проблем нет, Cortex M4 тот же очень быстрая машина.<br>Память-то вся SRAM обычно, никакого DDR.<br><br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#62 Wed, 12 Dec 2018 21:32:07 GMT https совершенно не оправдан, это я согласен полностью. TCP/IP - можно придумать юзкейс, хотя как правило он в подобных системах реализован на уровне внешней железки. А вот TLS очень даже оправдан. С учётом того, что сейчас в большинстве контроллеров аппаратное шифрование, он становиться вполне доступным по ресурсам.<br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#61 Wed, 12 Dec 2018 21:23:51 GMT &gt;&gt; У них свое фирменное проклятие в виде оверинженерии, переклина на проприетарных средствах разработки, ну и конских цен на все это и враждебности экосистемы в целом к линуху. <br><br>О да, индусский код обвзяки от STM это страшно. Это одна из причин, почему я их предпочитаю не использовать. У EnergyMicro, ныне принадлежащей силабсу, с этим было гораздо лучше (при силабсах вроде пока тоже нормально). Да, разрабатывал я под линуксом без проблем, коллеги тот же самый проект пилили под виндой - кому что удобнее, и главное прозрачно переносимо.<br><br>&gt;&gt; Ну и стоит он такой как-то не доллар все-же.<br><br>ну да, бакса 2-3<br><br>&gt;&gt; А раз так - может и ну его нафиг TLS тогда? Гимора много, профита мало %)<br><br>Не понял логику =) А что если не TLS? Своё шифрование городить? Так ещё больше уязвимостей огребёшь.<br>Я ж говорю, классическая задача для датчика - собрать данные и слить на сервак в центр. Для этого зачастую самое удобное решение - TCP/IP. Шифровать в современных реалиях надо по-любому, аутентифицировать тоже крайне желательно https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#60 Wed, 12 Dec 2018 17:31:16 GMT &gt;&gt; ar9331 правда партией по пять штук хотя бы.<br>&gt; А ты его потребление видел, пардон? <br><br>Конечно видел. Это же не мешает его использовать, если нет требований по автономности питания.<br>&gt; Сабж запускают на совем микроконтроллерах - <br>&gt; и там с управлением питанием сильно лучше чем в 9331. Так <br>&gt; что реально даже от батареек какое-то более вмняемое время работать. А <br>&gt; с 9331... ну в общем это разные весовые категории, даже не <br>&gt; конкуренты толком.<br><br>У нас в компании бывает берут и ar9331, если питание не батарейное и надо что-то недорогое, толстое и на Linux. Между прочим одна из причин как раз такие грабли с безопасностью.<br><br><br><br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#59 Wed, 12 Dec 2018 14:07:33 GMT &gt; Даст оно ложную уверенность очередного теоретика по типу Ordu в какой-то сферической безопасности в вакууме. <br><br>А ложная она, потому что все, в чем анон не сечет - фигня, внимания не стоящая.<br><br>&gt; А я ему пожелаю со своей стороны накодить себе на своем фетише хотя-бы автопилот/систему стабилизацит чего-нибудь летучего или скоростного. <br><br>Если опеннетные писатели автопилотов не в курсе целой кучи методов верификации для разработки критичных частей софта, то это однозначно говорит о том, что этих методов не существует и ими никто не пользуется!<br><br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#58 Wed, 12 Dec 2018 14:00:27 GMT &gt; я бы тебя нанял скажем на пару месяцев за 25к для нахождения 100 дыр.<br><br>Так чего скучаем? Пишем, нанимаем! <br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#57 Wed, 12 Dec 2018 13:36:29 GMT The most dangerous time is whan you feel yourself safe...<br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#56 Wed, 12 Dec 2018 13:33:28 GMT Даст оно ложную уверенность очередного теоретика по типу Ordu в какой-то сферической безопасности в вакууме. А я ему пожелаю со своей стороны накодить себе на своем фетише хотя-бы автопилот/систему стабилизацит чего-нибудь летучего или скоростного.<br><br>И критерий тестов безопасности будет крайне прост. Если система не размажет своего автора за обозримое время - QC passed :)<br> https://ns.opennet.dev/openforum/vsluhforumID3/116041.html#55 Wed, 12 Dec 2018 12:29:45 GMT &gt; Ну ок, про китайцев соглашусь - я при разработке как-то их обычно не рассматриваю<br><br>Ну а я вот встретил это в весьма приличном эмбедовочном применении. Олимекс, конечно же, а не платки с али, так подороже, зато апстрим знает что произвел, дружественный к опенсорцу (на половину CAD файлы есть, кой-что даже в KiCad, можете хоть сами нашлепать, если пупок не развяжется). И понимают особенности эмбеда, так что через год купить платки и модули, чтобы не переделывать проект - не вопрос. А на али как повезет, ессно. Хотя для себя или для случаев когда повтор на бис не планируется я и более китайские варианты использую. Работает нормально. Если руки из правильного места и свою систему и железку знать, конечно.<br><br>&gt; ориентируюсь на более традиционных производителей: TI, Silabs/EnergyMicro, <br>&gt; NXP/Freescale, STM, Atmel/Microchip и тд. <br><br>У них свое фирменное проклятие в виде оверинженерии, переклина на проприетарных средствах разработки, ну и конских цен на все это и враждебности экосистемы в целом к линуху. Хотя ST