4 ms·

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-resea

by _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
        There's no public record of the log4j code being audited, nor is there any indication that Apple audits the open-source code they use before deployment.
    - olliej 5y ago
      Are you saying that you believe that deploying linux is being lax with security? 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.
      - throw10920 5y ago
        "Lax" depends on what your code is doing. 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.

by _jal 5y ago

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
      There's no public record of the log4j code being audited, nor is there any indication that Apple audits the open-source code they use before deployment.
  - olliej 5y ago
    Are you saying that you believe that deploying linux is being lax with security? 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.
    - throw10920 5y ago
      "Lax" depends on what your code is doing. 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.