Ang mga detalye sa mga patch na isinumite ng University of Minnesota ay isiniwalat

Sa huling ilang araw ang kaso sa mga aksyon na isinagawa ng isang pangkat ng mga mananaliksik mula sa Unibersidad ng Minnesota, dahil sa pananaw ng marami, ang mga naturang pagkilos kaugnay sa pagpapakilala ng mga kahinaan sa Linux Kernel ay walang katwiran.

At kahit isang pangkat Mga Mananaliksik sa Unibersidad ng Minnesotupang mai-publish ang isang bukas na liham ng paghingi ng tawad, na ang pagtanggap ng mga pagbabago sa Linux kernel na na-block ng Nagsiwalat si Greg Kroah-Hartman ng mga detalye ng mga patch na isinumite sa mga developer ng kernel at pagsusulatan sa mga nagpapanatili na nauugnay sa mga patch na ito.

Kapansin-pansin na lahat ng mga patch ng problema ay tinanggihan Sa inisyatiba ng mga nagpapanatili, wala sa mga patch ang naaprubahan. Ang katotohanang ito ay linilinaw kung bakit si Greg Kroah-Hartman ay kumilos nang napakalupit, dahil hindi malinaw kung ano ang gagawin ng mga mananaliksik kung ang mga patches ay naaprubahan ng tagapag-ingat.

Sa paggunita, Nagtalo na nilayon nilang iulat ang bug at hindi nila papayagan ang mga patch na magtungo sa Git, ngunit hindi malinaw kung ano talaga ang gagawin nila o kung hanggang saan sila makakarating.

Sa kabuuan, noong Agosto 2020, limang mga patch ang ipinadala mula sa mga hindi nagpapakilalang mga address acostag.ubuntu@gmail.com at jameslouisebond@gmail.com (isang liham mula kay James Bond): dalawang tama at tatlo kasama ang mga nakatagong error, lumilikha ng mga kundisyon para sa hitsura ng mga kahinaan.

Ang bawat patch ay naglalaman lamang ng 1 hanggang 4 na mga linya ng code. Ang pangunahing ideya sa likod ng mga hindi magagandang patch ay ang pag-aayos ng isang pagtagas sa memorya ay maaaring lumikha ng isang kundisyon para sa isang dobleng libreng kahinaan.

Nilalayon ng proyekto na mapabuti ang seguridad ng proseso ng pag-patch sa OSS. Bilang bahagi ng proyekto, pinag-aaralan namin ang mga potensyal na problema sa proseso ng pag-patch ng OSS, kasama ang mga sanhi ng mga problema at mungkahi para sa pagtugon sa mga ito.

Sa katunayan, ang pag-aaral na ito ay nagsisiwalat ng ilang mga problema, ngunit ang layunin nito ay upang tumawag para sa mga pagsisikap upang mapabuti ang
proseso ng pagtambal upang mag-udyok ng higit pang trabaho upang makabuo ng mga diskarte upang subukan at mapatunayan ang mga patch, at sa wakas upang gawing mas ligtas ang OS.

Batay sa mga patch na ito, binubuod namin ang kanilang mga pattern, pinag-aaralan ang mga tukoy na dahilan kung bakit mahirap mahuli ang mga patch ng pagpapakilala (na may parehong husay at dami na pagsusuri), at higit sa lahat, nagbibigay ng mga mungkahi para sa pagtugon sa problema.

Ang unang may problemang patch ay naayos ang tagas ng memorya sa pamamagitan ng pagdaragdag ng isang tawag sa kfree () bago ibalik ang kontrol kung sakaling may isang error, ngunit lumilikha ng mga kundisyon upang ma-access ang lugar ng memorya pagkatapos na ito ay napalaya (use-after-free).

Ang tinukoy na patch ay tinanggihan ng nagpapanatili, na nakilala ang problema at ipinahiwatig na isang taon na ang nakalilipas ay may isang tao na sumubok na imungkahi ng isang katulad na pagbabago at ito ay unang tinanggap, ngunit itinapon sa parehong araw pagkatapos makilala ang mga kondisyon sa kahinaan.

Naglalaman din ang pangalawang patch ng mga kundisyon para sa isyu ng pagsusuot ng post-release. Ang tinukoy na patch ay hindi tinanggap ng nagpapanatili, na tumanggi sa patch dahil sa isa pang problema sa list_add_tail, ngunit hindi napansin na ang "chdev" pointer ay maaaring mapalaya sa pagpapaandar ng put_device, na ginagamit sa susunod sa tawag sa dev_err (& chdev -> dev ..). Gayunpaman, ang patch ay hindi tinanggap, kahit na para sa mga kadahilanang walang kaugnayan sa kahinaan.

Nagtataka, sa una ay ipinapalagay na 4 sa 5 mga patch ang may mga problema, ngunit ang mga mananaliksik mismo ay nagkamali at sa isang may problemang patch, sa kanilang palagay, ang tamang solusyon ay iminungkahi, nang walang inaakalang mga kundisyon upang magamit ang memorya pagkatapos ng paglunsad.

Sa gawaing ito, ipinakita namin ang konsepto ng «immature kahinaan» kung saan kulang ang isang kundisyon ng kahinaan, ngunit maaari itong maging isang tunay na kapag ang kundisyon ay implicitly
ipinakilala ng isang patch para sa isa pang bug.

Bumubuo rin kami ng mga tool na makakatulong sa amin na makahanap ng mga lugar ng code na maaaring magdusa
ng mga patch ng pagpapakilala ng bug at iminumungkahi kung ano ang maaaring maging mahirap na tuklasin ang mga patch ng pagpapakilala ng bug.

Pagkalipas ng isang linggo, ipinadala ang impormasyon sa mga developer ng kernel na may panukala na talakayin ang posibilidad ng paglulunsad ng mga kahinaan sa ilalim ng pagkukulang ng mga walang kabuluhang pag-aayos para sa mga paglabas ng memorya, ngunit walang sinabi tungkol sa mga nakaraang pagtatangka upang magsumite ng mga nakakahamak na patch.

Ang pangatlong patch tinanggihan din ito ng nagpapanatili dahil sa isa pang bug nang walang kahinaan (dobleng aplikasyon sa pdev).


Ang nilalaman ng artikulo ay sumusunod sa aming mga prinsipyo ng etika ng editoryal. Upang mag-ulat ng isang pag-click sa error dito.

Maging una sa komento

Iwanan ang iyong puna

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *

*

*

  1. Responsable para sa data: Miguel Ángel Gatón
  2. Layunin ng data: Kontrolin ang SPAM, pamamahala ng komento.
  3. Legitimation: Ang iyong pahintulot
  4. Komunikasyon ng data: Ang data ay hindi maiparating sa mga third party maliban sa ligal na obligasyon.
  5. Imbakan ng data: Ang database na naka-host ng Occentus Networks (EU)
  6. Mga Karapatan: Sa anumang oras maaari mong limitahan, mabawi at tanggalin ang iyong impormasyon.