Unfinished might be a good excuse if it weren't running on Nest devices.

Nest devices don't run untrusted code. If you get code running on a Nest display, please let me know how, because I'd love to hack around on mine.

> Nest devices don't run untrusted code.

Yes they do; they run code written by Google. The only thing worse would be Facebook; the literal NSA are more trustworthy.

>Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.

Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.

You’re kidding right? Did you miss the parts about KASLR being broken and syscalls with TODOs for missing validations? And the CVEs created in relation to these?

I saw one CVE (CVE-2022-0882) for the innocuous kernel log bug. How many CVE's did you see? As for the KASLR, this was a known issue to the Fuchsia devs.

>This is a known-issue. KASLR support on the zircon kernel is just there so that it doesn't bit-rot. We are always picking up a static address instead of a dynamic one.

>Once physboot rollout is complete, that should make it easier to support kaslr.

KASLR is a pretty meh mitigation. But yeah, "todo" around capability checking probably should have been a higher priority fix.

FTA: But to simplify my first security experiment with Fuchsia, I decided to disable SMAP and SMEP in the script starting QEMU and create the fake vtable in my exploit in the userspace

I don’t see them re-enabling it later, so yes, they found security problems, but they didn’t show a complete attack, either.

Also from the start they introduce a bug in the kernel (in the TimerDispatcher implementation), and this is the very bug they focus on and eventually write an exploit for.

They explain why they do so, and the article is extremely valuable as a first step and tutorial to get started in Zircon kernel hacking. They also find some actual issues, including one CVE. But I disagree the article shows how "unsecure Fuchsia is as a result of being unfinished".

Better than being insecure by design, I would think.

Insecure is insecure. Or did you mean unfixably insecure?

Parent means infixably and/or intentionally insecure.

Was that your takeaway from reading it, or something else?

My take away, but the author goes into a bit of detail on this.

"How insecure" a surprising conclusion based on a single exploit.

If you read the article it mentions that ASLR doesn't work, and it's treated as a "known bug".

Kernel ASLR. User-space has ASLR enabled and working, in addition to shadow stacks and a number of other hardening techniques.

The article also references syscalls that are marked with TODOs for validation of those calls.

Do you assume I didn't read the article? Calling it insecure based on this is absurd.

Exactly I also find it slightly silly to immediately declare this 'insecure' in this case here.

If it was directly end-to-end on say a Nest Hub running a release version of Fuchsia then that would be a more convincing here, as that would confirm that it can be deployed and the bug can be exploited in the wild and in production and not on a newly built developer version running in an emulator.

The writeup of finding and exploiting this bug is impressive, but whether if you can use that exploit to directly attack a production version of Fuchsia on a device like the Nest Hub is another thing, which is the same way security researchers do to break live versions of other OSes like macOS, Windows, Android and Linux.

The word you were looking for is _writeup_.

It's weird in my later 20s I started doing this, writing homophones. I at least get my then/their/effect right still.

I think this mostly happens to native English speakers for some unimaginable reason. I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.

I would guess that the difference native/foreign is simply due to the way language is learned: for native speakers, it's first and mostly orally. This doesn't explain a later appearance of mistakes though…

I right a lot less now then I did as a kid, so maybe it’s about just staying sharp

You rays a good point!

I believe “raze” would be the correct pronunciation. ;)

Both are pronounced identically in American English at least.

Huh, the IPA indeed seems to be the same, but I would argue that the “z” in “raze” is distinctly more voiced than the “s” in “rays”.

Ah, this remains me of a classique in this field: https://youtu.be/OonDPGwAyfQ

As a nonnative English speaker (actually mostly reader/writer/listener), I started doing that at some point (many years after English proficiency), to my own dismay.

> I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.

I used to think that, too. But now my fingers just type the words as I hear them spoken in my mind, and that seems to occasionally produce homophones.

Kinda fascinating what this says about our language processing, to be honest!

I was most disconcerted to find myself doing the same thing of late. It is very curious; like my brain internally just couldn't be bothered anymore to expend the energy to delineate their and there until I'm in the process of actually typing. But that means the signalling fires a tad late, so I'm going back and fixing stuff.

I'm not native and I absolutely do this. 500 grams of flower...

Funny, that fragment actually works as written in some contexts. :)

Imagining that looks very nice, TIL prettiness can be quantified/measured by weight :D

Unfinished does not justify unsecure!

You start with something secure and rudimentary and add features over time.

You don't start with something unsecure and then add security to it.