White House's Software Engineering Advice + Child Safety and Encryption Bans

Editor’s Note: This newsletter is part of a collaboration between Lawfare and Risky Business. You can find the full version of the Seriously Risky Business newsletter and previous editions on news.risky.biz.

The White House's Oddly Specific, and Really Quite Good, Software Engineering Advice

This week the U.S. Office of the National Cyber Director (ONCD) published a report calling for the adoption of memory safe programming languages.

It's remarkable such a technical document has been published by the White House.

The report has the overarching goal of addressing what the ONCD calls in its fact sheet the "urgent need to address undiscovered vulnerabilities." It notes that if every single known vulnerability were fixed, undiscovered vulnerabilities would still present additional risk.

To that end, the report lays out two complementary approaches.

One approach calls for better measures of "cyber security quality." The thinking here is that if people could tell what was actually secure, there would likely be market incentives to create more secure products.

The report notes that "software measurability is one of the hardest open research problems to address." So this feels like a long-term effort with no immediate payoff. Public vulnerability data via CVE and CVSS tracking doesn't seem to have moved the needle much over the past decade or two, so we're not sure some new type of metric will really improve the situation here.

The other approach the report outlines is to "reduce the attack surface in cyberspace." Here the report is far more concrete and calls for software developers and vendors to use “memory safe” programming languages. It's oddly specific engineering advice to come out of the White House, but it's also very good advice.

Memory safety vulnerabilities are a class of vulnerabilities arising from how computers read, store, and write memory. In some older languages, such as C or C++, programmers are responsible for writing code that manages memory. This means that programmers often inadvertently introduce vulnerabilities that provide opportunities for malicious actors to take control of the system running that software.

Memory safety bugs have a very long history. The first documented reference to a memory safety vulnerability is in a 1972 U.S. Air Force study. One was later used by the Morris worm in 1988. The 1996 paper "Smashing the Stack for Fun and Profit" described how to take advantage of one type of memory safety vulnerability, a buffer overflow, to compromise computers. 

Since then, there have been many, many different mitigations that have made exploitation of these bugs harder, including OS and hardware features such as Address Space Layout Randomization and pointer authentication.

Despite these mitigation efforts, memory safety bugs are still common. In 2019 Microsoft said that 70 percent of the vulnerabilities to which it assigns a CVE were memory safety issues, in 2020 Google said that 70 percent of its severe Chromium browser project bugs were related to memory safety, and 75 percent of the zero day vulnerabilities Google found in the wild in 2023 took advantage of memory corruption issues.

