User-set name strings are not trusted data. Even if you filter on submission, people will find ways around it.
This is the second "User can set the name of a device to a string that screws things up badly" bug in recent history. The other one was the "You can set your AirTag name to cross site scripting tags" one.
https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...
The whole point of a “zero day” is that people don’t know about it ahead of time.
That deploying:
* nginx
* node
* apache
* java
* ruby
* python
* bash
* linux
* chrome
etc
is lax with security?
The amount of "audited" code is vanishingly small, and as many "audited" crypto contracts have demonstrated those audits don't ensure code is bug free, and those are trivial pieces of code.
If it's protecting nuclear secrets or the personal information of hundreds of millions of people (as in the case of Apple), then yes, deploying Linux is absolutely being lax with security. The kernel itself has had thousands of security vulnerabilities, with userspace on top adding tens of thousands more.
If you're writing software for your smartwatch, then maybe Linux (or node/apache, which are built to lesser quality standards) is OK.
Log4j has, to my knowledge, never been audited.
I'm taking the fact that I haven't heard of log4j being audited, the fact that I haven't heard of Apple auditing an external product before importing it into their environment, and the fact that auditing open-source software isn't standard practice among tech companies to make that assumption.
...although, the bug is sort of blatant. I would hope that an audit would catch this particular one, at least.
I wonder if it was a “necessary” fault: I can imagine someone going “let’s validate this string and terminate if it’s invalid”. That mitigates security problems very effectively, however it’s clearly actually a bad thing if you can trigger it trivially in a semi-permanent manner.
Projects like webkit and blink aggressively use release asserts on internal invariants that should not happen, but they’re not triggered on raw inputs.
In this case such a response would be inappropriate (I have know idea what the actual bug in the code was, whether it was deliberate or unintentional). Hell I’ve seen utf8 libraries that terminate on invalid input, so good luck using those :-/
At least that is the logic that occurs. I am not saying it’s good logic :)
Honestly I feel the bigger bug is something going wrong in HomeKit taking out springboard.
You might even be able to implement it in the sandboxing system.