Siguza writes technical analyses of Apple platform security, including iOS kernel mitigations, sandbox escapes and arm64 hardware features.
HN commenters cite it for explanations of KTRR and Psychic Paper, and to back up points about Apple hardware mitigations and Arm speculation bugs.
1) You wrote a general CSV input parser, but what about someone writing CSV output? The obvious way (write a ',' between each cell and a '\n' between each row) works most of the time, but it doesn't always work. The output needs to be escaped correctly, and data escaping should be well tested. I think the issue is that CSV sounds very easy to implement, but most naive implementations will be wrong.
2) You took on exactly the responsibilities the article author said you'd have to take on. Based on the screenshots for your "Strukt" application, it looks like the user controls configuration/validation for parsing CSV and they will fix any issues with parsing the CSV file themselves.
> If a supplied CSV is arbitrary, the only real way to make sure the data is correct is for an user to check it and eventually specify the delimiter, quoting rule,… Barring that you may end up with a error or worse silently corrupted data.
3) I think the better question is, how do you handle malformed CSV? Is your error correction as robust as Ruby's? Do you handle malformed CSV the same way as other libraries? If it's handled differently by different parsers, you can run into issues like Apple recently did [0]
[0] https://siguza.github.io/psychicpaper/
Yes, you are right that they allow their own JIT. Their position would be that they spend a great deal of time hardening that JIT and don't trust others to take that time. Their JIT isn't perfect of course, but they control it and can fix it fast if needed. (In their opinion.) They are really saying that they aren't willing to take the time to exhaustively test other JITs. That is a frustrating choice, but I do understand the thinking.
You raise the bigger point. Is there no way for their platform sandbox to handle the concerns? That is a great question.
>Plus, it’s not like normal code doesn’t have buffer overflows or other security issues.
I think normal code on an M1 only runs in rx memory blocks [0,1], so no buffer overflow attacks. At least not without another attack to remap the blocks. This might go back to A12 processors. M1 strengthened the model.
Perhaps with these newer processors, the hardware support can harden the sandbox enough to allow more flexibility. One can hope...
[0] https://blog.svenpeter.dev/posts/m1_sprr_gxf/
[1] https://siguza.github.io/APRR/
To truly open up iOS, by my understanding, Apple would need to remove the requirement for notarisation of binaries. This would mean they'd also need to sort out their entitlements system, given an app can use entitlements to say it isn't sandboxed. That was the root cause of a recent exploit, where differing parsing logic allowed an app to get signed while declared as unsandboxed. (https://siguza.github.io/psychicpaper/)
One approach could be to namespace installed apps based on the store ecosystem which installed them. Assuming platform level permissions for access to user data are enforced by the platform and can't be worked around via the manifest file, this would ensure apps can't move around outside of their "store" sandbox and access the data of other apps.
More ideally, Apple would move away from signing a plist that gives an app special access, towards the user prompts like those for contacts access etc. And where possible, use portals to give granular access to selected resources like photos (or selected contacts).
Regarding IOHIDFamily: An application may be able to execute arbitrary code with kernel privilege
I found this: https://siguza.github.io/IOHIDeous/
that was published Dec 31.
It took Apple 23 days since it was public before they released a fix.
> The exploit accompanying this write-up consists of three parts:
> poc (make poc)
Targets all macOS versions, crashes the kernel to prove the existence of a memory corruption.
> leak (make leak)
Targets High Sierra, just to prove that no separate KASLR leak is needed.
> hid (make hid)
Targets Sierra and High Sierra (up to 10.13.1, see README), achieves full kernel r/w and disables SIP to prove that the vulnerability can be exploited by any unprivileged user on all recent versions of macOS [!!!!!!!!!]
Usually, once you can run code in kernel mode it’s just a matter of bringing the hardware back to a sane state.
Unfortunately, “just” running code in kernel mode is incredibly hard on the iPad. There’s e.g. a hardware mitigation that turns a memory region to read-only and also only allows kernel code to run from this region. This mitigation is locked down and cannot be disabled once XNU is running on the iPad (http://siguza.github.io/KTRR/).
On top of that page tables are also protected by a “kernel within the kernel” (https://blog.svenpeter.dev/posts/m1_sprr_gxf)
Getting past all that is going to be very hard if not impossible.
Dev mode is still limited and doesn't grant root access to the device. In dev mode there's still an app certificate, and Apple still signs it, and still prohibits escaping the app sandbox. There are also JIT specific entitlements to allow an app to dynamically load or generate code. Without those, it's unclear how feasible a developer-signed version of Firefox on iOS is.
https://siguza.github.io/psychicpaper/ is a recent writeup that includes more details on (escaping) the limitations.