Durant els Ășltims dies s'ha estat discutint el cas sobre les accions que van prendre un grup d'investigadors de la Universitat de Minnesota, Ja que des de la perspectiva de molts, aquestes accions en relaciĂł de la introducciĂł de vulnerabilitats en el nucli de Linux no tĂ© justificaciĂł.
I tot i que un grup d'investigadors de la Universitat de Minnesota publiquessin una carta oberta de disculpa, l'acceptaciĂł de les actualitzacions de el nucli de Linux que va ser bloquejada per Greg Kroah-Hartman, va revelar detalls dels pegats enviats als desenvolupadors de el nucli i la correspondĂšncia amb els mantenidors associats amb aquests pegats.
Ăs de destacar que tots els pegats problemĂ tics van ser rebutjats per iniciativa dels mantenidors, cap dels pegats va ser aprovat. Aquest fet deixa en clar per quĂš Greg Kroah-Hartman va actuar amb tanta duresa, ja que no estĂ clar quĂš haurien fet els investigadors si els pegats haguessin estat aprovats pels encarregats de l'manteniment.
En retrospectiva, van argumentar que tenien la intenciĂł d'informar de l'error i no permetrien que els pegats anessin a Git, perĂČ no estĂ clar quĂš farien realment o fins on podrien arribar.
En total, l'agost de 2020, es van enviar XNUMX pegats des de les direccions anĂČnimes acostag.ubuntu@gmail.com i jameslouisebond@gmail.com (una carta de James Bond): dos correctes i tres que inclouen errors ocults, creant condicions per a la apariciĂł de vulnerabilitats.
Cada pegat contenia nomĂ©s d'1 a 4 lĂnies de codi. La idea principal darrere dels pegats erronis era d'arreglar una fuga de memĂČria podria crear una condiciĂł per a una vulnerabilitat lliure doble.
El projecte té com a objectiu millorar la seguretat de l'procés de pegats a OSS. Com a part de el projecte, vam estudiar problemes potencials amb el procés de pegats d'OSS, incloses les causes dels problemes i suggeriments per dirigint-se a ells.
De fet, aquest estudi revela alguns problemes, perĂČ el seu objectiu Ă©s demanar esforços per millorar la
procĂ©s de pegats per motivar mĂ©s treball que desenvolupi tĂšcniques per a provar i verificar pegats, i finalment per fer que el US sigui mĂ©s segur.Basat en aquests pegats, resumim els seus patrons, estudiem les raons especĂfiques per les quals els pegats d'introducciĂł d'errors sĂłn difĂcils de captura (amb una anĂ lisi tant qualitatiu com quantitatiu) i, el que Ă©s mĂ©s important, proporcionar suggeriments per abordar el problema.
El primer pegat problemĂ tic va solucionar la pĂšrdua de memĂČria afegint una crida a kfree () abans de tornar el control en cas d'un error, perĂČ creant condicions per accedir a l'Ă rea de memĂČria desprĂ©s que es va alliberar (use-after-free).
El pegat especificat va ser rebutjat pel mantenidor, Qui va identificar el problema i va indicar que fa un any algĂș ja havia intentat proposar un canvi similar i va ser inicialment acceptat, perĂČ descartat el mateix dia desprĂ©s d'identificar les condicions de la vulnerabilitat.
El segon pegat tambĂ© contenia condicions per al problema d'Ășs desprĂ©s de l'alliberament. El pegat especificat no va ser acceptat pel mantenidor, que va rebutjar el pegat causa d'un altre problema amb list_add_tail, perĂČ no va notar que el punter «chdev» es pot alliberar en la funciĂł put_device, que s'usa a continuaciĂł a la crida a dev_err (& chdev -> dev ..). No obstant aixĂČ, el pegat no va ser acceptat, encara que per raons alienes a la vulnerabilitat.
Curiosament, inicialment es va assumir que 4 de cada 5 pegats tenien problemes, perĂČ els mateixos investigadors van cometre un error i en un pegat problemĂ tic, segons ell, es va proposar la soluciĂł correcta, sense les suposades condicions per utilitzar la memĂČria desprĂ©s de l'llançament.
En aquest treball, presentem el concepte de «vulnerabilitat immadura» on un falta la seva condiciĂł de vulnerabilitat, perĂČ pot esdevenir una real quan la condiciĂł Ă©s implĂcitament
introduït per un pegat per a un altre error.També desenvolupem eines que ens ajuden a trobar llocs de codi que poden patir
dels pegats d'introducciĂł d'errors i suggereixi quĂš pot fer que aquests pegats d'introducciĂł d'errors siguin difĂcils de detectar.Una setmana desprĂ©s, es va enviar informaciĂł als desenvolupadors de el nucli amb una proposta per discutir la possibilitat de promoure vulnerabilitats sota l'aparença de correccions trivials per fuites de memĂČria, perĂČ no es va dir res sobre intents anteriors d'enviar pegats maliciosos.
El tercer pegat també va ser rebutjat pel mantenidor causa d'un altre error sense vulnerabilitat (doble aplicació en pdev).