[clug] ASD/ Five Eyes report on "Memory Safe" languages

jm jeffm at ghostgun.com
Thu Dec 7 22:26:31 UTC 2023


It will likely go the way of the US DoD mandatory adoption of Ada in the 
80s if they try to enforce an "all software shall be written in one of 
these languages" approach. For starters, there are legacy systems and 
products which have to be used but were coded in other languages. If 
such an approach was to be taken it might be better to only apply it to 
Internet and systems handling "untrusted" data. This would mean high 
risk entry points are covered including desktops, but backend systems, 
which would be were most heavily entrenched legacy stuff runs would be 
unaffected.

I don't know how such as stance would affect network equipment though. 
You're not going to be able to get those vendors to change no matter who 
you are. There's simply too much high performance code and ASICs.

Jeff.

On 8/12/2023 08:48, steve jenkin via linux wrote:
> This is not going to stop C and other off-list tools being used in FOSS projects,
> but might prompt efforts to address Known Problems like buffer over-runs and stack smashing.
>
> You’ll note that All Your Favourite Multinationals get a Guernsey,
> but half the languages on the list are FOSS.
>
> A significant accomplishment IMHO.
>
> At what point do you think the Fed Govt is going to mandate “memory safe” for new internal projects, then all software?
>
> And when will that be extended, if ever, to systems & software purchased by FedGov?
> I don’t know. [ When Microsoft announces they’re converting to ‘C#’? ]
>
> I tried to look up the number of exploits in Winders vs The Rest and struck out. [ links below. Debian is #1 in their CVE catalog ]
>
> This in the light of Britain declaring Russian interference in their 2019 General Election with two Russians being charged.
> While ’spearphising’ is a social exploit, it can only install code that stays hidden if the platform has significant vulnerabilities.
>
> 	<https://abcnews.go.com/Technology/wireStory/uk-russias-intelligence-service-sustained-attempts-meddle-british-105451402>
> 	<https://www.bbc.com/news/uk-politics-67647548>
>
> [ I loved the irony of the website using PHP, notorious for being exploited, but these guys will, hopefully, be diligent protecting against exploits ]
>
> 	Security Vulnerabilities in CISA KEV Catalog, sorted by EPSS (Exploit Probability Score)
> 		<https://www.cvedetails.com/cisa-known-exploited-vulnerabilities/kev-1.html>
>
> 	Top 50 Products By Total Number Of "Distinct" Vulnerabilities
> 		<https://www.cvedetails.com/top-50-products.php?year=0>
>
> ============
>
> The Case for Memory Safe Roadmaps
> 	<https://www.cyber.gov.au/about-us/view-all-content/publications/case-memory-safe-roadmaps>
>
> 	Memory safety vulnerabilities are the most prevalent type of disclosed software vulnerability
>
> 	Modern industry reporting indicates defects first identified over 25 years ago
> 	remain common vulnerabilities exploited by malicious actors today to routinely compromise applications and systems.[7]
> 	Yet, according to modern industry reporting, these vulnerabilities remain common,
> 	and malicious actors routinely exploit them to compromise applications and systems:
>
> 	    • About 70 percent of Microsoft common vulnerabilities and exposures (CVEs) are memory safety vulnerabilities (based on 2006-2018 CVEs).[8]
> 	    • About 70 percent of vulnerabilities identified in Google’s Chromium project are memory safety vulnerabilities.[9]
> 	    • In an analysis of Mozilla vulnerabilities, 32 of 34 critical/high bugs were memory safety vulnerabilities.[10]
> 	    • Based on analysis by Google’s Project Zero team, 67 percent of zero-day vulnerabilities in 2021 were memory safety vulnerabilities.[11]
>
> Appendix: Memory Safe Languages
>
> 	C#
> 	Go
> 	Java
> 	Python
> 	Rust
> 	Swift
>
> Purpose
> 	This guidance was developed by U.S., Australian, Canadian, UK, and New Zealand
> 	 cybersecurity authorities to further their respective cybersecurity missions,
> 	including their responsibilities to develop and issue cybersecurity specifications and mitigations.
>
> ============
> --
> Steve Jenkin, IT Systems and Design
> 0412 786 915 (+61 412 786 915)
> PO Box 38, Kippax ACT 2615, AUSTRALIA
>
> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
>
>




More information about the linux mailing list