
Комментарии 6
Я практически целиком прочитал ваш опус, но, несмотря на ваши утверждения, так и не понял, это всё-таки баг в телеграмме или в QtNetwork и он теоретически воспроизводим в других приложениях?
Это баги в QtNetwork, которые, благодаря незакрытому способу их эксплуатации в Телеграме, через Телеграм могли эксплуатироваться. Поэтому правки нужны были и туда и туда. Приложения, на которых это воспроизводится, в статье указаны: "тот же уязвимый примитив мы практически воспроизвели в qBittorrent, Nextcloud Desktop и Electrum".
То есть вы утверждаете, что закрытия бага в QtNetwork недостаточно и абсолютно такая же уязвимость через неинициализированную память остаётся в телеге даже с новой версией Qt?
Или же с пропатченным Qt уязвимость превращается в обычный баг?
Насколько я понял из текста, с пропатченным Qt уязвимость превратится просто в неудобство для пользователя, т.к. враждебный прокси будет своими требованиями авторизации ломать подключения.
А какие мировые практики в bug bounty в таких случаях, когда бага не в самом софте, а в сторонней зависимости (у которой, тоже возможно есть свой bug bounty)?
P.S. я имею в виду, если прямо сейчас собрать все проекты в мире, где есть баг баунти и найденная уязвимость в кутэ - можно сорвать большой куш :)
Telegram Desktop под атакой прокси: деанонимизация, утечка секретов и RCE с правами SYSTEM