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).