351–360 of 360 posts
This is mind boggling. NSO used a compression format's instructions to create logic gates and then from there "a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations", all within a single pass of decompression. Combine this with a buffer overflow and you've got your sploit.
Earlier quoted context omitted.
They don’t really have to, they can just mine Bitcoin by reversing SHA256 in polynomial time, inspect https messages to banks, or send Bitcoin to themselves by creating an ECDSA signature… or just set up a software as a service and have the biggest business in the world.
n^10 is a polynomial too. The equality of P and NP would not itself mean there are fast solutions.
Earlier quoted context omitted.
I'd assume they're using the Erik Prince/Constellis business model, taking some time off and getting the band back together under a different name to do the same work.
I think when you are providing such a valuable service, there is almost zero chance they just stop.
Reading breakdowns like this gives me imposter syndrome
Thanks god you can remove Messages.app nowadays
How? I just tried, and I could only remove it from the home screen.
Earlier quoted context omitted.
iOS does not allow the modification or generation of new executable code (at least, it will not at this stage of an exploit). So they are likely creating a weird machine to patch various data and then redirecting control flow with the altered state by overwriting a function pointer.
Right, and they get there of a decomp pass on totally untrusted input over the network. This is why it's so crazy that apple has this huge attack surface. My own suggestion. Ascii only messages if contact is not in address book or is a contact you've communicated with in your message history (however long you keep that) up to 1 year. Once you reply these untrusted saudi contacts can send you the gif meme's.
This is mind boggling. NSO used a compression format's instructions to create logic gates and then from there "a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations", all within a single pass of decompression. Combine this with a buffer overflow and you've got your sploit.
That reads like some handwavy explanation of a hack in a movie scene... "Now I just have to embed a 64-bit computer architecture into my compression algorithm and... boom. We're in."
Earlier quoted context omitted.
As much as I'd like to agree with you, the real reason this is happening is because humans wrote the code and humans make mistakes. And even if you rewrite all of the software in Rust, it'll still have exploitable bugs. Does it matter if it's a buffer overflow or a rusty pan, if the end result is someone reading your device's memory?
In a language with proper bounds checking, regardless of which one, the result of this attempt would have been a core dump. Sure there are other ways to then take advantage from killing a critical process, but it would be one attack vector less.
Earlier quoted context omitted.
Note the disclaimer on that page: > This is not an official Google product, it is just code that happens to be owned by Google. Which generally means that the original author worked at Google when they wrote this code & "chose" to let Google own the copyright of this project rather than fill out more paperwork. It doesn't imply the project was funded by Google--just that the author was a Google employee at some point…
That disclaimer appears at the bottom of every project that Google doesn't feel like officially supporting. Even the tcmalloc project has that disclaimer at the bottom and it's used in every single process running in Google datacenters right now. I think you'd be hard pressed to really make the case that WUFFS is not funded by Google.
Based on my understanding from conversations with Google staff, it's a disclaimer that's required if anyone at Google wants to write "personal" code & release it (under an Open Source license) while employed by Google.
(Unless they choose to undertake a much more paperwork-intensive alternate process with different requirements & implications.)
Personal code is different to code developed for reasons that were directed by Google (which they have no problem saying is unsupported, e.g. any version of Android older than 3 minutes or something :D )--which is why this disclaimer can be seen on such odd non-corporate things as retro-computing related projects.
Of course, sometimes such projects do become something Google wants to use (maybe WUFFS falls into this category)--so I expect we'll see more retro computing support on Stadia any day now... :D
TL;DR - the ending of the post is all you need: “JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. Using over 70,000 segment commands defining logical bit operation…
This one will be another talking point right beside the "arbitrary code execution in SNES games via controller inputs" as a rebuke to arguments about even small systems (like an image decompressor) being "made secure". I also keep thinking "The Cylons would totally write an exploit like this."
Reminder that the Cylon attack was an insider job in the rebooted series (from a model Number Six).