Подробности «android stagefright exploit» или о том что мп4 парсер меньше 5%?
Скорее о том, почему именно этот компонент решили переписывать, хотя про mp4 было интересно почитать, спасибо :). До этой новости я вообще думал, что в серво быстрее попадет https://github.com/servo/rust-url, но с его внедрением какие-то затруднения возникли внезапно.
но их очевидно что надо проверять а не слепо читать и парсить без оглядки
Мне представляется, что почти все серьезные уязвимости можно сопроводить словами "очевидно, тут надо было просто ..." — иногда человеки просто забывают где-то сделать что-то очевидное.
Поэтому я просто не пойму как переписывание mp4 в другом языке может чем-то помочь
Мне сама по себе разработка серво мало интересна — только как самый крупный проект на ржавчине, который и держит ее сейчас на плаву — так что я не слежу за подробностями ржавого браузеростроения и теперь не могу нагуглить конкретные причины создания и внедрения mp4parse-rust, видимо обсуждение было внутренним :(
Может конкретно этот компонент переписали просто потому, что его было просто переписать и надо уже начинать протаскивать ржавчину в огнелиса, вполне допускаю.
Ну это какие-то очень размытые требования — очень сильно зависит от решаемых задач, да и требования к "адекватности" у каждого свои :). Тут в общем виде не скажешь. Для меня и моих задач адекватные библиотеки и документация для ОС "первого уровня" наличествуют)
«android stagefright exploit» — там в основном все про stagefright, только частично упомянается мп4 парсер, который меньше 5% от stagefright занимает.
Ну тогда я бы и сам не отказался от ссылок на подробности :(
Сам мп4 парсер довольно таки легко написать без подобных проблем (для тех кто знают структуру мп4 это очевидно).
Каюсь, я структуру mp4 не знаю и мне не очевидно. По моему опыту правильно написать хоть немного объемный код на плюсах, который работает с данными из недоверенного источника, очень сложно.
А в чем проблема к примеру использовать тогда custom C++ array with checked index bounds?
Можно, главное везде это последовательно делать (и аналогичную остальную опциональную защиту использовать). А я считаю, как выше написал, что все люди время от времени ошибаются и что-то забывают, так что рутину с человека надо максимально перекладывать на программу. И вот в ржавчине по умолчанию все безопасно и без UB — ты должен специально попросить компилятор если что-то опасное хочешь сделать. А в плюсах наоборот и без UB реальную программу больше сотни строчек написать практически нельзя.
Вроде как vector::[] calls vector::at()? Подобная run-time проверка тоже будет.
Насколько я помню, что бы была проверка границ у плюсового вектора надо дергать метод at, а не обычный оператор индексирования.
если трудно пройтись по коду в отладчике это уж точно не поможет в отладке этих самых уязвимостей и прочих проблем короые могут привести к букету других проблем и уязвимостей.
Я не очень в курсе как там сейчас ситуация с отладкой в VS, вроде как подвижки какие-то есть, но в целом так себе работает. IDE для ржавчины и всякие мощные плагины для редакторов вообще пока в состоянии активного развития, тут время нужно.
А в отладчике пройтись по коду не трудно — gdb-то поддерживается.
Отладка уязвимостей, кмк, обычно аналитическая и отладчик тут вообще не нужен — главное узнать о уязвимости. А узнать отладчик никак не поможет, тут скорее статический анализатор нужен.
… немного удивился что кто-то умудрился в андроид закомитить код который парсит что-то без валидации размеров
Люди время от времени ошибаются или забывают что-то сделать, так было и всегда будет :( .
Вместо того чтоб нормально написать парсер переписать писать его на другом языке?
Я думаю, что те ошибки, которые уже нашли, тут же исправили и выкатили обновления. Вопрос в том, сколько подобных уязвимостей еще не известны авторам, но известны злоумышленникам.
А ржавчина позволяет на порядок уменьшить возможность возникновения подобных косяков (совсем без unsafe на каком-то уровне и без ffi писать реальный код все-таки нельзя).
А как же отладка кода (если это не gdb)? В VisualStudio нельзя будет пройтись по парсеру как будто это какой-то массивный opengl что ли?
Отладка это отладка, как она уязвимости должна помогать находить?
Оперативность обновления пакетов — одна из его сильных сторон арча, тут вопросов нет) А вот во всяких убунтах/сусях с ржавчиной в стандартных репозиториях дела пока так себе.
Как минимум, 1.8 должен быть. Значит и дистрибутивам, что бы нормально собрать фаерфокс придется хотя бы такой же запаковывать.
В любом случае это не очень важно, так как есть rustup
Не критично (хорошо хоть оно уже давно "curl… | sudo sh" не требует), да, но мне массовое использование rustup видится временной мерой. С течением времени хотелось бы ставить cargo/rustc как обычный gcc — из пакетного менеджера, а не где-то сбоку.
А я правильно понимаю, что из-за этого теперь во всех линуксовых дистрибутивах (файерфокс же, наверное, практически во всех есть, кроме совсем уж узко специализированных) будет более-менее свежий стабильный rustc/cargo?
Логика в том, что плюсы — плохой инструмент (по крайней мере с точки зрения Мозиллы, иначе бы они разработку Ржавчины не оплачивали) и его постепенно заменяют на лучший инструмент — ржавчину. Да, поначалу это проносит мало прямой выгоды для пользователей, но в долгосрочной перспективе должно быть для них выигрышно.
не крашился
Можно подумать это единственная проблема плюсового кода.
От самого факта переписывания этого компонента на ржавчину пользователям и правда прямо сейчас прямой выгоды нет (как и вреда).
Смысл в самом прецеденте — Ржавчина пробралась в стабильную ветку такого большого проекта. Для начала в небольшой компонент, но надо понимать сколько за этим стоит работы по подтягиванию инфраструктуры Ржавчины до нужного состояния (на андроиде вон до сих пор добивают) и адаптации сборки самого Firefox.
Т.е. это реальный и значительный шажок к будущему, когда процент ржавого кода сильно вырастет и уже это позволит добиться более быстрого времени запуска, лучшей производительности и меньшего потребления памяти.
на C/C++ тоже можно писать код который не будет крашиться.
Предполагается что на Ржавчине это делать проще, особенно в больших масштабах.
С 1.9 это уже не совсем так: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html, хотя идиоматичный подход остался тем же.
Может мне кто-то объяснить, почему режим IronMan не включен по умолчанию и зачем люди вообще играют без него?
А что такого костыльного gl-rs делает?
Скорее о том, почему именно этот компонент решили переписывать, хотя про mp4 было интересно почитать, спасибо :). До этой новости я вообще думал, что в серво быстрее попадет https://github.com/servo/rust-url, но с его внедрением какие-то затруднения возникли внезапно.
Мне представляется, что почти все серьезные уязвимости можно сопроводить словами "очевидно, тут надо было просто ..." — иногда человеки просто забывают где-то сделать что-то очевидное.
Мне сама по себе разработка серво мало интересна — только как самый крупный проект на ржавчине, который и держит ее сейчас на плаву — так что я не слежу за подробностями ржавого браузеростроения и теперь не могу нагуглить конкретные причины создания и внедрения mp4parse-rust, видимо обсуждение было внутренним :(
Может конкретно этот компонент переписали просто потому, что его было просто переписать и надо уже начинать протаскивать ржавчину в огнелиса, вполне допускаю.
С Редоксом вопрос скорее в том, что он сам еще совсем сырой.
Ну это какие-то очень размытые требования — очень сильно зависит от решаемых задач, да и требования к "адекватности" у каждого свои :). Тут в общем виде не скажешь. Для меня и моих задач адекватные библиотеки и документация для ОС "первого уровня" наличествуют)
Странный вопрос — http://rurust.github.io/rust_book_ru/src/getting-started.html#Поддерживаемые-платформы
что бы ключевые слова новые не вводить?
Ну тогда я бы и сам не отказался от ссылок на подробности :(
Каюсь, я структуру mp4 не знаю и мне не очевидно. По моему опыту правильно написать хоть немного объемный код на плюсах, который работает с данными из недоверенного источника, очень сложно.
Можно, главное везде это последовательно делать (и аналогичную остальную опциональную защиту использовать). А я считаю, как выше написал, что все люди время от времени ошибаются и что-то забывают, так что рутину с человека надо максимально перекладывать на программу. И вот в ржавчине по умолчанию все безопасно и без UB — ты должен специально попросить компилятор если что-то опасное хочешь сделать. А в плюсах наоборот и без UB реальную программу больше сотни строчек написать практически нельзя.
Насколько я помню, что бы была проверка границ у плюсового вектора надо дергать метод
at, а не обычный оператор индексирования.Я не очень в курсе как там сейчас ситуация с отладкой в VS, вроде как подвижки какие-то есть, но в целом так себе работает. IDE для ржавчины и всякие мощные плагины для редакторов вообще пока в состоянии активного развития, тут время нужно.
А в отладчике пройтись по коду не трудно — gdb-то поддерживается.
Отладка уязвимостей, кмк, обычно аналитическая и отладчик тут вообще не нужен — главное узнать о уязвимости. А узнать отладчик никак не поможет, тут скорее статический анализатор нужен.
Я так понимаю, речь об этом и всяком что гуглится по запросу "android stagefright exploit".
Люди время от времени ошибаются или забывают что-то сделать, так было и всегда будет :( .
Я думаю, что те ошибки, которые уже нашли, тут же исправили и выкатили обновления. Вопрос в том, сколько подобных уязвимостей еще не известны авторам, но известны злоумышленникам.
А ржавчина позволяет на порядок уменьшить возможность возникновения подобных косяков (совсем без unsafe на каком-то уровне и без ffi писать реальный код все-таки нельзя).
Отладка это отладка, как она уязвимости должна помогать находить?
Оперативность обновления пакетов — одна из его сильных сторон арча, тут вопросов нет) А вот во всяких убунтах/сусях с ржавчиной в стандартных репозиториях дела пока так себе.
Откуда я 1.8 взял? 1.10 текущая стабильная же.
Как минимум, 1.8 должен быть. Значит и дистрибутивам, что бы нормально собрать фаерфокс придется хотя бы такой же запаковывать.
Не критично (хорошо хоть оно уже давно "curl… | sudo sh" не требует), да, но мне массовое использование rustup видится временной мерой. С течением времени хотелось бы ставить cargo/rustc как обычный gcc — из пакетного менеджера, а не где-то сбоку.
А я правильно понимаю, что из-за этого теперь во всех линуксовых дистрибутивах (файерфокс же, наверное, практически во всех есть, кроме совсем уж узко специализированных) будет более-менее свежий стабильный rustc/cargo?
В теории могли бы и не внедрять ничего в огнелиса, а сосредоточить все силы на создание совсем нового браузера поверх servo.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3870
https://github.com/mozilla/mp4parse-rust
Обе ссылки из текста статьи :)
Это очень похоже на мое о нем впечатление)
Смотрю в доках:
И судя по тем же докам, проверка времени изменения перед проверкой хешей опциональна и требует явного включения —
Decider('MD5-timestamp').Логика в том, что плюсы — плохой инструмент (по крайней мере с точки зрения Мозиллы, иначе бы они разработку Ржавчины не оплачивали) и его постепенно заменяют на лучший инструмент — ржавчину. Да, поначалу это проносит мало прямой выгоды для пользователей, но в долгосрочной перспективе должно быть для них выигрышно.
Можно подумать это единственная проблема плюсового кода.
Можно подробней где тут эта самая очевидная фаллометрия? Кто с кем длинной чего меряется вообще?
Ленивые ретрограды всех так называют
От самого факта переписывания этого компонента на ржавчину пользователям и правда прямо сейчас прямой выгоды нет (как и вреда).
Смысл в самом прецеденте — Ржавчина пробралась в стабильную ветку такого большого проекта. Для начала в небольшой компонент, но надо понимать сколько за этим стоит работы по подтягиванию инфраструктуры Ржавчины до нужного состояния (на андроиде вон до сих пор добивают) и адаптации сборки самого Firefox.
Т.е. это реальный и значительный шажок к будущему, когда процент ржавого кода сильно вырастет и уже это позволит добиться более быстрого времени запуска, лучшей производительности и меньшего потребления памяти.
Предполагается что на Ржавчине это делать проще, особенно в больших масштабах.
Раст