Новые взломы на Pwn2Own 2021: побеждены Ubuntu Desktop, Windows 10, Zoom и кое-что еще

[JPEGEC]

Участники предприняли три попытки взломать Ubuntu Desktop. Из них засчитано две: победители этой секции показали способ локального повышения привилегий через эксплуатацию ранее неизвестных уязвимостей. Они связаны с переполнением буфера и двойным освобождением памяти. Подробности станут известны через 90 дней — именно столько дается разработчикам взломанных продуктов для ликвидации проблем.

Странно звучит. Реально разработчики убунту десктопа фиксят уязвимости баша, вима, постфикса и прочих где нашли уязвимость?

[Denis_Andreevich]

Я не эксперт в области свободного ПО, но уверен, что у Canonical есть свои разработчики, которые хорошо знакомы с исходниками ключевых программ. Те в свою очередь могут контребьютить в мастер-ветку.

[JPEGEC]

Те в свою очередь могут контребьютить в мастер-ветку.

Очень сомнительно. Скорее поверю что свой пакет соберут с патчами поверх оригинального кода.

[LynXzp]

Нет смысла напрямую контрибьютить в мастер ветки всего ПО, достаточно создать нормальный issue и/или PR, и все будет принято. Патчи хорошо, но кто их поддерживать будет? С течением времени это буду уже форки, а не патчи.

[JPEGEC]

Я предположу что вы не подавали ченч реквесты в опенсорс. Там тот еще зверинец.
Так же ради интереса загляните в какой из пакетов того же debian. Там норма по 10 патчей от дистростроителей. Притом присутсвуют годами, ожидая когда авторы софта поправят багу.
Автор того же deadbeaf очень быстро бросил попытки пытаться пропихнуть свои исправления, и тащит все либы прямо в пакете.

[LynXzp]

Подавал. Парочку принимали сражу же. Кстати одно issue было отправлено 31 декабря вечером в deadbeef и исправлено 1 января в первой половине дня. Подавал на совместимость с FreeBSD софта написанного для MacOS, там я в issue вежливо спросил нельзя ли исправить, и показал какие я внес изменения которые бы позволили работать и там и там, автор просто внес эти изменения в мастер без дополнительных вопросов.
Но были случаи разные, например со словами «это уже исправлено в предыдущей версии», хотя я ясно указал что это проблема в новой. Были просто проигнорированы, но скорее в софте уже не поддерживаемом, но используемом. Был отправлен в workaround exist, no need to fix и т.п. Часто просят потанцевать и поприседать правильно оформляя патчи / issue. Но в общем случае все не так плохо.

[JPEGEC]

Разумеется не так все и плохо, адекватных больше. Но и не так легко и просто как «просто подать и все будет ок». А закрывать нужно прямо сейчас, поэтому патчи к пакету в дистрибутиве.

[netch80]

Скорее поверю что свой пакет соберут с патчами поверх оригинального кода.

Это не противоречит предыдущему, а делается одновременно с ним. Пусть текущая версия апстрима некоторой buka — 6, есть в поддержке 5.3 и 4.5, а в дистрибутиве собрана 4.5.12-23 (номер после дефиса — версия сборки). Одновременно будет:
1) собрана 4.5.12-24 с патчем;
2) в апстрим будет предложен этот патч для 4.5; там через несколько дней выпустят 4.5.17;3) в апстрим будет предложен патч для 6, даже если лечение для него кардинально отличается (ну и через несколько дней выпустят какую-нибудь 6.4). Возможно, его в таком виде отвергнут из-за стиля или несоответствия плану, но переделают по-своему.
Наблюдалось уже тысячи раз по одному и тому же шаблону.
Случаи с отказом, что вы описываете рядом — тоже бывают, да. Но именно для секьюрити проблем это редчайшие случаи. Для функциональности — если правка расходится с линией партии — да, могут тянуть, вплоть до того, что в дистрибутиве разрабатывают совсем свою ветку (редко, но бывает — из знаменитых был т.наз. gcc 2.96); но тоже это никак не общее место, а исключение (пара процентов).
(И не все патчи дистрибутива это правки дыр/ошибок — бывает много заточек под локальную специфику.)