Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 128
Уязвимость либо есть, либо её нет. Если она есть, то было бы неплохо её исправить. В чём проблема? Разработчики могут сами принять решения, исправлять что-то или нет.
Тут вопрос скорее в том что, идёт уведомление о найденной уязвимости, если вы в течении 90 дней ее не убрали или даже убрали, о ней сообщается всему миру. Я так понял посыл.
Ну и как бы мало кому приятно, что если он не успел убрать уязвилсось, ей могут начать пользоваться. Да и убирать иногда нет жклани и мотивации.
Проблема, видимо, в том, что Гугл считает 90 дней достаточным, чтоб потом публиковать отчет. Скорее всего, маленькие и популярные проекты получили такое количество новых багов неизвестной серьезности, которое разобрать руками невозможно.
Проблема, видимо, в том, что Гугл считает 90 дней достаточным, чтоб потом публиковать отчет.
Однако если не публиковать - то уязвимость (если она конечно, есть) никуда не пропадет. И ее теми же инструментами могут найти уже те, кто захочет ей воспользоваться.
Хакеры могут быть благодарны гугл и включить их в свою команду,
Есть такой анекдот, про женскую баню:
В исполком пришла жалоба: "Напротив моего окна женская баня. Мне все видно и это отвлекает меня и вообще действует на мой моральный облик. Прошу предоставить мне новую квартиру". Приехала комиссия, смотрят в окно.
— Ну и что? Ничего не видно!
— А вы на шкаф залезьте!
— Ну, залез, — говорит представитель, — все равно не видно!
— Двигайтесь левее...
— Все равно не видно!
— Еще левее!
— А, вижу, вижу — Тут представитель двигается и падает с края шкафа.
— Вот видите! А я так целыми днями!
Это я к тому, что баги уязвимости бывают разными. Очень разными. И когда ИИ выкатывает пачку багрепортов уровня "если прыгать на правой ноге, взявшись левой рукой за правое ухо, а правой рукой - за левую пятку, то расстёгивается рубашка" - ну это такое себе. Надо смотреть, что именно им шлют.
Одна из проблем что ИИ глючит и находит уизвимость которой нет. Но генерирует это поток уязвимостей большим числом. Но на обработку этого бреда приходится тратить много времени.
то есть не доказанные уязвимости? до этого они не снисходят?
Только уязвимости, которые ищет гугл верифицируются через санитайзеры (памяти, адресов и прочие). В данном случае гугл прислал одну уязвимость read-after-free (или что-то подобное, не могу найти ссылку на репорт) в каком-то кодеке для пет проектов
В чём проблема
В том, что ошибок много, а разработчиков мало, и разработчики эти трудятся на волонтёрских началах. Помочь им в работе никто не хочет, а требовать чего-то - это каждый первый. Особенно цинично это звучит, когда одна из богатейших корпораций требует чего-то. Если вам так важен этот FFmpeg, возьмите этих ребят к себе, платите им з/п, добавьте помощников, если не справляются с объёмами, и поставьте планы по исправлению уязвимостей.
Гугл: Поставить им план по исправлению уязвимостей это мысль! А вот остальное лишнее.
Нет, пожалуйста, пусть не берут. Ты думай, это же корпорация, они либо поглотят и сделают платным, либо закрытым, либо сделают свое, которое будет чуть лучше, но ровно до тех пор пока открытый проект не умрёт, после чего расслабятся с качеством и ещё и рекламы с телеметрией напихают. Нет спасибо.
А вот помощь материальную или умственную выделить - пожалуйста
Реклама в библиотеке это как? В документации типа?))
При загрузке фреймворка Express ставился лайк на рекламу бургеров в твиттере https://notes.jordanscales.com/node_modules
Да я условно, раньше мы не думали, что холодильник будет рекламу показывать, а тут вполне могут в cli добавить пару строк в стартовый баннер
если это ffmpeg, то можно в перекодируемое видео вставлять.
По моему опыту общения с "security researcher"-ами из плоти и крови, в отсутствие настоящих и при этом легко обнаружимых уязвимостей они достаточно часто начинают "репортить" всякую дичь в стиле "при наличии физического доступа к серверам habr.com возможно их физическое уничтожение при помощи кувалды". И начинают еще нагонять что голактеко опасносте, и все такое, гоните мне 0.5 BTC на такой-то кошелек.
Представляю, что там ИИ мог нагенерить.
А как может гугл что-то "требовать" от волонтерского проекта, который даже не финансирует? При наличии финансирования можно хотя бы косвенно давить. А так, кто запретит закрыть issue с формулировкой "Что-то мне щас неохота это фиксить. Пойду пивка бахну" :) Юристы гугла, ваш выход!
Интереснее другое: могут ли авторы волонтёрского проекта поменять лицензию, что "с версии XXX - для всех всё, как для старого, а для Гугла - мегабакс за копию"?
Для замены лицензии нужно согласие всех контрибьюторов. Уже была подобная эпопея для какой-то части VLC (уже не помню какой именно) - это была очень долгая история. К сожалению не знаю чем закончилась - перестал туда контрибьютить...
Кроме того, такая замена приведёт к тому, что проект перестанет считаться СПО.
Например, была история с приложением, разработчик которого вставил в лицензию запрет использовать код со злыми целями. Приложение перестало соответствовать определению "свободное", т.к. лицензия начала ограничивать свободу пользователей.
Гугл просто форкнет предыдущую версию и будет развивать её сам. С учётом ресурсов Гугла вполне может случиться, что форк станет ещё и популярнее оригинала (к тому же форк будет свободным ПО, а оригинал уже нет, что может оказаться психологически важным для других проектов, которые берут код из FFmpeg) , а разработчики оригинального проекта окажутся героями мема "просчитался, но где?"
Я ИМХО думаю что проблема несколько в другом.
Но для этого надо вернуться к главной идее linux: одна задача - одна программа.
А ввиду того что из маленьких программ для одного действия вырастают монстры комбайны, который могут чайник поставить хотя изначально задумывались только чтобы спарсить код страницы, мы получаем сложно поддерживаемый проект с кучей зависимостей и трудноуловимых багов.
Похоже назревает необходимость в атомизации всего написанного.
Ну так помогите им, благо репо и все доки доступны :)
Что, нет желания? Как же так? Советы все давать горазды.
ИИ-система нашла баг в системе декодированием кодека LucasArts Smush, в частности первых 10–20 кадров Rebel Assault 2, игры 1995 года, и назвала эту проблему средней важности в ffmpeg
Вопрос в том, что проблема существует возможно только в Rebel Assault 2, а Гугл отмечает это как проблему средней важности в ffmpeg. Поулчается что опесорсный ffmpe ДОЛЖЕН устранить что-то, что не несет опасности для Гугл, а только для игры 1995 года, при этом это публикуется как баг средней важности во всеуслышание.
И речь не только об этом конкретном баге, а о том, что многомиллардная корпорация с помощью ИИ находит маловажные вещи и требует их исправления в одностороннем порядке
Думаю, логика тут в том, что если накормить либу чем-то интересным - она сделает что-то забавное.
И если есть способ открыть в ffmpeg произвольный файл. - кто-то может подсунуть его именно в таком формате 1995 года, да ещё и с бережно подготовленным эксплойтом.
Когда открываешь видеофайл, а у тебя загорается светик на камере - это ниразу не прикольно)
Конечно, конкретно этот баг похоже не особо страшный, да.
Да нет отсылок к ИИ ни в твите, и в пулл-реквесте. Оба говорят исключительно о правильности воспроизведения видео, а не об угрозе безопасности.
Ffmpeg это open source проект доступный абсолютно всем. И работают над ним энтузиасты, а не условные работники google. Нахождение самих уязвимостей то это хорошо, чтобы их решить, но ffmpeg используется повсеместно, поэтому бы было бы неплохо, если бы большие компании ещё помогали решать сами проблемы в проектах, которые они используют, а не просто указывать на эти проблемы.
Уязвимость либо есть, либо её нет. Если она есть, то было бы неплохо её исправить. В чём проблема? Разработчики могут сами принять решения, исправлять что-то или нет.
Вижу, что не все поняли смысл моего комментария, поэтому распишу свою позицию подробнее.
Уязвимости в ПО - это плохо и их нужно исправлять. Создал своё ПО и отправил его в opensource, будь добр нести ответственность и исправлять в нём уязвимости. Если не хочешь исправлять уязвимости, то так и напиши. Индустрия тогда просто перейдёт на другое ПО, где есть кому исправлять уязвимости.
Размер ПО конечен (а не бесконечен), как и количество багов и уязвимостей в нём. Чем больше их исправлено, тем меньше их там остаётся.
Сейчас появилось много ПО, которое с помощью ИИ лучшим образом находит уязвимости, т.е. там, где раньше нужно было 10 человек, теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей. А это значит, что сейчас нахлынет волна репортов по уязвимостям. Это нормально. Чем больше уязвимостей будет по этим репортам исправлено, чем меньше этих репортов будет приходить в будущем.
Появление новых ИИ сканеров уязвимостей означает, что создателям ПО имеет смысл их запускать самостоятельно на периодической основе, а не ждать, пока это сделают сторонние исследователи ИБ. Например, можно включить дополнительную стадию в свой CI\CD процесс.
Если уязвимостей слишком много, то в первую очередь нужно исправлять самые критические, потом средние и в самом конце, если есть время и желание, то уязвимости с самым низким приоритетом.
Google и другие исследователи ИБ уже сделали многое, что нашли эти уязвимости и прислали вам для исправления. Никто из них вам больше ничего не должен, поэтому не нужно ждать, что кто-то будет вам присылать ещё и патчи для закрытия этих уязвимостей. Уязвимости должны исправлять мейнтейнеры проекта. Если из мейнтейнеров есть только сам автор этого ПО, то вопрос уже к нему, почему он не набрал к себе в команду других людей или почему не занимается расширением своего комьюнити.
Если какая-то компания или исследователь ИБ прислали вам тонну уязвимостей, то обсудите с ними, в каком порядке вы будете их исправлять и когда примерно, можно будет их обнародовать. С другой стороны тоже сидят люди, а не роботы и с понимаем отнесутся к вам, если будут знать, что уязвимости будут исправлены, а так как репортов было очень много, то на это потребуется больше времени, чем ранее ожидалось. В общем, будьте людьми и начните друг с другом общаться, а не видеть во всех, присылающих вам баги и уязвимости, врагов.
Никто не обязан нести ответственность. Хотите написать свое ПО - вперед. Open source - это не обязанность.
Разработчик open source проекта несёт ровно столько же ответственности за исправление уязвимостей, сколько и closed source - очень часто "no warranty".
Размер (конкретного) ПО и количество багов конечно только если проект больше не получает новых фич, лишь исправления багов. И даже в этом случае, количество багов может расти: обновились системные библиотеки, железо, настройки окружения - и ваш продукт начал вести себя не как положено.
"теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей" - и эти 10 сканеров найдут 10 000 уязвимостей, из которых не галлюцинациями будут, скажем, 3% - как один человек это всё проверит? Почитайте Death by a thousand slops, особенно 4 пример, Buffer overflow in strcpy
"Например, можно включить дополнительную стадию в свой CI\CD процесс" - см. п. 3 про кучу не-уязвимостей. А кто будет за эти прогоны платить, лично GitHub?
Да.
Не обязательно быть мейнтейнером, чтоб стать контрибутором. Раз уж говорим про open source, то вот как раз патч прислать может любой мимокрокодил. Да, не факт, что любой "мимокрокодильный" патч примут как есть, но он как минимум покажет один из возможных методов исправления.
С другой стороны как раз сидит ИИшенка, которая по своему шаблону завела баг. И даже если нет - в самом баге УЖЕ написано, какие сроки разглашения - почему сторона, создающая баг не могла первой связаться с представителями проекта?
Когда вам в проект накидывают кучу... просто кучу, вам нужно потратить время и силы чтобы это всё разобрать, категоризировать, приоритизировать. В какой-то момент, накидываемая куча становится настолько большой, что вы не можете с ней совладать, и она начинает бесконтрольно расти, а настоящие баги начинают теряться. Это натуральный DoS.
Тем более мерзко, что примерно в то же время, кто-то из Google дал интервью вида "наше DeepSleep такое крутое, нашло 20 багов в мультимедиа продуктах - только вот их не исправили ещё".Это подгонка фактов и вампирский пиар. Аж сейчас упоминать про это противно, тьфу.
В добавок к пункту 6.
Какой бы Гугл корпорацией зла не была, если мы берём именно текущую ситуацию и текущую уязвимость, то с чего бы вдруг Гуглу патчить/помогать патчить уязвимость в каком то там нишевом кодеке, используемом в двух с половиной играх 95 года от одной компании, которая собственно к иерархии Гугла и другим крупным корпорациям/стримингам никак не относится? Ещё бы понял причину по которой свалился шквал критики, если бы найденная уязвимость относилась "условно" к h.264, который, собственно, гуглом активно используется(использовался), но... Извините, LucasArts Smush? Я такой кодек вообще впервые вижу.
Я не придерживаюсь ничьей стороны, есть за что поругать и Гугл и представителей ffmpeg, но мне кажется сама вот эта ситуация слишком уж высосана из пальца, как СМИ и Гуглом, так и самими ffmpeg
А уязвимости нужно исправлять, да. В идеале тому, кто эту заплатку для корректного запуска ролика формата LucasArts Smush и написал. Я считаю вина здесь не Гугла и не ffmpeg'а в целом, а того контрибьютора, допустившего эту уязвимость и пустивший эту заплатку в прод, если мы говорим об open source
то с чего бы вдруг Гуглу патчить/помогать патчить уязвимость в каком то там нишевом кодеке, используемом в двух с половиной играх 95 года от одной компании, которая собственно к иерархии Гугла и другим крупным корпорациям/стримингам никак не относится?
Но баги - шлют. Если им все равно, то зачем?
Если вы нашли уязвимость, то у вас моральный долг о ней сообщить. Сначала разработчику, а через адекватное количество времени - пользователям. Чтобы все знали об опасности и могли защититься от нее.
Если вы нашли уязвимость, то у вас моральный долг о ней сообщить.
Почему вы вообще пошли искать и нашли, если вам на эту библиотеку все равно?
Гугл ищет уязвимости почти во всех популярных open-source проектах, даже в тех, которые не использует. Потому что может: https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html
Находить ≠ исправлять. И да, как вам уже ответили, у гугла под это есть отдельный проект. В любом случае, основная работа возлагается на ИИ, человеческого вмешательства там минимум, поэтому и могут. Ну и момент с "посмотлите какие мы халосые" никто не отменял :)
С пунктом 7 посмотрю. В случае Гугла с другой стороны вполне могут сидеть именно роботы, и до техподдержки достучаться тот ещё квест.
Если это реальные ошибки и уязвимости, то их в любом случае нужно исправлять. Неважно, кто эти ошибки обнаружил и сколько платят тому, кто их накодил.
Ну представьте, что некий волонтер, пользуясь имеющимся у него калькулятором, составил и опубликовал таблицу логарифмов, которая стала популярной среди математиков и инженеров. Но вдруг большая богатая корпорация, у которой есть мощные компьютеры, проверила эту таблицу и обнаружила в ней множество ошибок. Что будем делать? Оставим ошибки как есть, потому что ну он же бесплатно работал, нельзя с него что-то требовать?
Разработчики не обязаны исправлять каждый чих гугла. Пусть гугл шлет PR, если ему нужны эти исправления.
Ага, щаз. Использовать халяву и рубить бабло или работать - разные вещи.
В эту игру ведь можно играть вдвоём: разработчики не обязаны исправлять ошибки, а Гугл не обязан присылать исправления.
Например, если я нашёл ошибку в какой-то программе, никто не может меня заставить её исправлять и никто не может меня заставить о ней молчать. Не хотите исправлять - ваше право, а моё право про неё написать, например, в моём блоге.
Почему Гугл пользуется FFMpeg, вместо того, чтобы написать что-то своё? большая и богатая корпорация не выпустит свою собственную таблицу логарифмов?
Гугл может форкнуть проект и поддерживать его самостоятельно
Гугл может поставить своего разраба чинить баги и закрывать уязвимости. Думаю принимать готовые ПР будут с радостью.
Я и говорю - специально давят. Нельзя просто форкнуть опенсорс, если его поддерживают нормально. А так они опубликуют "разрабы не чинят, вы в опасности, мы вынуждены комерциализировать проект". Их форк открытым не будет
уязвимости исправлять надо. Вопрос кому
Если Гугл так печется о своей (о нашей) безопасности, то чего не напишут свое решение. Так как им надо и безопасно
Вот на Вашем примере. У Вас есть такая таблица. Вам пишут что в ней ошибка. То есть у Вас в таблице ошибка. Перещитайте таблицу заново и найдите ее. Иногда они с барского плеча шлют например у Вас ошибка в такой строке в таком столбце. Вы проверяете, но ошибку в упор не видите. Вот и просят условно говоря чтобы не только присылали условный столбец и строку но и то что насчитали. Что бы сразу было видно что насчитан бред. Всё выше сказанное не отнимает того что ошибки реально могут существовать.
Здесь речь не о том, что нельзя требовать, а о том, что возможности волонтёров ограничены, требуй - не требуй, а чисто физически угодить всем и решать все проблемы волонтеры не в состоянии. И здесь получается такая ситуация, похожая на шантаж: или вы сейчас срочно всё бросите и исправите проблему, или мы расскажем о ней всему миру и злоумышленники начнут эксплуатировать непропатченную уязвимость, вы будете выглядеть как рукожопы, а мы - все в белом и с триллионом долларов.
К тому же, это открытый бесплатный проект, требовать чего-либо здесь неэтично в принципе, особенно со стороны громадной корпорации. Вот мы создали продукт и дарим его всему миру, хотите - пользуйтесь, не хотите - не пользуйтесь. Вы имеете лицензионное право улучать и видоизменять продукт как вам вздумается. Но не надо наседать на нас со своими требованиями, мы не нанимались работать в Гугл и вы нам ничего не дали в ответ. Примерно так это выглядит.
требовать чего-либо здесь неэтично в принципе, особенно со стороны громадной корпорации. Вот мы создали продукт и дарим его всему миру, хотите - пользуйтесь, не хотите - не пользуйтесь.
Ну вот я придумал вкусный рецепт и бесплатно раздаю его людям. Вот только в нем есть небольшая ошибка, из-за которой в кухонной плите при определенных редких обстоятельствах происходит утечка газа. Этично будет потребовать, чтобы я исправил эту ошибку? Или мне можно продолжать раздавать рецепт как есть, не хотите - не пользуйтесь?
Этично будет предложить исправление ошибки.
Вы не можете требовать, кто вы такой, грубо говоря, что бы требовать? Вы можете просить.
А компания, и тем более волонтеры, не обязаны ради безопасности пользователей этого бесплатного сервиса жертвовать своим свободным временем и всем остальным в угоду другим.
Это волонтеры и опенсорс. Требовать даже рассмотреть готовый PR будет лишним. Попросить - да, но не требовать.
Нет, не этично. Проблема в плите, а не в рецепте. Вы должны требовать исправить плиту, потому что утечка в ней. А не обкладывать все рецепты в интернете костылями
Нет, требовать ничего вы не можете. Если это общественно опасно - вы можете обратиться куда следует с просьбой запретить распространение этого рецепта.
Можете предложить решить эту проблему, или предложить свое решение. Еще вы можете предложить решение проблемы производителю плиты, а так же поставщику газа (например поставить датчик утечки и автоматический клапан)
В вашем примере ошибки найдены и исправлены, остаётся только сделать PR на замену. Разработчики совершенно не против, если Гугл будет слать им PR'ы с исправленными ошибками
Как тебя заминусовали однако.
Давайте с другого конца зайдем. Гугл пушит волонтеров исправлять всякий бред, угрожая раскрыть эксплоит всему миру. Логично что у волонтеров ни возможности ни желания нет, это тупо шантаж. Более корректно было сообщить всему миру рейтинг безопасности ПО, без деталей, что бы пользователи сами принимали решение - а так они сами говорят хакерам "фас". А если те кто находит уязвимости в их сраных продуктах будут не им за вознаграждение (некислое весьма) сообщать, а сразу в даркнет сливать - им понравится? Может на то и расчет - выдавить опенсорс и начать делать платные форки? Уверен в хроме и андроиде уязвимостей больше и они критичнее
Настораживает упомянутое слово "CVE-слоп" и недосказанность в отношении ложных срабатываний, про которые говорится на сайте FFmpeg ( https://ffmpeg.org/security.html ). Есть вероятность, что Гугл идёт по тому же пути, что и множество ИИ-энтузиастов ранее, заваливавших настоящих разрабов отчётами о ненастоящих уязвимостях (чтобы быстро набрать стату о том, какие они классные эксперты по ИБ благодаря ИИ), только делает это значительно более эффективно.
В статье очень не хватает информации, что этот баг найден в кодеке для LucasArts SANM / Smush. Соответственно, "в дикой природе" используется он только для просмотра катсцен в некоторых играх LucasArts.
Какая разница, где он найден? А такая, что просто так, при стандартных сценариях работы с современным мультимедиа, наткнуться на использование этого кодека невозможно.
Добавил про это в начало новости. спасибо.
Какая разница, где он найден? А такая, что просто так, при стандартных сценариях работы с современным мультимедиа, наткнуться на использование этого кодека невозможно.
Ну к примеру, если эта CVE будет крашить мессенджер использующий ffmpeg, некоторые пользователи начнут присылать видосы с этим кодеком специально
И даже в этом случае претензия должна быть адресована не авторам ffmpeg, а команде мессенджера: нафига им в сборке ffmpeg для приложения обмена сообщениями кодек, который используется лишь в некоторых играх LucasArts? Так‑то сборка ffmpeg конфигурируется, можно выкинуть всякий [устаревший] шлак. И потом, у мессенджера бэк не проверяет, что в него загружают? Позволяет отправлять пользователям всякий нечитаемый или опасный экзот?
Файлы видео в формате mp4 с кодеком h264 (или h265) сейчас поддерживает любая мыльница. Ну OK, есть ещё WebM с VP8/VP9 и ещё какая‑нибудь матрёшка с AV1, ну ещё GIF и анимированные PNG, WebP или что там сейчас лучше GIF'а. Все остальные форматы видео в мессенджере — ненужный экзот, который просто не будет востребован пользовательской базой, значит можно безболезненно вырезать его поддержку, заодно снизив поверхность атаки. Ещё и приложение похудеет, одни плюсы.
вот только ffmpeg не поддерживает список таких ненужных кодеков. --enable-gpl у него есть, а --enable-shitcodecs - нет. Они все разрешены по умолчанию. Это надо каждому дистрибутиву и каждому сборнику самостоятельно собирать список опций --disable-shitcodec1 ... --disable-shitcodec100500
Вот с этим, пожалуй, могу согласиться. Могли бы сделать аналогично плугинам для GStreamer: разделить на условные base, good, ugly и bad, чтобы можно было целым ворохом отключать всякие некрофильские, несвободные или просто плохо написанные/работающие кодеки.
Но всё равно это не отменяет исходного тезиса: нафига тащить в мессенджер то, что там заведомо не нужно да ещё и потенциально небезопасно (чем больше перекладываний байтов из одного буфера в другой, тем больше вероятность словить какую-нибудь мерзость)? Тем более что конфигурационный скрипт ffmpeg позволяет делать так (по крайней мере в версии 4.3.1, которая оказалась у меня под рукой):
./configure --disable-everything --enable-encoder=NAME --enable-muxer=NAME --enable-parser=NAMEчто позволяет-таки легко организовать белый список технологий в сборке ffmpeg.
Я нарыл свои видео со старой нокии и нигде просмотреть не могу. Но решением было бы разделение на 2 либы, актуальную и для некрофилов
а команде мессенджера: нафига им в сборке ffmpeg для приложения
У меня возникает другой вопрос - почему оно вообще для приложения собирается, а не используется условная системная либа (ну есть же она?).
И вот в системной - это все может быть включено. Потому что мало ли что конкретному приложению понадобится.
Системная‑то, может, и есть, но к ней был бы тот же вопрос, имхо: зачем в ней что‑то сугубо нишевое, как в данном случае? Я могу себе представить, например, не знаю, приложение на смарте, которое воспроизводит ролики из старых игр, но будь я разрабом такой проги, то всё равно использовал бы свою собственную специальную сборку ffmpeg (ну, или libav* напрямую) — просто чтобы не зависеть от стороннего компонента, пусть и включённого в систему. Сегодня в общесистемной либе всё ещё есть нужный немейстримный кодек, а завтра его выпилят, потому что устарел, или небезопасен, или закончилась лицензия, или «потому что пошёл ты — вот почему» (ц). Речь ведь о чём‑то сильно специальном, а такое, по опыту, чаще всего всё равно приходится явно включать вручную.
Опять же, если говорить о поддержке видео в приложениях на смартах, можно ведь его на бэкенде конвертировать во что‑то современное — вот тут-то и понадобится спецсборка с включёнными некрофильскими кодеками, которая будет обложена 20-ю слоями виртуалок, докеров‑шмокеров, а обычному среднестатистическому пользователю смарта будет и удобно, и безопасненько. Мы ведь тут в контексте безопасности это всё обсуждаем.
Как будто бы мессенджеры не очень поддерживают MKV как видеоконтейнер?.. WebM, MOV - да, видел работающими.
Ради интереса записал OBSкой 2 секунды видео в MKV, но с обычными MP4шными кодеками (AVC + AAC LC). Telegram и Discord предлагают его скачать как любой другой бинарный файл, не показывают как видео (хотя Discord показывает превьюшку при отправке, видимо Electron сумел декодировать - Firefox тоже успешно воспроизводит MKV, если в него кинуться). Вот если переименовать файл в .mp4 - тогда всё нормально, подставляют плеер как положено.
MKV я просто упомянул как один из самых популярных форматов, а так подавляющее большинство устройств поддерживает mp4, даже, прости господи, дефолтный Windows Media Player на десктопах играет mp4, записанные современными устройствами. А если говорить о пользовательском опыте, то всё равно всякий экзот чаще всего придётся конвертировать во что-то популярное вроде mp4. Применительно к вебу, где-то даже была рекомендация перейти уже наконец с GIF на HTML5+mp4, мол, качественнее, удобнее и всё такое.
Вот если переименовать файл в
.mp4- тогда всё нормально, подставляют плеер как положено.
Это интересно, а где такое наблюдается? В веб‑версии, в приложении на Electron или в нативном приложении на смарте? Так‑то вроде принято определять MIME type по содержимому, а не по расширению, по крайней мере на бэке. Ведь от смены расширения файла на .mp4 скрипт на баше матрёшка изнутри никуда не исчезает.
сразу вспомнился мульт, ну погоди, с роботом зайца. В общем, ИИ теперь не отстанет от разработчиков, единственный путь, делать его все умнее
Вьетнамские флэшбэки пошли. Если дать дураку в руки оружие CVE-репортинга, то он даже святых за**ет. Живо вспоминаю, как пришлось перепахивать проект под новую мажорную версию log4j (или slf4j, не помню уже) только потому, что когда Венера противостоит Марсу в високосный год, то будет какая-то пепяка. Речь не про Log4Shell - оно позже обнаружилось.
И безопаснику не докажешь, что в твоем проекте этот CVE не реализуется вообще никак. Вынь да положь фикс.
О как знакомо, новые безопасники раздувая щеки от важности изнасиловали всех, заставляя убрать пару CVE которые в нашем окружении не реализовать вообще никак.
здесь, как мне кажется, другая ситуация: ваши новые безопасники это та же самая ваша организация. Они "насилуютвсех" за деньги этой же организации и тратят ее время и ресурсы на (возможно, по вашему мнению) бесполезные активности.
здесь же - внешняя организация с огромными доходами по сути шантажирует волонтеров (ситуацию "если вы за 3 месяца не исправите - мы всем расскажем" я иначе не могу назвать), не вкладывая ресурсы, но при этом пользуясь продуктом этих волонтеров.
О, тут есть шедевр: https://nvd.nist.gov/vuln/detail/CVE-2022-42969
это ReDoS(!)-уязвимость
в коде подключения к Subversion
в антикварной библиотеке начала нулевых, которую почти никто уже использует и которая почти не поддерживается
и которая, по-случайности, оставалась в самом популярном инструменте для тестирования в Python для каких-то малоиспользуемых функций
Думаю, у разработчиков последней было много нецензурных слов.
Искал как-то через нейросеть утечку памяти в своем коде. Она выдала много потенциальных мест, а настоящую причину утечки так и не нашла.
Тут вполне может быть такой же шлак. Кидают баги, которые вероятно багами и не являются.
Думаю командам OS проектам нужно прописать более строгие правила принятия багрепортов. Например обязательное описание полного воспроизведения бага.
обязательное описание полного воспроизведения бага.
Так нейронка и его напишет, и тоже без гарантии, что по этому описанию баг будет воспроизводиться
Думаю командам OS проектам нужно прописать более строгие правила принятия багрепортов. Например обязательное описание полного воспроизведения бага.
Багтрекер гугловый, насколько я понимаю. Там особо правил не попишешь.
Как вариант, почему бы Гуглу не отказаться от использования FFmpeg (нафига им пользоваться неконтролируемым инструментом?), и запилить свой аналог с блэкджеком? А то умные, неоплачиваемых разработчиков-добровольцев учить.
Они 100% им не пользуются (как минимум, на бумаге), потому что в их экосистеме стоит абсолютный запрет на код от GPL
а как же линукс?
FFmpeg имеет двойную лицензию LGPL/GPL, в зависимости от опций. Код самого FFmpeg - LGPL, но при вкомпиливании отдельных библиотек (libx264 например) - лицензия общего собранного продукта становится GPL. Google 100% им пользуются; например, FFmpeg встроен в Chrome.
Или LGPL
Велнхофер недавно отказался от поддержки libxml2, поскольку ему приходилось «тратить несколько часов в неделю на решение проблем безопасности, о которых сообщали третьи лица
Тем смешнее сумма 350.000₽ от Selectel за переписывание libxml2 на Rust
Парсинг XML вроде не то чтобы супер сложная задача? А уж когда весь код есть, то тем более. Написать свою библиотеку для разбора XML норм задача для курсовика для студента. Окей, сделать эту библиотеку эффективной и собирающейся под разные платформы уже сложнее, но если все грабли уже собраны разработчиками оригинальной либы, и тебе надо лишь портировать - ну не выглядит оно супер сложным. Объем кода там не должен быть уж очень большим.
Ага, классическое "задача плёвая, за пару вечеров справлюсь"
Угу. Вы спеку на XML откройте и удивитесь. Вот это, например, вполне себе валидный XML документ:
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>В сбере 10 лет назад были ежегодные проверки квалификации, и там наваливали вопросов именно с такими XML. На практике мы, конечно же, в глаза не видали таких извращений. К слову об адекватности всевозможных подтверждений квалификации.
На практике мы, конечно же, в глаза не видали таких извращений.
Их наваливают как раз для того, чтобы народ знал и учитывал, что такое может быть. Потому что в такие извращение разные уязвимости положить можно, которые ты пропустишь, если не отключишь парсинг вот этого всего.
Так себе аргументы. Если я что-то и понял за свою карьеру, так это то, что если не работаешь с чем-то, то экспертизы в этом у тебя нет. Хочешь, чтобы люди врубались в многопоточку - давай им задачи на многопоточку. Хочешь, чтобы врубались в хитровыдуманные XML - пусть встречаются с ними хоть где-то в реальности, а не выдуманных тестах. А раз в год кошмарить работяг какой-то дичью и делать выводы - это подход из анекдотов про армию.
Можно пояснение неспециалистам - куда смотреть в этом коде?
Парсинг XML вроде не то чтобы супер сложная задача?
Парсинг XML - это задница. Есть и большие задницы, конечно, но и этой достаточно.
Порядка 1000 тестов к либе и вообще XML это типа язык (эта часть функционала никому сейчас на нужна, но легаси надо сопровождать, выкинуть нельзя)
Процитиую
Потому что XML — это политический компромисс 1990-х, который пытался быть всем для всех, и в итоге превратился в стандарт, где каждый комитет вставил свою любимую фичу.
Вот три главные причины перегрузки:
1. Золотая лихорадка вендоров (Vendor Gold Rush)
В 1998 году W3C пыталась создать "универсальный язык разметки данных". За стол сели:
Microsoft (нужна поддержка Office-документов)
IBM (хотели сложные корпоративные фичи)
Sun Microsystems (Java-ориентация)
Другие гиганты
Каждый лоббировал свою фичу: "Нашим клиентам нужны внешние сущности!", "Мы не можем жить без DTD!", "Добавьте пространства имён, иначе наше решение сломается!". В итоге спецификация стала квази-стандартом мейнфреймов, а не лёгким форматом данных.
2. Feature Creep без контроля версий
XML 1.0 (1998) уже содержал 5 независимых под-спецификаций: DTD, Namespaces, XPath, XSLT, XInclude. Проблема в том, что отказаться от лишнего нельзя — это нарушит обратную совместимость. Когда в 2006 году добавили XML Schema, это был уже 7-й слой абстракции, который нужно поддерживать вместе с DTD.
Пример: простой парсер XML должен уметь:
Разрешать внешние сущности (XXE-уязвимости)
Обрабатывать CDATA-секции
Парсить DTD и XSD одновременно
Поддерживать 5+ разных кодировок внутри одного документа
3. Архитектурная ошибка: "XML как платформа"
Стандарт рассматривался не как формат данных, а как фундамент для экосистемы. Отсюда появились:
XSLT (туринг-полный язык трансформации внутри парсера)
XPointer/XLink (гипертекстовые ссылки внутри XML)
XML Catalogs (система перенаправления сущностей)
В результате минимальный корректный парсер — это не 500 строк кода, а 50,000+ строк, потому что он должен поддерживать всю эту инфраструктуру.
Цифры, которые всё объясняют:
Фича Строк кода в libxml2 Используется в реальности DTD валидация ~15,000 <5% проектов XSLT ~40,000 Удаляется из Chrome Namespace resolver ~8,000 Всегда (потому что нельзя отключить) Кодировки (iconv) ~12,000 Только для наследия
Итого: ~70% кода libxml2 служит фичам, которые 99% разработчиков никогда не используют, но не могут отключить.
Как это влияет на вас прямо сейчас:
Если вы парсите простой конфиг вроде:
<config><timeout>30</timeout></config>
Ваш код всё равно "безопасно" загружает парсер XSLT, DTD-валидатор и 15 кодировок, хотя вам они не нужны. Это не просто медленно — это прямой путь к XXE-инъекциям и Billion Laughs attacks.
Вывод: XML — это пример того, как стандартизация без жёсткого «нет» превращает простую идею (человекочитаемые данные) в архитектурный монстр, который теперь тормозит весь интернет.
Это была эпоха вендор-лока через стандартизацию. XML стал идеальным инструментом для этого механизма.
Как это работало:
1. "Enterprise Features" как барьер входа
Корпорации лоббировали фичи, которые только их продукты могли полноценно реализовать:
Внешние сущности (XXE): IBM встраивала их в WebSphere, создавая зависимость от своего парсера
XSLT: Microsoft толкала MSXML с Office-расширениями
Сложные DTD: Sun нужны были Java-специфичные сущности
Результат: конфигурация для WebSphere невалидна в простом парсере — нужен именно IBM-парсер. Это чистый vendor lock-in под видом "открытого стандарта".
2. Консорциум как инструмент лоббизма
W3C в 1998-м работала на платной основе: IBM, Microsoft, Sun платили по $50,000+ в год за голос. Они блокировали любые упрощения:
"Мы голосуем против упрощённого подмножества XML — это сломает наш продукт стоимостью $100M." — реальная позиция мейнфрейм-вендоров в архивах W3C
3. Проприетарные расширения под видом стандарта
Классика — SOAP от Microsoft:
База: простой XML-конверт
Добавили: WS-* спецификации (WS-Security, WS-Transaction, WS-Addressing)
Итог: 1500+ страниц спец, реализованных только в .NET Stack
Это был проприетарный продукт, замаскированный под открытый стандарт. Хотели взаимодействия с .NET — покупали Windows Server.
Ирония:
XML задумывался как антидот проприетарным форматам, но стал инструментом вендор-лока. А простые форматы (JSON) победили именно потому, что никто не контролировал их эволюцию — they just worked.
Вывод: libxml2 — это археологический артефакт эпохи, когда стандартизация продавалась как продукт. Сегодня такое невозможно: IETF требует работающую реализацию до стандартизации, а open source движение мгновенно создаёт простые альтернативы.
Гугл вообще охерел со своей политикой принудительной безопаности. Через тот же хром на старые сайты теперь даже не зайдешь.
Если Гугл перестанет присылать эти уязвимости проекту, а начнёт публиковать их у себя на сайте, сразу в открытую – вы все что скажете?
Не очень понятна риторика ffmpeg, много слов про нейрослоп, плохой и жадный google.
Правильно будет написать: это опенсурс проект на добровольных началах и кому не нравятся уязвимости могут записать CVE на бумажку побольше и засунуть себе их в задницу поглубже. Компактно, доходчиво и без расплывания мыслью по нейронкам.
Они же не Линус Торвальдс, чтобы про задницу отвечать.
А пора бы уже так отвечать. У нынешнего комьюнити есть какая-то проблема с аттрибуцией претензий. То ли они просто хайпят на этом то ли просто лыжи не едут. Стало это заметно еще во времена баттла синей кнопки против красной, а из недавних случаев где курьер оскорбляет покупателя за то что тот заказал 30 литров воды в дом без лифта, хотя любому очевидно что тут адресат претензий это курьерская компания а не покупатель.
Ну вот в чем проблема энтузиаста который постит от лица ффмпег в твиттере?
1) Google забивает своими багами их треккер? Да вроде нет, это треккер гугла а не самого ффмпег, у тех он по другому адресу. Можно вообще не читать его.
2) Ишьюсы не так сформулированы? Ну вроде все так, просто приоритет их ниже ноля.
3) Кто-то требует эти ишьюсы фиксить? Ну вроде тоже нет, в статье это не пишется по крайней мере.
4) Денег не платят? Ну тут конечно да, но разве должны? Энтузиасты сами решили тянуть эту телегу и они аналогично никому ничего не должны. Тут "ваши ожидания это ваши проблемы" работает на 100%.
По итогу реальная проблема за которую можно и нужно посылать это #3 но в статье истинная проблема(та которая заботит ffmpeg энтузиастов) это номер #4.
А раз сама эта причина не выглядит "достаточно благородно" в глазах комьюнити то под нее натужно подтягивается комок из #1 и #2 и даже про #3 делается намек. Зачем так делать? Выглядит очень топорно.
Я не очень понимаю в чем проблема, ну есть отчет, посмотрели что это не что-то критичное и поставили куда-нибудь в план. Зачем кидаться все исправлять сразу. Ну опубликует это гугл, в чем проблема то если это не критичная уязвимость? Пока больше похоже на попытку получить финансирование.
FFmpeg, написанный преимущественно на языке ассемблера
Ничоси.
Нужен ИИ менеджер для классификации багрепортов
Какой нейро-слоп? Пример по ссылке содержит реальную ошибку, с примером воспроизведения и крешем в ASAN. Что-то в коде пофиксили, чтобы это исправить. Т.е. ошибка была реальная, фактическая.
В коде слишком много ошибок? Ну запихните все баги в отдельный список, сделайте приватными, и не смотрите на них больше, пока не появятся ресурсы их исправлять.
Лучше уж пусть будет сообщение об ошибке, чем будет ошибка никем, кроме хакеров, не замеченная.
А что значит уязвимость ffmpeg, если он в юзерспейсе выполняется? Как их предлагается эксплуатировать? Просто интересно. Или имеются ввиду обычные баги которые назвали уязвимостями?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Команда проекта FFmpeg обратилась к Google: финансируйте нас или прекратите отправлять баги (CVE-slop) с помощью ИИ