《zds-2023-06-27-security.pdf》由会员分享,可在线阅读,更多相关《zds-2023-06-27-security.pdf(23页珍藏版)》请在三个皮匠报告上搜索。
1、The Zephyr Project Security Overview,Progress and StatusThe Zephyr Project Security Overview,Progress,and StatusDavid Brown,LinaroFlavio Ceolin,IntelZephyr Security Overview Introduction Lifecycle of a Vulnerability Current Status DiscussionIntroduction Zephyr Importance of security Security Committ
2、ee Security Working GroupWhat is Zephyr Open Source Lots of supported architectures and boards Lots of supported features Lots of code Zephyr:1.3 million lines of C Modules:20 million lines of CSecurity Standards ETSI EN 303-645 Cybersecurity Standard for Consumer IoT Devices FIPS 140-3 Security Req
3、uirements for Cryptographic Modules SP 800-128 Secure Software Development Framework Annex K(C11 standard)Security Committee Defined by project charter Has one rep from platinum members,an architect and a chair Architect:Flavio Ceolin,Chair:David Brown Meeting every two weeks Topics that are not pub
4、licSecurity Working Group Open to any participants First met regularly,with committee meeting on demand Now regular and interleaved with committee Many useful discussion have resulted Security Standards Security Processes Code analysis tools Committee mostly dealing with vulnerabilities and sensitiv
5、e informationLifecycle of a vulnerability What is a vulnerability,in our context Why treated differently The processVulnerability“A software vulnerability is a flaw or weakness in a software system that could be exploited to compromise the systems security or functionality.It could be a bug,design f
6、law,or configuration oversight in the softwares code,design,architecture,or user interface.If a vulnerability is exploited,it could potentially lead to unauthorized access,data loss,or data theft.It could allow an attacker to install malicious software,gain access to sensitive data,or gain control o
7、ver the system and its resources.”-ChatGPT(yes,I did it)Vulnerability for us Bugs in the code,flaws in the design,configuration issues,even problems with an implemented standard Difference from“normal”bugs:it can be exploited This allows an attacker to do something else To understand,we need a threa
8、t model Threat models are hard in Zephyr,we are a general system,and there are lots of uses The threats and use also change over timeTreating different than bugs Bugs are reported publicly,fixes reviewed and merged,all publicly Vulnerabilities are reported and kept private for an“embargo period”Fixe
9、s still happen publicly,including review,but relation to vulnerability is not overtly stated during embargo Theory is to allow certain parties time to mitigate and deal with fix before exploit is known Reality hasnt really worked as wellThe Process:Incoming Reports to zephyr-psirt mailing list or di
10、rectly on github Issue is entered in as a draft security advisory into github Attempt to triage:severity,and what code and maintainers are affected Start notification process,maintainers need to know to get a fix startedProcess:Fixing Maintainers gain visibility along with potentially additional dev
11、elopers to work on fix Eventually one or more PRs are created,reviewed and merged All of this needs to be tracked in github,currently text in the security advisory,but moving to a project-based tracking system Once merged,it will get into a releaseProcess:Embargo Release Time based,90-days Embargo c
12、an end,whatever state fixing the issue is in We report state of fix,point to patches,describe merged changes,or a release A CVE is published with MITRE to disclose vulnerability Release notes are updated to give information more than just the existence of the vulnerabilityProcess:Backports Zephyr ha
13、s a good process for backports,often can happen with a few clicks If backport conflicts,security person may see if easy to resolve,otherwise give to maintainer Backports need to update release notes,CVE and possibly notificationProcess:So How Is It Going?Largely manual Tried automating,web-scraping
14、not reliable There are two types of tasks here:Security“expert”type:analysis,triage,finding maintainers,looking at code Process:notification,updating status based on merges,etc We kind of would like a“rotation”with rest of security committee,process things easier for someone to pick up,“expert”e.g.t
15、he process tasks are fungible.Status:Committee Originally,just committee,met every two weeks Limited audience,started to realize lots of other people would be interested in most topics Created working group(March,2022),changed meeting to this.Committee was to be on demand Committee didnt really happ
16、en,so now interleaveWorking Group General security discussions,open to anyone Covered many topics:Security standards Coding guidelines Analysis tools Security labeled issues on github Has worked reasonably wellCommittee Focuses on vulnerabilities,and things involving budget Trying to improve the vul
17、nerability process Budget things:e.g.third party analysis,sponsoring security conferences,attendanceCryptography Libraries Zephyr uses multiple crypto libraries,can we unify?Some subsystems currently use a specific library One library,in particular,has no upstream maintainer Decided on PSA API Actua
18、lly implementing hasnt happened,thoughConcerns:How do we handle vulnerabilities on modules?3rd party code we have fork in our repo where do fixes go,do reports come from zephyr or forward Can we automate it?(google/osv-scanner,intel/cve-bin-tool,.)Do we need more SBOM information?module interdependencies Shows up with TF-M and Mbed TLS If someone needs TF-M,it demands a specific version of Mbed TLS If not,Mbed TLS version can be flexible Our last LTS update disabled tf-m due to this,fixes were needed in Mbed TLS West doesnt really handle this What can we do better?Questions/discussion