5 ms·

Dear Apple: 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 t

by Syonyk 5y ago

Dear Apple: 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.

ripa 5y ago
there was also the WiFi name where it would disable the iPhone's WiFi. https://www.macrumors.com/2021/06/20/ios-bug-network-name-disable-wifi-iphones/ https://www.macrumors.com/2021/06/20/ios-bug-network-name-di...
_jal 5y ago
Renaming your phone also triggered the Log4Shell vuln at one point. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sms-log4shell-log4j-exploit-researchers-test https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...
- throw10920 5y ago
  This is a good point - here, the victim wouldn't have been the user, but Apple themselves, illustrating that (occasionally, not always) being lax with security can come and bite you (instead of just your users).
  - olliej 5y ago
    They weren’t lax with security, they updated as quickly as every other major company did. They were caught out by the same zero day as everyone else. The whole point of a “zero day” is that people don’t know about it ahead of time.
    - throw10920 5y ago
      Deploying unaudited code is being lax with security.
      - als0 5y ago
        Audited code can still have bugs.
        throw10920 5y ago
        Of course! But it generally has fewer bugs than it did before, and you have greater confidence that it has fewer bugs. Perfect security is not achievable - you just make the best trade-offs that you can. Log4j has, to my knowledge, never been audited.
        als0 5y ago
        I'm just pointing out that you assume Apple deployed unaudited code, just because the code had a bug. I would not make that assumption.
        throw10920 5y ago
        My apologies, I wasn't clear. I agree, audited code can have bugs - but I'm not assuming that the presence of the bug was the indicator that it hadn't 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.
      - op00to 5y ago
        How do you know the code was unaudited?
        throw10920 5y ago
deleted 5y ago
[deleted]
vxNsr 5y ago
It really feels like sanitizing user inputs is a new concept to Apple.
- musicale 5y ago
  You'd think they'd have implemented data taint tracking or something in the Swift language/runtime/libraries to reduce the attack surface. You might even be able to implement it in the sandboxing system.
- olliej 5y ago
  The problem is really how you respond - a valid (from a security standpoint) response to invalid input is termination: it means that you can’t exploit it. 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 :-/
  - 0x0 5y ago
    Doesn't help if you're just terminating the springboard over and over, basically bootlooping the device
    - olliej 5y ago
      But at least it’s not a security bug \o/ 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.
olliej 5y ago
If you can’t trust users, who can you trust? :D 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.

by Syonyk 5y ago

ripa 5y ago

there was also the WiFi name where it would disable the iPhone's WiFi. https://www.macrumors.com/2021/06/20/ios-bug-network-name-disable-wifi-iphones/ https://www.macrumors.com/2021/06/20/ios-bug-network-name-di...

_jal 5y ago

Renaming your phone also triggered the Log4Shell vuln at one point. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sms-log4shell-log4j-exploit-researchers-test https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...

throw10920 5y ago
This is a good point - here, the victim wouldn't have been the user, but Apple themselves, illustrating that (occasionally, not always) being lax with security can come and bite you (instead of just your users).
- olliej 5y ago
  They weren’t lax with security, they updated as quickly as every other major company did. They were caught out by the same zero day as everyone else. The whole point of a “zero day” is that people don’t know about it ahead of time.
  - throw10920 5y ago
    Deploying unaudited code is being lax with security.
    - als0 5y ago
      Audited code can still have bugs.
      - throw10920 5y ago
        Of course! But it generally has fewer bugs than it did before, and you have greater confidence that it has fewer bugs. Perfect security is not achievable - you just make the best trade-offs that you can. Log4j has, to my knowledge, never been audited.
        als0 5y ago
        I'm just pointing out that you assume Apple deployed unaudited code, just because the code had a bug. I would not make that assumption.
        throw10920 5y ago
        My apologies, I wasn't clear. I agree, audited code can have bugs - but I'm not assuming that the presence of the bug was the indicator that it hadn't 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.
    - op00to 5y ago
      How do you know the code was unaudited?
      - throw10920 5y ago

deleted 5y ago

[deleted]

vxNsr 5y ago

It really feels like sanitizing user inputs is a new concept to Apple.

musicale 5y ago
You'd think they'd have implemented data taint tracking or something in the Swift language/runtime/libraries to reduce the attack surface. You might even be able to implement it in the sandboxing system.
olliej 5y ago
The problem is really how you respond - a valid (from a security standpoint) response to invalid input is termination: it means that you can’t exploit it. 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 :-/
- 0x0 5y ago
  Doesn't help if you're just terminating the springboard over and over, basically bootlooping the device
  - olliej 5y ago
    But at least it’s not a security bug \o/ 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.

olliej 5y ago

If you can’t trust users, who can you trust? :D 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.