Управлението на уязвимостите често се опира на опростен модел. Даден CVE идентификатор препраща към съответна корекция за сигурност, някой я прилага и задачата се затваря. Това опростяване покрива по-голямата част от корекциите в софтуера с отворен код. Част от тях обаче функционират по различен начин, пристигайки като поредица от два или повече комита (commits), при които първият оставя слабостта неотстранена.

Изследователи от Тексаския университет в Далас анализираха 1646 CVE за отворен код в Националната база данни за уязвимости (NVD), които съдържат повече от една корекция за сигурност, подбрани от записи между 1999 г. и 2025 г. Тези случаи са малка част от общия брой – близо един на всеки петнадесет CVE за отворен код в базата данни, които имат свързана корекция. Оперативната тежест обаче се намира в интервала между първата и последната корекция – прозорец, в който софтуерът остава незащитен.

Групата отчита средно по 2,55 корекции за сигурност на CVE, като натоварването се разпределя неравномерно между проектите. ImageMagick, който поддържа няколко активни версии едновременно, се нуждае от повече от един комит за близо една трета от своите корекции – процент, дължащ се на необходимостта едно и също отстраняване да се пренася към всяка поддържана версия.

Три начина, по които една единична корекция се оказва недостатъчна

Екипът разпределя случаите с множество корекции в три групи. Най-голямата обхваща уязвимости, които съществуват на повече от едно място. Подобен код с дефекти се появява в отделни клонове, методи или проекти, а Git не може да приложи един комит към всички клонове едновременно, затова разработчикът пренася промяната на всяко засегнато място. Корекциите, разпръснати в различни клонове или проекти, съставляват най-голямата единична подкатегория с 830 записа.

Втората група обединява промяната на сигурността със съпътстваща работа, като например временно решение (workaround), запис в дневника на промените или обновяване на документацията, комитнати самостоятелно. Третата група носи най-голям риск. Това са дефектни корекции, при които първата кръпка или пропуска част от уязвимостта, или добавя нов бъг. Непълните корекции сами по себе си представляват 641 от записите, явявайки се втората най-голяма подкатегория в изследването.

Препълването на целочислена стойност (integer overflow) във файловата система Linux XFS, регистрирано като CVE-2012-0038, илюстрира този модел. Първият комит добавя проверка на границите. Той обаче разчита на помощна функция, която връща цяло число без знак, подавайки стойност, която кодът третира като число със знак, поради което проверката е могла да бъде заобиколена. Втори комит променя типа на променливата и затваря пролуката. Пълната корекция е внедрена 18 дни след първия опит.

Инструментите за откриване пропускат остатъчния риск

Автоматизираните инструменти помагат изключително малко за разграничаването на частична от пълна корекция. Изследователите тестват седем модела за откриване върху набора с непълни корекции, включително CodeBERT, UniXcoder, LineVul, Devign и ReVeal, като изискват от всеки да класифицира коригирания код като уязвим или чист.

Точността и F1 оценката на всеки модел падат под 50% – граница, която авторите определят като по-лоша от случайно налучкване. Моделите са склонни да дават един и същ етикет на версиите на дадена функция преди корекцията, в междинното състояние и след нея, тъй като корекцията за сигурност променя съвсем малка част от кода.

Оценяваните модели са системи с отворен код за научноизследователски цели, тествани върху публични данни. Уейлианг Ци, съавтор на изследването, споделя, че екипът умишлено е изключил търговските продукти от тестовете. „Тъй като нашите тестови случаи идват от публични записи за уязвимости, патентованите инструменти може вече да съдържат сигнатури за същите CVE, което прави трудно разграничаването на реалното обобщение от предварителните знания“, казва Ци пред Help Net Security. Неговите очаквания за представянето на тези продукти се основават на начина им на работа: „повечето търговски инструменти, доколкото ни е известно, разчитат на техники като съпоставяне на сигнатури и кодови модели, които са сходни с подходите в оценяваните от нас инструменти. Поради това очакваме те да се сблъскат с подобни ограничения при откриването на непознати непълни корекции и корекции на множество места.“

Инструментите, които търсят копия на уязвим код в дадена кодова база, изпитват трудности при същите обстоятелства. Два детектора за клониран код с отворен код, ReDebug и FIRE, са насочени към случаите с множество местоположения, като използват първата корекция за създаване на сигнатура за следващите места. Способността на FIRE да улавя повтарящия се уязвим код спада от 90% до около 52% при нивото на истински положителни резултати (true positive rate). Уязвимите места в тези случаи се различават достатъчно едно от друго, така че сигнатура, изградена от първото място, пропуска останалите.

Времевият фактор превръща тези пропуски в излагане на риск. Близо една трета от корекциите с множество кръпки (31,7%) изискват повече от един ден, за да преминат от първия комит до последния. Пренасянето между различни клонове и проекти отнема най-много време, а забавянето създава предпоставки за надпревара. След като един клон получи публична корекция, атакуващите могат да прочетат същото хранилище, да открият еквивалентната слабост в некоригиран клон и да я експлоатират, преди пренасянето да е приключило.

Уязвимост за произволно качване на файлове в Chamilo LMS, регистрирана като CVE-2023-4226, следва точно този модел. Първоначално е пуснато временно решение за защита, а официалната корекция за сигурност го последва 16 дни по-късно.

Ци е предпазлив по отношение на изводите от данните. „Не откриваме преки доказателства за експлоатиране на уязвимостите по време на тези интервали. Нашето проучване измерва прозореца на излагане на риск, а не активността на атакуващите, така че описаният от нас риск на този етап е структурен“, отбелязва той.