Google прадставіў сістэму fuzzing-тэставанні ClusterFuzzLite

Кампанія Google прадставіла праект ClusterFuzzLite, які дазваляе арганізаваць fuzzing-тэставанне кода для ранняга выяўлення патэнцыйных уразлівасцяў на этапе працы сістэм бесперапыннай інтэграцыі. У наш час ClusterFuzz можа выкарыстоўвацца для аўтаматызацыі fuzzing-тэставанні pull-запытаў у GitHub Actions, у Google Cloud Build і ў Prow, але ў далейшым чакаецца з'яўленне падтрымкі і іншых CI-сістэм. Праект грунтуецца на платформе ClusterFuzz, створанай для каардынацыі працы кластараў fuzzing-тэставанні, і распаўсюджваюцца пад ліцэнзіяй Apache 2.0.

Адзначаецца, што пасля ўкаранення ў 2016 годзе кампаніяй Google сэрвісу OSS-Fuzz у праграму бесперапыннага fuzzing-тэставанні было прынята больш за 500 важных адкрытых праектаў. На аснове праведзеных праверак было ліквідавана больш за 6500 пацверджаных уразлівасцяў і выпраўлена больш за 21 тысячу памылак. ClusterFuzzLite працягвае развіццё механізмаў fuzzing-тэставанні магчымасцю больш ранняга выяўлення праблем на стадыі рэцэнзавання прапанаваных змен. ClusterFuzzLite ужо ўкаранёны ў працэсы рэцэнзавання змен у праектах systemd і curl, і дазволіў выяўляць памылкі, прапушчаныя статычнымі аналізатарамі і linter-амі, якія ўжываліся на пачатковым этапе праверкі новага кода.

ClusterFuzzLite падтрымлівае праверку праектаў на мовах C, C++, Java (і іншых моў на базе JVM), Go, Python, Rust і Swift. Fuzzing-тэставанне праводзіцца з выкарыстаннем рухавічка LibFuzzer. Для выяўлення памылак працы з памяццю і анамалій таксама могуць выклікацца прылады AddressSanitizer, MemorySanitizer і UBSan (UndefinedBehaviorSanitizer).

Асноўныя магчымасці ClusterFuzzLite: хуткая праверка прапанаваных змен для знаходжання памылак на этапе да прыняцця кода; загрузка справаздач аб умовах узнікнення крахаў; магчымасць пераходу да больш пашыранага fuzzing-тэставання для выяўлення глыбейшых памылак, не якія ўсплылі пасля праверкі змены кода; генерацыя coverage-справаздач для адзнакі ахопу кода пры тэставанні; модульная архітэктура, якая дазваляе выбіраць неабходную функцыянальнасць.

Нагадаем, што пры fuzzing-тэставанні ажыццяўляецца генерацыя струменя разнастайных выпадковых камбінацый уваходных дадзеных, набліжаных да рэальных дадзеных (напрыклад, html-старонкі з выпадковымі параметрамі тэгаў, архівы ці малюнкі з анамальнымі загалоўкамі і да т.п.), і фіксацыя магчымых збояў падчас іх апрацоўкі. Калі нейкая паслядоўнасць прыводзіць да краху ці не адпавядае чаканай рэакцыі, то такія паводзіны з высокай верагоднасцю сведчаць пра памылку ці ўразлівасці.

Крыніца: opennet.ru

Дадаць каментар