През последните няколко дни дело относно действията, предприети от група изследователи от университета в Минесота, тъй като от гледна точка на много такива действия във връзка с въвеждането на уязвимости в ядрото на Linux нямат оправдание.
И въпреки че група Изследователи от Университета в Минесотда публикува отворено писмо с извинение, чието приемане на промени в ядрото на Linux, което беше блокирано от Грег Кроах-Хартман, разкри подробности на кръпки, изпратени на разработчиците на ядрото и кореспонденция с поддържащи, свързани с тези кръпки.
Забележително е, че всички проблемни кръпки бяха отхвърлени По инициатива на поддържащите, нито един от пластирите не е одобрен. Този факт става ясно защо Грег Кроах-Хартман е действал толкова грубо, тъй като не е ясно какво биха направили изследователите, ако лепенките бяха одобрени от поддържащия.
В ретроспекция, твърди, че възнамеряват да съобщят за грешката и те не биха разрешили на кръпки да отидат в Git, но не е ясно какво всъщност биха направили или докъде биха могли да стигнат.
Като цяло през август 2020 г. бяха изпратени пет кръпки от анонимните адреси acostag.ubuntu@gmail.com и jameslouisebond@gmail.com (писмо от Джеймс Бонд): две коректни и три, включително скрити грешки, създаващи условия за появата на уязвимости.
Всеки пластир съдържа само 1 до 4 реда код. Основната идея зад лошите кръпки беше, че отстраняването на изтичане на памет може да създаде условие за двойна безплатна уязвимост.
Проектът има за цел да подобри сигурността на процеса на корекция в OSS. Като част от проекта ние изучаваме потенциални проблеми с процеса на корекция на OSS, включително причините за проблемите и предложения за тяхното отстраняване.
Всъщност това проучване разкрива някои проблеми, но целта му е да призове за усилия за подобряване на
процес на закърпване, за да мотивира повече работа за разработване на техники за тестване и проверка на кръпки и накрая за да направи операционната система по-сигурна.Въз основа на тези кръпки ние обобщаваме техните модели, изучаваме конкретните причини, поради които е трудно да се уловят корекции за въвеждане на грешки (както с качествен, така и с количествен анализ), и най-важното даваме предложения за справяне с проблема.
Първата проблемна корекция коригира изтичането на памет, като добави повикване към kfree () преди връщане на контрола в случай на грешка, но създаване на условия за достъп до областта на паметта, след като е била освободена (use-after-free).
Посоченият пластир е отхвърлен от поддържащия, който идентифицира проблема и посочи, че преди година някой вече се е опитал да предложи подобна промяна и първоначално е била приета, но отхвърлена същия ден след идентифициране на условията на уязвимост.
Вторият пластир също съдържаше условия за проблема с износването след освобождаването. Посоченият пластир не беше приет от поддържащия, който отхвърли кръпката поради друг проблем със list_add_tail, но не забеляза, че указателят "chdev" може да бъде освободен във функцията put_device, която се използва следващата в извикването на dev_err (& chdev -> dev ..). Пачът обаче не беше приет, макар и по причини, несвързани с уязвимостта.
Любопитно е, първоначално се предполагаше, че 4 от 5 лепенки имат проблеми, но самите изследователи са допуснали грешка и в проблемен участък, според тях, е предложено правилното решение, без предполагаемите условия за използване на паметта след стартирането.
В тази работа ние представяме концепцията за „незряла уязвимост“, при която условие за уязвимост липсва, но може да се превърне в истинско, когато условието е имплицитно
въведено от кръпка за друга грешка.Също така разработваме инструменти, които ни помагат да намерим места с код, които могат да страдат
на лепенките за въвеждане на грешки и да предложи какво може да затрудни откриването на тези лепенки за въвеждане на грешки.Седмица по-късно бе изпратена информация до разработчиците на ядрото с предложение да се обсъди възможността за популяризиране на уязвимости под прикритието на тривиални корекции за изтичане на памет, но нищо не беше казано за предишни опити за изпращане на злонамерени кръпки.
Третата корекция също беше отхвърлена от поддържащия поради друга грешка без уязвимост (двойно приложение в pdev).