1. 19
  1.  

  2. 2

    Great explanation of an amazing find. But I really can’t tell if the author is just overexcited or just really awful:

    At the time of writing, this bug is still present on the latest non-beta version of iOS. The whole project is available on GitHub, have fun with it while it lasts!

    Uhh what? Embargo? Patched in Beta is not patched for everyone! This is so irresponsible and security research should not be done this way.

    In other words, any parser difference can be exploited to make different parsers see different things. This is the very heart of this bug, making it not just a logic flaw, but a system-spanning design flaw.

    Using multiple XML parsers is the design flaw, the bug itself is a logic flaw. I get that the author is excited, but please, take it down a few notches.

    It’s this kind of stuff that gives vulnerability engineers a bad name imo.

    1. 3

      Open publication is the only way to effectively allow the community to provide oversight to the otherwise-walled-in Apple ecosystem. In conversations about this story with others, folks are struck by the possibility that APTs have already discovered techniques like this and use them to target individual phones. We cannot trust Apple to be honest. Therefore we must have an ecosystem of reporting vulnerabilities which does not rely on Apple’s blessing.

      Using multiple XML parsers is the design flaw, the bug itself is a logic flaw.

      All computer bugs are, in some way, logic flaws; with sufficient forethought and careful logical reasoning, no bugs are truly inevitable. The author’s point is that Apple was wrong in their design phase to use multiple XML parsers, in the same way that any of us would be remiss if we chose both Expat and libxml2 in a Free Software project. Further, their point continues: This bug seems only to be possible when multiple XML parsers are applied; if there were only one XML parser present, then this bug could not occur. This analysis counterfactually shows that the design mistake could be the root cause.

      1. 2

        There’s a difference between publishing a vuln before or after the patch is widely available though.

        Sure, releasing the vulnerability lets people divest from Apple if they don’t like what Apple is doing and how they responded, but doing it before there’s a patch for everyone is just needless risk.

        Yes, it’s Apple’s responsibility to rush the patch out ASAP, and the APT risk is always there, but this early release just means that two-bit malware authors can now include it easily in a millions ways to try to sneak it past App Store app review.

        There are industry-standard ways to get this accountability. Say, the 90-day window that Google uses.

        Re: The last point, sure, semantically that may be true, my point was about the tone of the writing. The gleeful “shit’s broke” attitude is fun but it alienates software engineers who can fix these things and adopt better security practices goong forward.

        1. 2

          Considering this zeroday has been ignored for years, I think a little glee is in order.

          For starters, it’s doubtful that this guy is the only one who found this exact bug.

          Furthermore, your argument better applies to an average shop, not one of the most richest companies on the planet that can afford to take every bug seriously. This is more of a tale of arrogance from Apple than it is about a young developer being overly proud of a simple solution to breaking a sandbox designed by very well compensated engineers.

          1. 1

            That’s fair. Definitely didn’t want to detract from the work, it’s awesome for sure, and full kudos to the author.

            Thanks, this is a good point about Apple vs other orgs.

            1. 2

              I’m happy you found it helpful!!

              As a youngish engineer (29), I’ve noticed a tendency of other professionals telling people like me to be more “professional”. Sometimes it’s perfectly apropos. Other times I’ve seen it used like in this situation. There’s a logic to it - it’s much easier “correcting” someone who is young, compared to correcting a corporation. I guess it’s a logic of “what can I do”, which is fair some of the time. I only pushed back because I noticed the power differential was so immense. But in doing so, I wonder what really is the boundary in situations like this?

              I mean, your point towards asking for the author to be more professional is very, very important when dealing with a smaller industry where retaliation and blacklisting is the kiss of death to anyone’s career. And that makes me wonder more about the issue of fame/infamy dynamic in recruiting.

              Guess this is my roundabout way of saying “I think you’re on to something, even if some of it is inherently unfair” 🙂

              1. 1

                Absolutely. I guess I feel a subtle distinction between “professionalism” and just “being friendly” (wrt communicating to non-security engineers) and reducing risk/being ethical (wrt consumers) but your points definitely make sense.

                To your point about “other professionals,” hah, I’m a student, so I have no right to tell industry what to do XD

          2. 1

            I personally think that every engineer ought to have that attitude, though, and have it about their own work. When somebody tells me that they’ve found an exploit in my code, I am excited. I don’t mind making mistakes; I enjoy learning about ways to improve, and seeing what clever improvisation led to discovery of vulnerability. I deliberately take a stance of humility when it comes to my own ability to write correct code, and accordingly, I don’t punish myself for mistakes, but take them as opportunities to make things better.

            The App Store’s apps are not automatically safe. It is Apple’s contention that they are safe, and Apple risks their reputation by saying so. But Apple clearly isn’t the author of most App Store software. Should we really embargo a vulnerability because Apple has intentionally created a walled garden and tried to pretend that the vulnerability doesn’t exist? It seems like this worldview is only good for coddling consumers, personally; if Apple actually cared, then they would design APIs which are harder to exploit. plists have been around for some three decades, and the XML-based versions for two decades; Apple clearly doesn’t care enough to harden the design.

            1. 1

              There might be a disconnect here between talking philosophy (completely agree with what you’re saying and I hope all devs have the attitude you describe!) and practice, but I see where you’re coming from.

              I don’t like the idea of putting consumers at additional risk unnecessarily, but in this case maybe that risk was mitigated or at least already there and thus this didn’t add to it in the short term.

              Thanks for the input!