La programistoj de la poŝtelefona operaciumo Aurora (forko de la Sailfish OS evoluigita de la kompanio Open Mobile Platform) konigis malkaŝan rakonton pri elimino. () en Glibc, kiu aperas nur sur la ARMv7-platformo. Informoj pri la vundebleco estis malkaŝitaj en majo, sed ĝis la lastaj tagoj, korektoj ne estis disponeblaj, malgraŭ la fakto, ke la vundeblecoj. alta nivelo de danĝero kaj ekzistas funkcianta prototipo de ekspluato, kiu ebligas al vi organizi kodan ekzekuton dum prilaborado de datumoj formatitaj en certa maniero en la memcpy() kaj memmove() funkcioj. Pakaj korektoj por и ankoraŭ ne estis liberigitaj kaj la vundebleco restas nefiksita dum preskaŭ du monatoj de la momento de publika malkaŝo kaj kvin monatoj de la momento, kiam la programistoj de Glibc estis sciigitaj.
La vundebleco manifestiĝis en la efektivigo de memcpy () kaj memmove () en asembla lingvo por ARMv7 kaj estis kaŭzita de malĝusta prilaborado de negativaj valoroj de la parametro, kiu determinas la grandecon de la kopiita areo. Problemoj kun disvolvado komenciĝis kiam kompanioj и anoncis, ke iliaj platformoj ne estas tuŝitaj de la problemo, ĉar ili ne konstruas por 32-bitaj ARMv7-sistemoj, kaj ne partoprenis en kreado de riparo. La programistoj de multaj enigitaj distribuoj ŝajnas esti fidinta al la Glibc-teamo, kaj ankaŭ ne aktive okupiĝis pri preparado de la riparo.
Eblo Por bloki la problemon, Huawei preskaŭ tuj proponis, ke ĝi klopodu anstataŭigi asemblajn instrukciojn funkciantan per subskribitaj operandoj (bge kaj blt) per nesubskribitaj analogoj (blo kaj bhs). La prizorgantoj de Glibc evoluigis aron da testoj por kontroli diversajn erarkondiĉojn, post kio montriĝis, ke la diakilo de Huawei ne taŭgas kaj ne prilaboris ĉiujn eblajn kombinaĵojn de enigo-datumoj.
Ĉar Aurora OS havas 32-bitan konstruon por ARM, ĝiaj programistoj decidis fermi la vundeblecon memstare kaj proponi solvon al la komunumo. La malfacileco estis, ke necesis verki efikan asemblalingvan efektivigon de la funkcio kaj konsideri diversajn opciojn por enigargumentoj. La efektivigo estis reverkita uzante nesubskribitajn instrukciojn. Ĝi montriĝis malgranda, sed la ĉefa problemo estis konservi ekzekutrapidecon kaj eviti rendimentan degeneron de la memcpy kaj memmove-funkcioj, konservante kongruecon kun ĉiuj kombinaĵoj de enigvaloroj.
Komence de junio, du versioj de la riparo estis preparitaj, pasigante la testan kadron de la Glibc-subtenantoj kaj la internan testaro de Aurora. La 3-an de junio, unu el la elektoj estis elektita kaj al la dissendolisto Glibc. Semajnon poste
estis alia flikaĵo simila en aliro, kiu korektis problemon en la multiarka efektivigo, kiun Huawei antaŭe provis ripari. Testado daŭris monaton kaj pro la graveco de la flikilo.
8 julio korektoj al la ĉefa branĉo de la venonta glibc 2.32 eldono. La efektivigo inkluzivas du diakilojn − por la multiarka efektivigo de memcpy por ARMv7, kaj por la ĝenerala asembla lingvo efektivigo de memcpy() kaj memmove() por ARM.
La problemo influas milionojn da ARMv7-aparatoj kurantaj Linukso, kaj sen la taŭga ĝisdatigo, posedantoj estas en risko kiam ili konektas ilin al la reto (reto-alireblaj servoj kaj aplikoj kiuj akceptas enigajn datumojn sen grandecaj limigoj povas esti atakitaj). Ekzemple, la ekspluatado preparita de la esploristoj, kiuj identigis la vundeblecon, montras kiel ataki HTTP-servilon konstruitan en aŭto-informsistemon sendante tre grandan GET-peton kaj akirante radikan aliron al la sistemo.
fonto: opennet.ru