Kas yra formatavimo eilutės klaida ir kodėl ji vis dar svarbi?
A formatavimo eilutės klaida atsiranda, kai vartotojo kontroliuojami duomenys perduodami kaip formatavimo eilutė tokiose funkcijose kaip printf, fprintf arba syslog, be patvirtinimo.
Kalbant paprastai, Formatavimo eilutės klaida įvyksta, kai vartotojo įvestis naudojama kaip formatavimo šablonas, leidžiantis netyčia skaityti arba rašyti atmintyje. Tai ypač pavojinga tokiose kalbose kaip C / C ++, kur formato specifikatoriai, pvz., %s, %x, bei %n gali tiesiogiai manipuliuoti stekų duomenimis.
Kodėl tai svarbu šiuolaikiniame „DevSecOps“? Kadangi šios klaidos vis dar randamos aktyviose kodų bazėse, ypač:
- Atvirojo kodo komponentai su senuoju C kodu
- Gimtosios sąsajos „Python“, „Go“ arba „Rust“ kalbomis
- Automatiškai sujungtas trečiosios šalies kodas gamybinėje aplinkoje pipelines
Poveikis realus: atminties nutekėjimas, stekų sugadinimas ir netgi nuotolinis kodo vykdymas (RCE)Ir vis dėlto daugelis komandų pasitiki statiniais skaitytuvais ir nepastebi šių klaidų, nebent jos būtų specialiai tikrinamos.
Tiesiai prie kodo: printf(vartotojo_įvestis) ir pavojus
Pažvelkime į dažną klaidą:
printf(vartotojo_įvestis);
Ši frazė yra tiesus kelias į bėdą. Jei taip vartotojo_įvestis yra kažkas panašaus %x %x % x% %x, tai nurodo printf nuskaityti reikšmes iš steko, atidengiant atmintį. Dar blogiau, jei %n yra įtrauktas, užpuolikas gali įrašyti savavališkas reikšmes į atmintį.
Šis modelis ne tik nutekins duomenų paketą, bet ir gali sugadinti atmintį bei sukelti nuotolinį kodo vykdymą (RCE). Būtent taip praktiškai atrodo formatavimo eilutės pažeidžiamumas. Šie pažeidžiamumai nesukelia kompiliatoriaus klaidų ar įspėjimų, nebent būtų įjungtos specialios vėliavėlės ar valymo priemonės. Daugeliu atvejų jie yra paslėpti apvalkaluose arba naudingumo funkcijose, todėl yra nematomi atsitiktinėms kodo peržiūroms.
Atminties sugadinimas 101: kas iš tikrųjų yra pavojuje
Kai fPasinaudojus „ormat“ eilutės klaida, užpuolikai gali:
- Išmesti atminties adresus ir steko reikšmes naudojant %x or %s
- Perrašykite steko kintamuosius arba grąžinimo adresus su %n
- Sukelia segmentavimo sutrikimus arba logikos klaidas dėl atminties sugadinimo
- Pereikite prie visiško RCE, ypač jei apsaugos priemonės, tokios kaip ASLR arba „stack canaries“, yra neteisingai sukonfigūruotos.
Čia padeda suprasti kamino rėmą. printf nežino, kiek argumentų tikėtis; jis visiškai pasikliauja formato eilute. Štai kodėl %x vaikšto steku aukštyn, atskleisdamas arba manipuliuodamas duomenimis. Rezultatas svyruoja nuo nedidelio nutekėjimo iki visiško instrukcijų rodyklės valdymo.
Kur šiuolaikinėse kodų bazėse slepiasi formatavimo eilutės klaidos
Šie pažeidžiamumai būdingi ne tik senesniam C kodui. Jie slypi ir šiuolaikinėse aplinkose:
- Python (ctypes), Rust (FFI) ir Go (cgo) su vietinėmis bibliotekomis sąveikaujantys susiejimai dažnai veikia kaip ploni apvalkalai, perduodantys parametrus tiesiai pažeidžiamoms C funkcijoms.
- Trečiųjų šalių CLI įrankiai ir demonai integruoja senesnį C kodą be pakankamos peržiūros.
- Registravimo aplankai, pvz. debug_log(vartotojo_įvestis) kurios viduje nukreipia į printf stiliaus funkcijas
- Automatiškai sujungti OSS įnašai, kuriuose yra senų šablonų arba minimaliai patvirtinta informacija
Klaida gimtajame C sluoksnyje ten nepasilieka; ji plinta aukštyn. Jei C funkcija, pvz. log_event(char *msg) yra nesaugu, iškviečiama iš Python per ctipaiRūdys per nesaugus išorinis, arba Eiti per cgo atneša pažeidžiamumą į tas aukštesnio lygio aplinkas.
Problema? Šios integracijos yra įprastos, ir „DevSecOps“ dažnai daro prielaidą, kad susiejimai yra saugios abstrakcijos. Jos tokios nėra. Formatavimo eilutės pažeidžiamumas viename steko sluoksnyje gali tyliai išplisti tarp sąsajų, ypač kai vietiniai moduliai yra apvynioti be griežto tipo užtikrinimo ar įvesties valymo. Jei pagrindinė C funkcija yra pažeidžiama, aukštesnio lygio kodas paveldi formatavimo eilutės pažeidžiamumą.
CI/CD Pipelines: Kaip tai praslysta pro jūsų saugumo patikras
modernus pipelineyra sukurti greičiui, tačiau tas greitis sukuria akląsias zonas:
- SAST įrankiai retai aptinka dinaminio formato eilučių naudojimą, nebent tai būtų specialiai sukonfigūruota pažeistiems duomenims sekti
- PR apžvalgininkai daugiausia dėmesio skiria logikai ar stiliui, o ne pagrindiniam C funkcijos elgesiui
- CI sujungia pažeidžiamus paketus, kurie iš pirmo žvilgsnio atrodo nekenksmingi
- Priklausomybių skaitytuvai dažnai ignoruoja natyvų kodą arba nesaugią registravimo logiką
Standard SAST Įrankiai dažnai neaptinka formatavimo eilutės klaidų, nebent būtų įdiegtos pasirinktinės taisyklės, skirtos aptikti ne literalinius formatavimo argumentus. Be šių pritaikytų patikrinimų dinaminės formatavimo eilutės lengvai praslysta nepastebėtos.
Formatavimo eilutei būdingų taisyklių integravimas į CI/CD yra labai svarbu norint anksti nustatyti ir sustabdyti šias klaidas. Tai reiškia:
- Kodo blokavimas, kai nepatikimi įvesties duomenys pasiekia formatavimo funkcijas
- Dinaminių formato eilučių žymėjimas statinės analizės metu
- Šių politikų vykdymas kaip CI sujungimo proceso dalis
Be šito, jūsų pipeline nepastebi pažeidžiamumų klasės, kurios gali sukelti atminties sugadinimą ir RCE dar gerokai prieš kodo pasiekimą gamybinėje versijoje.
Klaidos aptikimas: praktinis aptikimas naudojant GDB ir statinius įrankius
Norėdami rasti ir patvirtinti šias klaidas, naudokite rankinio derinimo ir automatinės statinės analizės derinį.
Rankinė analizė naudojant GDB:
GDB yra ypač naudingas, kai įtariate netinkamą formatavimo eilutės naudojimą, bet reikia patvirtinti, kaip ji veikia vykdymo metu:
- Pertrauka įjungta printf arba susijusios funkcijos norint patikrinti iškvietimų steką ir argumentus.
- Ieškokite anomalijų, netikėtų atminties nuskaitymų, gedimų formatavimo metu ar keistų reikšmių steke.
- Abstraktus įvesties būdas, pavyzdžiui, pakartotinis %x or %s gali padėti nustatyti, kaip giliai formato eilutė pereina steką.
Nuo rankinio iki automatinio:
Kai rankiniu būdu patvirtinsite netinkamo naudojimo modelį, kitas žingsnis – šią įžvalgą paversti automatizuota taisykle. Pavyzdžiui:
- Paskirtis grep 'printf(' šaltinis/) norint rasti neapdorotus formatavimo iškvietimus.
- Derinkite tai su scenarijais, kad pažymėtumėte bet kokį naudojimą printf( kur yra pirmasis argumentas ne pažodinė eilutė.
- Naudokite AST pagrindu veikiančius įrankius formato eilutės reikšmėms sekti, dinamiškai identifikuodami netaisyklingus kelius.
- Dažnus rankinius radinius, pvz., apgaubiančias funkcijas, persiunčiančias nepatikimą įvestį, išverskite į integracijos taisykles, kurios automatiškai blokuoja šiuos atvejus.
CI integravimo patarimas: Konfigūruokite savo pipeline kad sudarymas nepavyktų, jei kuri nors formatavimo funkcija gauna dinaminę įvestį kaip formatavimo eilutę. Šie patikrinimai veikia kaip užkarda, kuri užtikrina tai, ko išmokote iš GDB ir derinimo vykdymo metu.
Kodo grūdinimas: įvesties patvirtinimas ir saugesni šablonai
Formatavimo eilutės pažeidžiamumo prevencija prasideda nuo saugesnių kodavimo įpročių taikymo ir jų laikymosi užtikrinimo dideliu mastu:
- Visada naudokite fiksuoto formato eilutes: printf(„%s“, vartotojo_įvestis);, niekada neperduokite neapdorotos įvesties kaip formato.
- Pirmenybę teikite saugesniems variantams: snprintf, vsnprintf, ir panašios funkcijos padeda valdyti buferio dydžius ir užtikrinti išvesties struktūrą.
- Patvirtinkite visas naudotojo įvestis kurie gali patekti į registravimo ar formatavimo logiką, net ir apvalkalo funkcijose.
Automatinės švelninimo priemonės, kurias turėtumėte įjungti:
- Adresų valiklis (ASan): Realiuoju laiku aptinka atminties pažeidimus, įskaitant buferio perpildymą ir steko pažeidimus, kuriuos dažnai sukelia netinkamai suformuotos formato eilutės.
- UndefinedBehaviorSanitizer (UBSan): Pažymi neapibrėžtą elgesį, pvz., nesutampančių arba trūkstamų argumentų perdavimą formatavimo funkcijoms.
- -D_FORTIFY_SOURCE=2: Prideda supaprastintus libc funkcijų patikrinimus kompiliavimo metu, padedančius aptikti netinkamą formatavimo eilučių naudojimą arba buferio perpildymą su minimaliomis našumo išlaidomis.
Šie įrankiai turėtų būti įjungti tiek kūrimo, tiek CI aplinkoje, kad būtų galima aptikti problemas dar prieš jas išleidžiant. Kartu su statine analize jie sudaro patikimą saugos tinklą, įspėjantį apie netinkamą naudojimą, kuris kitaip galėtų likti nepastebėtas iki vykdymo ar po išnaudojimo.
Patarimas: Įtraukite šias dezinfekavimo priemones į savo pastatą pipeline su įspėjimo apie gedimą politika. Bet kokį formatavimo eilutės pažeidimą traktuokite kaip nepavykusį testą.
Kaip „Xygeni“ sustabdo formatavimo eilutės klaidas prieš joms išsiunčiant
Ksigeni Stiprina CI/CD užtikrinant formato eilutės saugumą naudojant prevenciją realiuoju laiku, o ne tik aptikimą:
- Atpažįsta pavojingus modelius kaip printf(vartotojo_įvestis) prieš kodo pasiekimą gamybinę versiją
- Taikoma statinė užterštumo analizė atsekti nepatikimus įvesties duomenis formatavimo funkcijose, net keliuose sluoksniuose arba apvalkalo iškvietimuose
- Automatiškai blokuoja nesaugius sujungimus „GitHub“, „GitLab“, „Bitbucket“ ir „Jenkins“ platformose
- Pateikia aiškų grįžtamąjį ryšį su skambučių pėdsakais, įvesties kilme ir išankstiniucise. taisomųjų pasiūlymų
Pavyzdys veiksme: ifa kūrėjas commits linija log_debug(vartotojo_įvestis) bei log_debug() viduje apgaubia pažeidžiamą printf„Xygeni“ seka iškvietimo grafiką, atpažįsta dinaminio įvesties kelią ir blokuoja sujungimą. Kūrėjas iš karto mato pranešimą savo sujungimo užklausoje:
⚠️ Aptiktas formatavimo eilutės pažeidžiamumas: vartotojo_įvestis teka į printf() iš šaltinio / logger.c:42. Naudokite fiksuoto formato eilutę ir patikrinkite įvestis.
Šis atsiliepimas pateikiamas tiesiogiai „GitHub“, „GitLab“, „Jenkins“ arba „Bitbucket“ platformose kaip MR/PR proceso dalis. Kūrėjai negali jo nepastebėti ir gauna veiksmingų nurodymų, kaip išspręsti problemą, o ne tik miglotą įspėjimą.
Integracija yra sklandi:
- Politikos taisyklių konfigūravimas pagal saugyklą, šaką arba projektą
- Įjungti blokavimo sąlygas dėl nesaugaus formato naudojimo
- Automatiškai sekti nesaugias įvestis C/C++, Python, Go, Rust ir jų gimtosiose sąsajose
Integruodama saugumą į savo darbo eigą ir teikdama kūrėjams pirmiausia atsiliepimus, „Xygeni“ užtikrina, kad formatavimo eilučių klaidos niekada nepasieks gamybos procesų, sustabdydamos jas tiksliai ten, kur jos atsiranda.
Paskutinis žodis: formatavimo eilutės klaidos nėra mirusios
Nepaisant šiuolaikinių kalbos įrankių, formatavimo eilučių klaidos vis dar pasitaiko. Jos patenka per apvalkalus, trečiųjų šalių paketus ir nepakankamai peržiūrėtus PR. Jų poveikis yra realus: atminties sugadinimas, duomenų nutekėjimas ir galimas RCE.
Patikrinkite savo kodą. Grūdinkite savo CI/CDĮdiekite aptikimo taisykles ir užtikrinkite jų vykdymą. Tai ne tik senas bagažas, tai aktyvi grėsmė, slepianti akis. Naudokite automatinius įrankius, statinę analizę ir vykdymo laiko dezinfekavimo priemones, kad problemos būtų aptiktos anksti. Nemanykite, kad esate saugūs vien todėl, kad kodas kompiliuojasi.