There's some sampling bias here for sure, as a Seriously Risky Business assessment of the Cybersecurity and Infrastructure Security Agency's (CISA's) Known Exploited Vulnerabilities (KEV) catalog found about 25 percent of vulnerabilities were related to memory safety. (This is a conservative count, as many vulnerabilities were not specified in any detail.)

So, despite nearly 50 years of history and extensive work on mitigations, memory safety bugs are common in data sets that indicate they are having real-world impact.

Hence the push for “memory safe” languages. These languages such as Go, Python, Java, Swift and Rust, to name but a few, reduce, but don't entirely eliminate, the possibility of memory safety bugs.

A lot of programming tasks have migrated to memory safe languages, but C and C++ are still commonly used in development that requires high performance such as operating systems, browsers, and engineering and scientific applications. The memory safety bugs that appear in Google's zero day data set and in CISA's KEV list predominantly occur in operating systems and browsers.

In prior years, there weren't really high-performance memory safe alternatives for C and C++. However, Go (created in 2009), Swift (2014), and Rust (2015) are now fast enough and mature enough that they can be used for operating system and browser development.

There is evidence that using memory safe languages actually does reduce bugs, too.

Google, for example, has found that the number of memory safety bugs in Android has decreased as it has increased its use of Rust and other memory safe languages in Android. Similarly, Mozilla analyzed the bugs in a Firefox component and found that 74 percent of them would not have been possible if that component had been written in Rust. 

The time is right because the memory safe alternatives are now good enough to be viable alternatives. And at the bigger vendors, such as Google and Microsoft, the ONCD is pushing on an open door. The companies are exploring or have advocated for ways to use memory safe languages.

But the software that is causing havoc these days isn't all made by Google or Microsoft. Enterprise software, in particular, is riddled with memory safety flaws. It might be odd that the White House is issuing very specific software engineering advice, but it sends a clear message to vendors: The U.S. government considers the use of memory safe languages to be best practice.

Today's "best practice" has a habit of becoming tomorrow's table stakes, so we think the White House has done a Good Thing here.

There's More to Child Safety Than Encryption Bans

Nevada's attorney general has filed a motion to stop Meta from providing end-to-end encryption on its Messenger app to users under age 18 living in the state.

The state's motion cites its "strong interest in immediately protecting Nevada children" and says "encryption on Messenger enables predators to stalk young users with impunity."

From a law enforcement perspective, removing end-to-end encryption on Messenger could make it easier to gather evidence of crimes. They would be able to obtain unencrypted content by issuing Meta with a court order, rather than needing to get it by forensically examining victim or perpetrator devices.

But it's hard to see how this motion would, on its own, prevent any crime.

We are open to the idea that messaging and social media platforms should treat messages from adults to children differently from messages between adults. Maybe messages to children from adults they don't know or aren't related to, for example, should be delivered alongside in-app prompts that encourage reporting of suspect messages. Perhaps they should be unencrypted to facilitate some sort of scanning or vetting. 

But these are safety-by-design questions that require the system as a whole to make sensible trade-offs between privacy, safety, and children's autonomy.

In this context, tackling encryption in isolation doesn't seem to make a lot of sense. 

Three Reasons to Be Cheerful This Week:

1. Medibank hacker arrested in Russia: Russian authorities have arrested members of the SugarLocker ransomware group. The nickname of the gang's leader, GustavDore, is one of the pseudonyms of Aleksandr Ermakov, the individual sanctioned by Australia for the Medibank hack.
2. A more secure Chrome browser: This week's version of the Chrome browser has a new security feature that (optionally) disables some of the V8 JavaScript engine's speed optimization features. This performance feature, just-in-time compilation, has been responsible for a slew of vulnerabilities affecting Chrome. Risky Business News has extensive coverage, including how to enable the feature.
3. $45 million for energy cybersecurity projects: The Department of Energy has announced the money will go to 16 projects aimed at better protecting the U.S. energy sector. CyberScoop has additional coverage.

Shorts

In Post-Soviet Russia, Apps Navigate You!

Wired has published an excerpt from a new book out just this week that steps through various government projects to use advertising data to track individuals.

The excerpt provides examples of how advertising data can be used to track individuals including Vladimir Putin (because, while he doesn’t have a personal phone, his entourage carries them). 

Another example in the excerpt claims a company was able to track phones in transit from special forces bases in the United States to Syria, where they clustered in the Lafarge cement factory outside Kobane. This location was subsequently confirmed to be a forward operating base for a U.S. anti-ISIS campaign.

The examples cited are generally plausible, although we do wonder whether special forces types really take phones from U.S. military facilities to undeclared overseas bases.

SVR Is Taking to the Clouds

This week the U.K.'s National Cyber Security Centre and partner Five Eyes agencies published an advisory detailing how the Russian SVR (its foreign intelligence service) is modifying its tactics as targets move to cloud infrastructure. The SVR's cyber groups are also known as APT29 or Cozy Bear.

The advisory describes tactics such as cloud access via service and dormant accounts, the use of cloud-based tokens to access accounts, enrolling new devices, and the use of residential proxies.

CrowdStrike also noted a significant increase in cloud intrusions over the past year in its Global Threat Report that was released last week.

A £350,000 Fine for the U.K. Ministry of Defense

The U.K.'s Information Commissioner's Office (ICO) has fined the Ministry of Defense £350,000 for putting 245 Afghans who helped the British military at risk by revealing their contact details in bulk email information leaks.

The emails in question related to the potential removal of individuals from Afghanistan as the Taliban was poised to regain control of the country in 2021. Instead of “BCC”ing the recipients, the ministry included the Afghans' email addresses in the “TO” field. The ICO thought the appropriate penalty was £1 million but cut the ministry some slack because it was a public-sector organization and because of the chaotic circumstances of the evacuation from Afghanistan.

Experts Weigh in on I-Soon Data Leak

The Chinese cyber contractor data leak that we covered last week has been taken down, although the version containing a machine-translated English version was still available at time of writing.  

The Associated Press confirmed the leak originated from I-Soon and also reported that Chinese authorities are investigating it. Security researcher Will Thomas has dived into the technical content of the leak, Natto Thoughts examines the business aspects, and Krebs on Security and SentinelOne have both written their takes.

The loose consensus so far is that the leak was from a disgruntled employee.

Risky Biz Talks

In the latest "Between Two Nerds" discussion, Tom Uren and The Grugq apologize for repeating a quote that is purported to be Russian cyber doctrine but is not. They also wonder why this phenomena has happened before with the so-called Gerasimov doctrine.

From Risky Biz News:

Backdoor code found in Tornado Cash: A malicious backdoor has been found inside the user interface component of the Tornado Cash cryptocurrency mixing project.

The code has been exploited in the wild to hijack assets deposited in Tornado Cash installations.

The malicious code was added to the project by one of its developers. This code was discovered by a security researcher known as Gas404 and confirmed by Yu Xian (Mr. Cos), the founder of the SlowMist blockchain security company.

It works by sending copies of deposit notes to a third-party server.

The deposit notes, also called deposit certificates, work as private keys for funds placed inside a mixer and can be used to reaccess assets once they've been mixed.

[more on Risky Business News, including its previous use for money laundering by both criminals and state-backed groups. This newsletter looked at Tornado Cash when the U.S. government sanctioned it in August 2022.]

U.S. sanctions Sandvine over Egypt sales: The U.S. Commerce Department has sanctioned Canadian company Sandvine for providing internet mass surveillance technology to the Egyptian government.

In a press release, U.S. government officials said Sandvine's networking equipment was used to monitor and censor internet traffic in Egypt and target local political figures and human rights activists.

Sandvine becomes the fifth surveillance and spyware vendor to be added to the agency's Entity List. The Bureau of Industry and Security previously sanctioned Candiru, NSO Group, Intellexa, and Cytrox in 2021 and 2023.

[more on Risky Business News]

FTC fines Avast: The U.S. Federal Trade Commission (FTC) has fined cybersecurity firm Avast $16.5 million for selling its users' browsing data. The FTC accused the security firm of using bait-and-switch tactics by offering browser extensions that blocked internet tracking but then selling browsing data behind its users' backs. Between 2014 and 2020, Avast allegedly sold browsing data to more than 100 third parties through its Jumpshot subsidiary. The FTC has banned Avast from engaging in similar practices and has ordered the company to notify all users whose data was sold.