A Saudi woman's iPhone revealed hacking around the world

I wouldnt consider Rice's theorem to be relevant for what I was thinking. Sure all programs have common repeatable elements, like open a file, read/write, close file, so you wouldnt have an instruction or few out of the blue suddenly being run, in effect out of context, but thats whats happening here, the normal instructions that would be required to do a task, suddenly start using instructions that are not required in most cases before resorting back to the rest of the instructions for the original task.

Its abit like saying, would you expect some instructions for virtualisation to run if you load a jpg to display on screen? I wouldnt expect instructions for virtualisation functionality to be running in this example.

Or would I expect some instructions for encryption to run if I were to load a sound file to play over speakers? No I wouldnt expect that to happen, but thats the sort of thing thats happening here, some instructions not normally associated with a task are occurring, so how do you detect and alert and maybe halt those instructions?

There isnt anything in the CPU AFAIK that would pick this up, it would need the OS to act as a co-party to perhaps halt this, and I dont know if the OS or even AV software goes to this extent? At best, you'd have something like a dmesg feed or the Intel Processor Trace (https://news.ycombinator.com/item?id=30110088) to get the output of instructions being called (possibly independent of the OS), but like I say I dont know of any OS or AV product that goes to this level of monitoring.

Thats where I am coming from.

Thanks for the non sequitur.

I think the most critical part in the flow is the integer overflow bug, and it is totally avoidable. I am a software engine at Microsoft. Half of my time was spent on security and compliance. We have the right tool, right policy to avoid such things happen. However, I'm not saying Microsoft software is free of integer overflow bugs. I don't intend to advertise Microsoft C/C++ development tools here, but they are the ones I know most.

Let's go to the technical part: If you are asked to implement the binary algorithm with your favorite programming language, how do you verify your code? Unit-tests. How many test cases you will need? More than 10. Binary search implementations are easy to suffer integer overflow bugs(remember the one in JDK?), as long as you have enough tests, your don't need to worry too much. But how much is enough? People can't implement binary search correctly in decades is not because we don't know the algorithm enough or we don't have excellent software engineers, it is because w don't know how to test our code thoroughly. Any non-trivial C/C++ function may need tens of thousands test cases. Simply you can't write them by hand.

You need the right tools: fuzzing and static analysis.

At Microsoft, every file parser should go through fuzzing, which basically is you generate some random input, then you run your tests with the random inputs. Not very fantastic. But there is another kind of fuzzing: symbolic execution, which tries to find all the possible execution paths of your code. If you run symbolic execution with your binary search code, you can get 100% test coverage. And it is guaranteed bug-free. It is like a math proof. Please note the advantage is based on human just had surprising great advancement on SAT solvers in the last 20 years. And often you need to make some compromises between your business goal and security. Most functions can't reach 100% test coverage. You need to simplify them. See https://github.com/klee/klee to get a quickstart. Though C/C++ is often considered unsafe, they have the best fuzzer.

Then it is about SAL annotation and static analyzer. In C, whenever you pass a pointer of an array to another function, you should also pass its length with it. And in the callee function you should check the length. If you forgot it, your static code analyzer will give you a warning. In such a sense, if you didn't allocate enough memory, it will only result an error code being returned instead of undefined behavior.

The last thing: Use safeint wrapping your malloc function. https://docs.microsoft.com/en-us/cpp/safeint/safeint-library...

When we move off the binary search toy example to a real code base, clearly you can see how much extra effort is needed to make the code safe. Please pardon me, most OSS libraries don't have the resource. Many famous OSS projects are "Mom-and-pop" shops. They don't have any compliance rule. They invest very little on fuzzing. So the big companies really should help them. Now you see an integer overflow bug was found in Apple's image render, but was the code written by Apple? Not necessarily. Now we all see the importance of the Open Source movement. It's time to think how to harden their security. For example, even I want to spend my free time on adding SAL annotations to an OSS project I love, would the maintainers accept it?

It prevents third-parties from introducing these kind of vulnerabilities, but it doesn't prevent Apple from introducing them. It just makes it really hard to find (and fix) them.

From the original article [0], last line: "In a future post (currently being finished), we'll take a look at exactly how they escape the IMTranscoderAgent sandbox."

[0]: https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...