Az elmúlt napokban a a kutatók egy csoportjának intézkedéseire a Minnesotai Egyetemről, mivel sokak szemszögéből nézve a Linux kernelében található sebezhetőségek bevezetésével kapcsolatos ilyen cselekvéseknek nincs indoklásuk.
És annak ellenére, hogy egy csoport Minnesot Egyetem kutatóinyílt bocsánatkérő levél közzététele, akinek elfogadta a Linux kernel által blokkolt változtatásokat Greg Kroah-Hartman részleteket árult el a kernelfejlesztőknek benyújtott javítások és az ezekhez a javításokhoz kapcsolódó fenntartókkal folytatott levelezés.
Figyelemre méltó, hogy az összes problémás javítást elutasították A fenntartók kezdeményezésére egyik javítást sem hagyták jóvá. Ez a tény egyértelművé teszi, hogy miért lépett fel ilyen keményen Greg Kroah-Hartman, mivel nem világos, hogy mit tettek volna a kutatók, ha a javításokat a fenntartó jóváhagyta volna.
Visszatekintve, azzal érvelt, hogy szándékukban állt bejelenteni a hibát és nem engedték, hogy a javítások Githez kerüljenek, de nem világos, hogy valójában mit csinálnának, vagy meddig mehetnének el.
Összesen 2020 augusztusában öt javítást küldtek az anonim címekről: acostag.ubuntu@gmail.com és jameslouisebond@gmail.com (James Bond levele): kettő helyes és három rejtett hibát tartalmaz, amelyek megteremtik a feltételeket a sérülékenységek.
Minden javítás csak 1-4 sornyi kódot tartalmazott. A rossz javítások mögött az volt az alapötlet, hogy a memóriaszivárgás kijavítása feltételeket teremthet a kettős ingyenes sebezhetőség számára.
A projekt célja a javítási folyamat biztonságának javítása az OSS-ben. A projekt részeként megvizsgáljuk az OSS javítási folyamatának lehetséges problémáit, beleértve a problémák okait és javaslataikat azok kezelésére.
Valójában ez a tanulmány feltár néhány problémát, de célja erőfeszítések felhívása a
javítási folyamat, hogy több munkát motiváljon a javítások tesztelésére és ellenőrzésére szolgáló technikák kifejlesztésére, és végül az operációs rendszer biztonságosabbá tételére.Ezen javítások alapján összefoglaljuk azok mintázatát, tanulmányozzuk azokat a konkrét okokat, amelyek miatt a hibajavító javításokat nehéz elkapni (mind kvalitatív, mind kvantitatív elemzéssel), és ami a legfontosabb, javaslatokat adunk a probléma kezelésére.
Az első problémás javítás kijavította a memóriát a kfree () mielőtt hiba esetén visszaadná a vezérlést, de feltételeket teremtenek a memóriaterület eléréséhez a felszabadulás után (use-after-free).
A megadott javítást a fenntartó elutasította, aki azonosította a problémát és jelezte, hogy egy évvel ezelőtt valaki már megpróbált hasonló változást javasolni, és ezt eredetileg elfogadták, de a sérülékenységi feltételek azonosítása után ugyanazon a napon elvetették.
A második javítás tartalmazta a megjelenés utáni kopás kérdésének feltételeit is. A megadott javítást a fenntartó nem fogadta el, aki a list_add_tail újabb problémája miatt elutasította a javítást, de nem vette észre, hogy a "chdev" mutató felszabadítható a put_device függvényben, amelyet a dev_err (& chdev -> dev ..). A javítást azonban nem fogadták el, bár a sebezhetőséghez nem kapcsolódó okokból.
Kíváncsi, kezdetben azt feltételezték, hogy az 4 tapaszból 5-nek problémái vannak, de maguk a kutatók hibáztak, és egy problémás javításban véleményük szerint a helyes megoldást javasolták, anélkül, hogy feltételeznék a memória használatát az indítás után.
Ebben a munkában bemutatjuk az „éretlen sebezhetőség” fogalmát, ahol a sérülékenység feltétele hiányzik, de valóságossá válhat, ha a feltétel implicit módon fennáll
egy másik hiba javításával vezette be.Olyan eszközöket is kifejlesztünk, amelyek segítenek megtalálni az esetlegesen szenvedő kódhelyeket
a hibajavító javítások közül, és javasolja, mi nehezítheti ezeket a hibajavító javításokat.Egy héttel később információkat küldtek a kernel fejlesztőinek azzal a javaslattal, hogy megvitassák a memóriaszivárgások apró javításainak leple alatt a sebezhetőségek előmozdításának lehetőségét, de a rosszindulatú javítások beküldésének korábbi kísérleteiről nem szólt semmi.
A harmadik javítást a karbantartó szintén elutasította egy újabb, sebezhetőség nélküli hiba miatt (kettős alkalmazás a pdev-ben).