Несколько недавно выявленных уязвимостей:...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59592
> Уязвимость (CVE-2023-38633) в библиотеке librsvgВот переписали бы на... Ой, это ведь была libsvg когда-то.
В расте не может быть уязвимости !
Раст и есть уязвимость.
Ну так именно поэтому тут проблема с путями, а не с переполнением буфера или overflow как в дыряшке в соседних уязвимостях.
А где по вашему больше виноват человек (кодер) где пути или где память ?
И там и там виноват)) Но с памятью ошибки опаснее, пути не дадут выполнить произвольный код.
Поэтому у этой уязвимости CVE-2023-38633 score 7.5, а у уязвимости в CVE-2023-3824 с памятью - 9.4 CRITICAL.
Чувствуется разница? А вообще все эти уязвимости с выходом за пределы родного каталога - просто результат черехж0пно спроектированной оси.Просто дыряшке ты с легкостью сделаешь обе ошибки, а в растишке нужно постараться, чтобы накосячить с памятью.
Ну да, спертые ключи ssh - полностью безопасно. Совсем не даст выполнить произвольный код.
> А где по вашему больше виноват человек (кодер) где пути или где память ?Ну, это как установить мину, а потом сказать - виноват тот, кто наступил, не надо было наступать.
Типа проблемы с путями безопасТные?
Там логическая ошибка, а не типичный сишный обсёр с указателями.
Нет, это типичная логическая ошибка на Расте, каких в будущем будет много. И такой тип ошибок превратится в класс уязвимостей.
Они время жизни указателя отследить не могут не то что пути.
Это типичная ошибка на чем угодно, и это отдельный класс уязвимостей с тех пор, как вообще существуют относительные пути.
Ну так и об указателях можно сказать, что это логическая ошибка работы с указателями.
Я уже начинаю считать количество типичных обс_ров разработчиков на rust при работе с файлами, включая https://www.opennet.dev/opennews/art.shtml?num=59548
Есть гипотеза, что rust развращает, и разработчик ожидает, что работа с файлами будет такая же безопасная как с указателями.
Вот что мешает разработать и встроить в rust безопасную работу с файлами с учетом их владения, передачи (включая по сети) и времени жизни? Rust начинали писать на OCaml, эту задачу может проще будет решить (для начала) на каком нибудь Coq, Agda, Idris
Это не получится. Надо создать новый язык, заточеный на безопасную работу с файловыми путями. И рекламировать его везде, вставляя по три больших абзаца текста про безопасную работу с файловыми путями, избавляя программиста от типичных ошибок выхода за пределы рабочего каталога
Ну, не то, чтобы не получится.
Но, наверно, вы правы.
Во первых семантика работы с обьектами файловой системы и указателями может не совпадать и будет код на rust похожый на кашу (сейчас, то rust - образец элегантности)
Во вторых, не всем нужна работа с файлами (может же персистентность обеспечиваться СУБД, etc)
А вот rust, и всю его инфраструктуру, видимо надо позиционировать как stateless, всю работу с IO обьявть unsafe.
Итого: rust, не язык общего назначения, а вычислитель с перекладыванием байтов в оперативной памяти
Вот именно, это лишний раз доказывает, что сознательные программисты/компании не зря (пусть не сразу) отказываются от сишки/плюсов. В них бы на одну эту "логическую" ошибку было бы в довесок еще две-три-четыре критических ошибки работы с памятью. Отрадно видеть, что в целом ЯП дает то, что обещает. Думать за программиста над задачей он не обещал. Это вам к чатгопоте будущих версий.
Компании в твоём сказочном мире?
А, ну да, точно. И поэтому гугловцы решили переписать сетевой стек фуксии с го на плюсы.
Видишь ли в конторах где умеют проверять уровень тупости программистов существуют отборочные вопросы и там сразу понятно кто явился. Растишка если бы был панацеей уже применялся бы вообще везде.
Пока что только отзывы от фанатов в духе "выбрать ржавчину было самой большой ошибкой моей жизни" и далее перечень объективных причин, почему это действительно оказалось плохой идеей. Но, в то же время, ржавчина всё ещё лучше сотен аналогичных моднявых язычков, и если таких неудачников не будет, она никогда не станет юзабельной. Поэтому, чем больше провалов, тем лучше.
Какой современный "социолог". Расплывчатый сомнительный опрос и твердый вывод "это действительно оказалось плохой идеей"
На HN пару раз видел, там любят ржавчину.
Она и была librsvg. Библиотека для РАСТЕРИЗАЦИИ svg.
1. phar_dir_read ошибка в файле dirstream.c немного ошиблись с вычислением размеров, бывает
2. логическая ошибка парсинга
3. GStreamer - в файле rmdemux.c забыли вычислять size для gst_buffer
4. xen-netback/netback.c - buffer overrun, какая неожиданность!
5. в жабаскрипте не силен, но тк там нет строгой типизации, то не удивительно
6. urllib.parse - забыли экранировать ввод? странная ошибка для такой древней либы
7. GNOME Files... проблема suid на пеньке появляется регулярно, возможно дело не в руках, а архитектуре
8. и логическая ошибка в librsvg, почти как в PHP что вдвойне обидно)
Я про то что как бы оказалась что Раст будет способствовать понижению уровня программиста.
ты делаешь такой вывод из одной cve'шки ?
было бы интересно глянуть, что там было до переписывания (но лень)))
может логику транслировали 1-в-1 со всеми ошибками
История помнит Delphi. Раст, конечно, не столь удобный и продуманный, но все возможно.
Ахаха, а у сишных бракоделов, которые даже размер буфера вычислить не могут, сильно высокий уровень??
Откуда инфа что не могут?
Посмотри на число уязвимостей и сложи 2+2(про переполнение не забудь)
Посмотри на чём пишут софт и на чём только переписывают привет миры и сложи 1 и 1.
Посмотрел. В андроиде (в последнийх версиях) _новую_ нативную системщину стараются писать на расте и выкидывают к хе.рам собачьим си/плюсы. Старую сишню/плюсовину пока переписывать не собираются, там же рациональные люди, не фанатики - слишком дофига написано, всё не перепишешь, плюс в старом уже большинство ошибок вылизано. Зато радуются, что в ядро растишку всунули. Грозятся, что когда вызреет то и в ядро на расте будут писать, ибо все эти сишные баги их достали. Так что держись там.https://security.googleblog.com/2022/12/memory-safe-language...
Как я понимаю, ты радуешься за успехи корп в эмбеддовке, но это не серьёзно. Как написали, так завтра и выкинули на свалку. Вообще, я не вижу проблем с таким применением, но вот прикладное ПО не пишет никто, и вряд ли это совпадение.
> Как написали, так завтра и выкинули на свалкуПохоже, не читал ссылку. Свободен, пионер. Скоро в школу.
> но вот прикладное ПО не пишет никто
ага, попробуй найди столько манки-кодеров на расте, сколько требуется всем этим конторам и галерам и сколько подготовлено погромистов (и продолжают готовить, инерция) на других, распространенных, языках, на "промышленных". Ну и никто не оспаривает и не отменяет тонны существующего кода, накопленного за десятилетия, которое не перепишешь и не выкинешь даже за полвека. Ты хочешь чтобы по щелчку пальцев все хопа - и переключились на раст? Так не бывает. Если бы это было на заре эры расцвета прикладного ПО, то можно было приводить такой аргумент. А так - глупо.
Твои аргументы не звучат сколько-нибудь убедительно.
Если бы умели считать, то и уязвимостей не было))glibc https://www.opennet.dev/opennews/art.shtml?num=59529
"Устранена уязвимость CVE-2023-25139, приводящая к переполнению буфера в функциях семейства printf при записи в буфер строковых представлений чисел с разделителями тысячных диапазонов, если размер буфера рассчитан без учёта разделителей (например, вывод 1,234,567 приведёт к переполнению на 2 байта)."
5. Оно и видно что не силён, ведь все 7 из 7 уязвимостей в ноде ни как не связаны с динамической типизацией
О, у нас спец по ноде! Неужели все 7 тоже сишные дырени?
И єтого я тоже не говорила, виноваты разрабы ноды.
Да ладно, нормально все тут с путями, они вообще с Unix пришли.
смотрю в Windows проблем вообще нет?
тебя волнуют проблемы форточников?
или может нужно оттуда взять пару костылей?
Просто про проблемы никто не знает кроме правильных людей.
Проблема не с путями, а с тем, куда ось дает доступ.
То что кто угодно может читать что угодно было нормально в дремучие времена юниксов.
Selinux может ограничивать доступ не только к файлам и сетке но и к памяти ...
Может, это круто. Ну и где ваш Selinux? Его нужно установить и настроить, причем правильно настроить, а то будет еще хуже. В AppArmor можно тоже прописать deny path, а толку.Это должно быть в оси по умолчанию. Каждая аппа получает доступ к своей папке в хомяке и больше никуда. Все остальные запросы на доступ идут через запросы к оси и юзер дает права. Или прописываются ручками в отдельном конфиге, если так удобнее.
В первом абзаце жалуется на то, что ему SELinux папа не настроил, и тут же во втором просит дать ему SELinux ручками настраивать. Подростки такие подростки…
Еще раз для таких отбитых как ты))
SELinux - это просто костыль для ядра, потому что в свое время нормально не сделали, а потом уже поздно было переделывать. Контроль доступа к каталогам должен (был) быть неотъемлемой частью ядра. Но что есть, то есть.
И как же должно быть нормально, о великий кексперт?
Что бы сделать что-то подобное мандатному доступу - надо договориться. Кому надо - поставят и настроят костыль.
В смысле установить и намтроить ? В Федоре все по дефаульту пашет.
В 2005 году (точно не помню) бяла утечка ПХП и пол инета сайты потюкали, а что были на Шапке не пострадали.
Только 2 из уязвимостей связаны с повреждением памяти.
Специальные элементы директорий `.` и `..` были большой ошибкой и костылём для того, чтобы bat-файлы, не имеющие ООП, было легче писать. Давно пора прекратить обработку `.` и `..` на уровне ядра и сломать все программы, от этого зависящие. Кому нужна родительская директория - пусть используют API операционной системы, POSIX API или std::filesystem. Это и есть окончательное решение вопроса.
Вот это очень правильно. Тем более, что в хорошей фс может быть не единственный родительский каталог.
> Специальные элементы директорий `.` и `..` были большой ошибкой и костылём для
> того, чтобы bat-файлы, не имеющие ООП, было легче писать. Давно пора
> прекратить обработку `.` и `..` на уровне ядра и сломать все
> программы, от этого зависящие. Кому нужна родительская директория - пусть используют
> API операционной системы, POSIX API или std::filesystem. Это и есть окончательное
> решение вопроса.Видите ли - так еще много контента ресурсы референсит. Кроме того - а как вы навигировать по иерархии будете без .. ? А назад возвращаться как?
Уязвимость в librsvg?! Не может быть! Эта библиотека написана на безопасном языке!
Дык и уязвимость безопасная. Просто фича такая, не дырень же.
Ещё какая дырень.
Все верно. Там ведь наверное выход за пределы массива? Или обращение к невыделенной памяти? Или, может быть, ее дважды освободили? Хм... Так, что там еще... "Думать за программиста над задачей, предметной областью и не допускать АБСОЛЮТНО ЛЮБЫХ ВООБРАЗИМЫХ ошибок"? А, нет, это сишники выдумали это утверждение и приписывают его растоманам и языку. Пусть тешатся, болезные, ибо как им еще самоутверждаться, оправдываться за 70% ошибок в своих поделках.
Так растовики и считать не умеют выдумывают проценты и сами в них верят.
Не-а. Это наглядная иллюстрация к утверждению, что Раст затрудняет процесс написания (требует повышенного внимания программиста) и следовательно, косвенно способствует появлению логических ошибок.
Сдаётся мне, таких новостей будет появляться всё больше.
https://www.opennet.dev/opennews/art.shtml?num=48680
CVE-2018-11235 в гит - возможность выхода за границы базового каталога репозитория через использование символов "../" в относительном пути к субмодулю, определённому в файле ".gitmodules"О нет! У сишников в штанишках такая же уязвимость была! Возможно программирование на си требует повышенного внимания программиста и следовательно, косвенно способствует появлению логических ошибок.
А вот аналогичная в питоне https://www.opennet.dev/opennews/art.shtml?num=59040
https://www.opennet.dev/opennews/art.shtml?num=59190 - в гитлабе
https://www.opennet.dev/opennews/art.shtml?num=57093 - опять питон, только еще рут получает
https://www.opennet.dev/opennews/art.shtml?num=49440 - сишечка
https://www.opennet.dev/opennews/art.shtml?num=55934 - go (moby, docker/cli и containerd)
https://www.opennet.dev/opennews/art.shtml?num=57978 - и любимое - выход за пределы массива на сишечке, а потом за пределы каталога))
И так далее...Поэтому ваше утверждение... мягко говоря имеет слабое обоснование
а время покажет.пока утверждение косвенно подтверждает :) тот факт, что ВСЕ проекты на Расте пишутся чрезвычайно долго и результат, по-первости, падает на любой чих (яркий пример: inkscape позапрошлого года)
Нет, Rust тут не поможет: ни один баг не про double-free и не про use-after-free, а больше никаких гарантий этот язык не дает.
Интересно, как поможет Rust, если он тихо проглатывает численные переполнения в арифметических операциях?Значит скоро полезут уязвимости.
Переполнения не выходят за границы отведенной памяти. Значение становится невалидное. Кроме того, можно указать поведение в случае переполнения.
В смысле не выходят??? А это тогда что?https://stackoverflow.com/questions/24898579/why-does-the-ru...
Там же по ссылке написано
> thread panicked at 'index out of boundsПроверка не дала выйти за границу.
доступ по индексу проверяется в рантайме. Программа аварийно завершилась - доступа за пределы не было.
В Rust индекс имеет тип usize. А значит при overflow вновь попадёт в валидный индекс 0.Это никак в runtime не проверить.
Вот тебе и яузвимость - доступ к другому участку памяти.А там и данные могут быть с root правами, или спец значения и ТД.
"при обработке файлов в формате RealMedia"Ну вряд ли много кто сейчас помнит-то о таком формате, не то что пользует. Такое найти можно только в пыльных архивах и еще кое где.
Не самый удачный формат для использования уязвимости.
Тем не менее, этот формат должен поддерживаться, иначе пользователи будут ныть. А значит, формат максимально удачный. Только вчера выяснял, почему в свеженькой игрушечке не работает видео, и там как раз этот формат оказался.
>этот формат должен поддерживаться, иначе пользователи будут нытьУтрутся и сконвертируют. Распространители контента, не пользователи. У пользователей не ffmpeg виноват будет, а те, кто контент во всратом формате, а не в общепринятых h.264 h.255 vp9 в кортейнерах и mp4 mkv (и варианте webm) публикует.
Но ведь у пользователей всё работает. Это очень популярный формат на самом деле, куда популярнее, скажем, общепринятых ogg+theora/daala.
> Локальный злоумышленник может передать жертве архив с исполняемым файлом с suid-битом и после открытия жертвой этого архива в GNOME Files, файл будет распакован в локальной ФС с сохранением выставленного suid-бита.Debian 10. Gnome. Распакован через Gnome Files.
***@***:~/tmp$ ls -al
итого 12
drwxr-xr-x 2 *** *** 4096 авг 13 16:32 .
drwxr-xr-x 30 *** *** 4096 авг 13 16:19 ..
-rw-r--r-- 1 *** *** 155 авг 13 16:20 f.zip
***@***:~/tmp$ zipinfo f
Archive: f.zip
Zip file size: 155 bytes, number of entries: 1
-rwsr-sr-x 3.0 unx 3 tx stor 23-Aug-13 16:19 F
1 file, 3 bytes uncompressed, 3 bytes compressed: 0.0%
***@***:~/tmp$ ls -al
итого 16
drwxr-xr-x 2 *** *** 4096 авг 13 16:33 .
drwxr-xr-x 30 *** *** 4096 авг 13 16:19 ..
-rwxr-xr-x 1 *** *** 3 авг 13 16:19 F
-rw-r--r-- 1 *** *** 155 авг 13 16:20 f.zip
***@***:~/tmp$
Это все от использования всяких ИИ-копилотов.
Деградация налицо, обленились.
больше уязвимостей нет, тащ майор
> Уязвимость в GNOME Files, связанная с сохранением suid-бита в файлах, извлечённых из zip-архивовС каких пор это уязимость? Если хомяк не монитруется с noexec, то ЭТО уязвимость (дистрибутива). Если пользователь запускает что-то, установленное в обход пакетного менеджера, то ЭТО уязвимость (между экраном и клавиатурой). А сохранение атрибутов файлов - это стандартная функция менеджера архивов.
*noexec - nosuid nodev noexec
Попробуй /tmp монтировать с noexec, потом поделишься впечатлениями. Сам ты уязвимость, малварь выглядит совсем не так, как ты её себе представляешь. Например, устанавливаемые из самых что ни на есть реп chrome и vscode -- малварь чистой воды.
> Попробуй /tmp монтировать с noexec, потом поделишься впечатлениями.А чо такого?
% mount -v /tmp
tmpfs on /tmp (tmpfs, local, noexec, nosuid)
% stattime /etc/fstab
File: /etc/fstab
Access: 20:34:55 15/11/2014
Birth: 18:47:56 14/11/2013
Modify: 15:23:23 03/06/2021
Change: 15:23:23 03/06/2021% uptime
18:10:04 up 159 days 17:34
Маловероятно, что это рабочая станция -- куча юзерского софта обломится. Да и смысла особого нет, если только нет цели огородить находчивого юзера.
> Маловероятно, что это рабочая станция -- куча юзерского софта обломится.Угу, это не рабочая станция, это ноут, с которого я пишу этот коммент. И да, "куч" обламывающегося не видел, проблемы обычно лишь у весьма специфичных смузи-поделок (сборка некоторых модулей для питона, ржавчины и прочее современное "sudo curl | sh")
Вайнтрикс? DE?
> Вайнтрикс?Да вроде работал пару лет назад (не помню уже для чего использовал - вино у меня только для пары старых игрушек стоит).
> DE?Нету. Еще лет 10 назад надоело регулярное "мы тут опять улучшили и перетасовали, привыкайте".
Есть набор программ - частью стянуто из кед (Okular, Dolphin), частью "когда-то наткнулся и с тех пор пользуюсь".
Под сборку и прочее есть отдельный /tmp-build
> Попробуй /tmp монтировать с noexecВ Debian 10 многие tmpfs смонтированы с noexec и nosiud по-умолчанию.
Запускать что-то из /tmp крайне подозрительно.
В Слэквэр /tmp для сборки слакбилдов, не?
Проблема "../" в том, что, как сказал релокант, нот всего семь. А играть приходиться и на свадьбах и на похоронах. Происходит смешение.