231–240 of 296 posts
Earlier quoted context omitted.
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.
Yes they do; they run code written by Google. The only thing worse would be Facebook; the literal NSA are more trustworthy.
Earlier quoted context omitted.
Sure - look i'm not gonna argue about C++ memory safety - i've funded and spent time trying to ensure we are funding figuring out how to get off of C++. I just assume C++ code is unsafe, because it's really really hard to make it safe. However, at the same time, the privilege escalation issues would have happened in any language - if you don't implement the check, you don't implement the check. (and you could make it…
What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel ins…
Yes, this particular one enabled a defeat of ASLR, but so what? Missing access checks enable privilege escalation no matter what the language.
Your claim that "has well-definable consequences" is equally true in C++ as anywhere else. Whether you miss your access check in rust, or C++, or python, or whatever, the definable consequences are "privilege escalation".
Let's not pretend memory safe languages solve logic problems. They help with memory safety - that's awesome but not a complete solution.
If we want better verification of access contracts, we'd need a language with contracts or some other verifiable mechanism.
Those exist, and i'd support their use in this sort of case.
Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it…
Wouldn't the easier path have been just for Google to contribute (or fork) Free/Open/NetBSD?
Earlier quoted context omitted.
Phones and tablets are just locked down computers, not appliances. Do you want your laptop to be like that? Why not? Why is that any different than your tablet? Spoiler: It's not. Some people only have access to tablets and phones. Let them have the freedom we had to create something. With that freedom, maybe one of them grows up and creates the next Apple, only without the cruelty and greed. On top of that, it would…
Again: it is cheaper and easier than ever to get a "real" computer. They're at thrift stores for like $50-100, with peripherals. Raspberry Pi alone has sold over thirty million units. If a bright kid with a good idea asked for one on HN I bet a dozen people would ship their extras to them for free . Computers are given away for free pretty regularly on Craigslist and Facebook and such. Old but functional laptops can…
And cheers bud, see yah round.
Earlier quoted context omitted.
Hi there, I work on Fuchsia, specifically on our Software Delivery system [1]. You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products. The ability to run code o…
I also work on Fuchsia’s Software delivery team. For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from: * a hardware key (on hardware that supports it), which checks the signature of * the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then co…
How do you insure that the end user is able to replace the hardware key and bootloader with one of their own devising (and generally to tamper with arbitrary parts of system) without a remote vendor/employer/DRM firm being able to prevent or detect it?
Earlier quoted context omitted.
Yes - you can't run untrusted native code in the first place outside of the emulator ;) That's why the bug says: "The overall impact of this bug is pretty minimal in our current set of supported products, since none support running untrusted native code, and if you can run your own code on the system, then (at present) you can also use other existing supported workflows to obtain kernel logs, but it does seem to be a…
Don't forget that the use-after-free used was also artificial - ie. OP didn't discover one, he added a UAF bug to go exploit. The fact he got KASAN working and talks about fuzzing suggests he looked for one, but couldn't find one, which is a good sign.
Earlier quoted context omitted.
To me it comes off as inclusive of Americans while excluding the rest of the world. As a European I do not feel welcome, and I imagine people further from US culture feel even less welcome.
Would you mind going into why these banners make you feel unwelcome? Do you feel similarly about using the US Google homepage?
It feels irrelevant to the purpose of the page, and makes it feel like the page is targeted to people who have a specific viewpoint on a specific political issue (usually an issue that non-Americans have little context for).
Earlier quoted context omitted.
I think the short version is that you're just not talking about capabilities.
How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?
If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability.
Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, but you can "guess" a uuid in the same way that you can "break AES" with a bruteforce, which is to say, you can't.
Something that I haven't seen brought up yet is the "weird C++ vtable layout." This is actually the "relative vtable layout" that's first described here: https://bugs.llvm.org/show_bug.cgi?id=26723 , and is usable in clang via the -fexperimental-relative-c++-abi-vtables option. The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the…
Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway. Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of…
From the link: "I can report that a prototype of this was able to shrink Chromium's code size by 9%."
Earlier quoted context omitted.
How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?
So to recap, a capability is a value that represents authorization. The value must not be forgeable, the value must be communicable. If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability. Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, b…
The attack surface of "bit pattern" capabilities is much larger than that of "trusted state" capabilities- even if you can't practically guess one, all you need to break it is to discover its bit pattern somehow. Trick someone into printing it out, read it out of their memory space, leak it via a side channel, attack their UUID generator, etc. For this kind of capability, sure- periodic revocation might be a worthwhile mitigation technique.
But for "trusted state" capabilities, which is where this thread started, and what file descriptors exemplify, this all goes away. The attack surface is reduced to the kernel and the component's own API (nothing new here) and its use of a finite set of capability delegation APIs. Leaking an fd number does not leak the corresponding capability the way leaking a Dropbox URL does, so there is relatively little purpose in rotating those out.