3 ms·
And still, in 2021, after so many exploits, realizing the futility of trying to fix these bugs and adding their "blast door" process, some Apple dev calls image
by meibo 5y ago
And still, in 2021, after so many exploits, realizing the futility of trying to fix these bugs and adding their "blast door" process, some Apple dev calls image parsing code where it doesn't belong. The people that are supposed to maintain the element of the OS that has been abused most by nation states do not know the internal APIs they are working with, even just to display looping GIFs.
This negligence is killing journalists and activists.
- terhechte 5y agoHow do we know this code was written in 2021? GIF support was added to iMessage (I think) in 2016 or 2016; I couldn't find an exact date.
- meibo 5y agoThat's a fair point, but doesn't change the fact that it remained there after the code review that was surely(?) made after implementing blast door. Especially for image parsing APIs, considering they've always been the brittle part in the iMessage pipeline. Not sure how Apple dev machines look like, but usually I can find stuff like this with a well written grep or a shell script and my API definition, if I'm not sure that I caught everything while refactoring. The codebase might be massive but the team should be sizeable enough to handle it.
- musicale 5y agoIt really does seem like a failure of blast door. Parsing any untrusted data should always be sandboxed.
- baybal2 5y agoThe image library also runs sandboxed, and they found a way to "escape it with ease." Sandboxes don't reduce the need in having programmers with straight hands. They just trade less safe APIs, for ones deemed more so. You will have as much holes in the sandbox, as much APIs you add to it.
- native_samples 5y agoIn this case they obviously didn't realize it needed to be called inside the sandbox. That function name really is amazingly misleading about what it will do. Anyone could have made that mistake.
- deleted 5y ago[deleted]