Brief items

Memory Safe Languages in Android 13 (Google security blog)

Over on the Google security blog, Jeffrey Vander Stoep writes about the impact of focusing on using memory-safe languages for new code in Android.

As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.

While correlation doesn’t necessarily mean causation, it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code. This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. Of course there may be other contributing factors or alternative explanations. However, the shift is a major departure from industry-wide trends that have persisted for more than a decade (and likely longer) despite substantial investments in improvements to memory unsafe languages.

(Thanks to Rahul Sundaram.)

Comments (45 posted)

Samsung, LG, Mediatek certificates compromised to sign Android malware (Bleeping Computer)

Bleeping Computer reports that the Android platform signing certificates for several manufacturers have leaked and been used to sign malware.

However, based on the results, even though Google said that "all affected parties were informed of the findings and have taken remediation measures to minimize the user impact," it looks like not all the vendors have followed Google's recommendations since, at least in Samsung's case, the leaked platform certificates are still being used to digitally sign apps.

Comments (26 posted)

Security quotes of the week

As an actual human and not a bot, I had no idea how to answer. Is this a joke? (Seems not.) Is it a Magritte-like existential question? (It's not a bicycle. It's a drawing of a bicycle. Actually, it's a photograph of a drawing of a bicycle. No, it's really a computer image of a photograph of a drawing of a bicycle.) Am I overthinking this? (Definitely.) I stared at the screen, paralyzed, for way too long.

— Bruce Schneier encounters a strange CAPTCHA

It's pretty much an unwritten law of computer security that any time you see or hear "we take security seriously" it's from someone who's just been breached after not taking security very seriously.

— Peter Gutmann

Comments (3 posted)

Kernel release status

The current development kernel is 6.1-rc8, released on December 4. Linus said: "So everything looks good, and while the calming down may have happened later than I wished for, it did happen. Let's hope this upcoming week is as quiet (or quieter)."

Stable updates: 6.0.11, 5.15.81, and 5.10.157 were released on December 2.

Comments (none posted)

A 10-minute guide to the Linux ABI (opensource.com)

Alison Chaiken provides an overview of Linux ABI concerns on opensource.com.

Understanding the stable ABI is a bit subtle. Consider that, while most of sysfs is stable ABI, the debug interfaces are guaranteed to be unstable since they expose kernel internals to userspace. In general, Linus Torvalds has pronounced that by "don't break userspace," he means to protect ordinary users who "just want it to work" rather than system programmers and kernel engineers, who should be able to read the kernel documentation and source code to figure out what has changed between releases.

Comments (2 posted)

KernelCI now testing Linux Rust code (Collabora blog)

Over on the Collabora blog, Adrian Ratiu writes about the addition of the kernel's Rust code to the KernelCI automated kernel testing project. The blog post looks at what it took to add the support and on some plans for future additions, as well.

An interesting challenge for the rustc docker builds was the fact that the standard Rust method of installing toolchains is via curl https://sh.rustup.rs | sh which might be ok-ish for individual local development, but is a particularly bad idea in an automated CI system. Rustup itself does not (yet) do any signature verifications for its downloads.

Distros like Debian do not ship the version required by the kernel (v1.62), nor even rustup in some cases, and it's unlikely the distro maintainers will keep the versions in sync with the mainline kernel which likely will become a moving target. Thankfully the Rust project provides standalone installers together with GPG signatures which are very useful for CI.

Comments (29 posted)

Quote of the week

The web's a tangled web of networks unseen,
A complex system that can be quite mean.
It's hard to predict when usage will peak,
So congestion can quickly become a leak.

When data is lost, it's time to intervene,
To keep the networks up and running clean.
Congestion control is the name of the game,
To keep the information flowing the same.

— ChatGPT (via Dave Taht)

Comments (none posted)

Rust support coming to GCC

Gccrs — the Rust front-end for GCC — has been approved for merging into the GCC trunk. That means that the next GCC release will be able to compile Rust, sort of; as gccrs developer Arthur Cohen warns: "This is very much an extremely experimental compiler and will still get a lot of changes in the coming weeks and months up until the release". See this article and this one for more details on the current status of gccrs.

Comments (69 posted)

Tor Browser 12.0 released

Version 12.0 of the Tor browser has been released. Changes include multi-locale support, Apple silicon support, HTTPS-only behavior by default on Android and more.

Comments (none posted)