4 ms·

Fuzzing, dynamic analysis or DAST might have found it too. Assuming Apple has deployed all of these and have invested in the labor/training on how to properly

Fuzzing, dynamic analysis or DAST might have found it too. Assuming Apple has deployed all of these and have invested in the labor/training on how to properly use them.

tptacek 5mo ago
Then why didn't they?
- kimixa 5mo ago
  I think the real point is they didn't - until it became a "marketing" thing for another company who did it for them. A lot of these issues would be highlighted by "legacy" (pre-AI) analysis tools. The issue is that they weren't being run.
  - tptacek 5mo ago
    Why not? We're talking about vulnerabilities with real market value here. If it was just a tool run, why weren't the tools run? Isn't the simpler explanation that they weren't just a tool run?
    - firesteelrain 5mo ago
      The tools are expensive. One of the major players in the market have really expensive licensing fees. Then the developers all need to be trained on how to use the tools and understand the results. It’s not something they teach effectively in schools. Software engineering is still kind of new overall.
      - tptacek 5mo ago
        Which tool specifically are you thinking of that might have found this but wasn't run because of it's very high licensing fees? I work in this field, I'll be familiar with it.
        firesteelrain 5mo ago
        Black Duck products https://www.blackduck.com/fuzz-testing.html https://www.blackduck.com/fuzz-testing.html OpenText products https://www.opentext.com/products/dynamic-application-security-testing https://www.opentext.com/products/dynamic-application-securi... I won’t say how much they are here but they are very expensive.
        tptacek 5mo ago
        Just to be clear: your claim is that the Black Duck fuzzer would have enabled the rapid discovery of kernel vulnerabilities in macOS?
        firesteelrain 5mo ago
        Question was about high licensing fees and which tools I was referring to I’m not claiming Defensics or OpenText DAST tools are magical “find all kernel vulns” buttons My point is more that mature fuzzing ecosystems already existed before the recent AI-driven approaches. Protocol fuzzers, syscall fuzzers, coverage-guided fuzzers, sanitizers, dynamic analysis, etc. have all historically found serious kernel bugs
        tptacek 5mo ago
        We might just be talking past each other. My question, from upthread, is this: the heyday of AFL was over a decade ago. Every major platform company fuzzes at a scale that I think is difficult for lay practitioners to get their heads around. They contract, quarterly, soup-to-nuts assessments from competing software security companies, who get full source access and are measured against each other by the quality of their findings. They run bounty programs specifically to direct public researcher attention to these exact findings. Why didn't "mature fuzzing ecosystems" find the vulnerabilities AI is now finding? It's a pretty big gap in the "fuzzing tools already do this" logic!
        firesteelrain 5mo ago
      - akerl_ 5mo ago
        Apple has a massive information security organization that has pretty intense resources at their disposal. It seems borderline impossible that there's a tool that they feel would be beneficial but that they're classed out of using by license costs or by staff proficiency.
        firesteelrain 5mo ago
        It happens at a lot of places that the budget isn’t unlimited when it comes to information security. But even then it comes down to risk management.
        akerl_ 5mo ago
        We’re in a thread about an Apple vulnerability, where the claim was made that they’d have found these if they’d properly run traditional tooling.
        kimixa 5mo ago
        I find this amusing as Apple were the people I had direct interactions with that didn't run stuff like fuzzers or sanitizers as a matter of course - at least not in the situations I was involved with. Though this was ~3 years ago now, and a lot of things have changed, but these tools were very much available and well known then - they aren't new. Though perhaps as they "knew" the project was coming to a close it wasn't a priority either? It also might have fallen through the gaps due to the Apple internal/team culture - I worked for an external vendor, and we had to work against binary built framework dumps that didn't even allow us to enable things like address sanitizer completely either, and fuzzing difficult as you'd need to trace things through their opaque binary layers before it even reached our code. Apple did have all our code though, it was very much an asymmetrical relationship, but if they were running such things as a matter of course in CI or similar you'd see that pattern in when they reported issues it caught, and the timings from time-of-bug-caused to time-of-report. It instead suggested any such runs were piecemeal and sporadic at best. Though, it wouldn't really surprise me if they were being run and finding issues all the time, but they never actually got back to us. This certainly wouldn't be the first time we ran into "difficulties" due to the nature of the relationship and culture.
      - NitiX 5mo ago
        [flagged]
- Someone 5mo ago
  Could be any (combination) of - looking at components in isolation, not realizing that a component could receive untrusted input - looking at the entire system, but not in a configuration that made the CVE possible - having to be extremely lucky to find the issue through fuzzing, and Apple not hitting that jackpot - having found the issue in testing, but incompletely/incorrectly fixing it - mostly focusing testing on other components because this one’s code didn’t change and hadn’t seen issues in years I don’t think we have enough info to know which (or something entirely different) it is.
pbgcp2026 5mo ago
... because it was vibe coded by someone in ... other country. Cut the corners, deliver fast! Consume tokens!

Fuzzing, dynamic analysis or DAST might have found it too. Assuming Apple has deployed all of these and have invested in the labor/training on how to properly use them.

tptacek 5mo ago

Then why didn't they?

kimixa 5mo ago
I think the real point is they didn't - until it became a "marketing" thing for another company who did it for them. A lot of these issues would be highlighted by "legacy" (pre-AI) analysis tools. The issue is that they weren't being run.
- tptacek 5mo ago
  Why not? We're talking about vulnerabilities with real market value here. If it was just a tool run, why weren't the tools run? Isn't the simpler explanation that they weren't just a tool run?
  - firesteelrain 5mo ago
    The tools are expensive. One of the major players in the market have really expensive licensing fees. Then the developers all need to be trained on how to use the tools and understand the results. It’s not something they teach effectively in schools. Software engineering is still kind of new overall.
    - tptacek 5mo ago
      Which tool specifically are you thinking of that might have found this but wasn't run because of it's very high licensing fees? I work in this field, I'll be familiar with it.
      - firesteelrain 5mo ago
        Black Duck products https://www.blackduck.com/fuzz-testing.html https://www.blackduck.com/fuzz-testing.html OpenText products https://www.opentext.com/products/dynamic-application-security-testing https://www.opentext.com/products/dynamic-application-securi... I won’t say how much they are here but they are very expensive.
        tptacek 5mo ago
        Just to be clear: your claim is that the Black Duck fuzzer would have enabled the rapid discovery of kernel vulnerabilities in macOS?
        firesteelrain 5mo ago
        Question was about high licensing fees and which tools I was referring to I’m not claiming Defensics or OpenText DAST tools are magical “find all kernel vulns” buttons My point is more that mature fuzzing ecosystems already existed before the recent AI-driven approaches. Protocol fuzzers, syscall fuzzers, coverage-guided fuzzers, sanitizers, dynamic analysis, etc. have all historically found serious kernel bugs
        tptacek 5mo ago
        We might just be talking past each other. My question, from upthread, is this: the heyday of AFL was over a decade ago. Every major platform company fuzzes at a scale that I think is difficult for lay practitioners to get their heads around. They contract, quarterly, soup-to-nuts assessments from competing software security companies, who get full source access and are measured against each other by the quality of their findings. They run bounty programs specifically to direct public researcher attention to these exact findings. Why didn't "mature fuzzing ecosystems" find the vulnerabilities AI is now finding? It's a pretty big gap in the "fuzzing tools already do this" logic!
        firesteelrain 5mo ago
    - akerl_ 5mo ago
      Apple has a massive information security organization that has pretty intense resources at their disposal. It seems borderline impossible that there's a tool that they feel would be beneficial but that they're classed out of using by license costs or by staff proficiency.
      - firesteelrain 5mo ago
        It happens at a lot of places that the budget isn’t unlimited when it comes to information security. But even then it comes down to risk management.
        akerl_ 5mo ago
        We’re in a thread about an Apple vulnerability, where the claim was made that they’d have found these if they’d properly run traditional tooling.
      - kimixa 5mo ago
        I find this amusing as Apple were the people I had direct interactions with that didn't run stuff like fuzzers or sanitizers as a matter of course - at least not in the situations I was involved with. Though this was ~3 years ago now, and a lot of things have changed, but these tools were very much available and well known then - they aren't new. Though perhaps as they "knew" the project was coming to a close it wasn't a priority either? It also might have fallen through the gaps due to the Apple internal/team culture - I worked for an external vendor, and we had to work against binary built framework dumps that didn't even allow us to enable things like address sanitizer completely either, and fuzzing difficult as you'd need to trace things through their opaque binary layers before it even reached our code. Apple did have all our code though, it was very much an asymmetrical relationship, but if they were running such things as a matter of course in CI or similar you'd see that pattern in when they reported issues it caught, and the timings from time-of-bug-caused to time-of-report. It instead suggested any such runs were piecemeal and sporadic at best. Though, it wouldn't really surprise me if they were being run and finding issues all the time, but they never actually got back to us. This certainly wouldn't be the first time we ran into "difficulties" due to the nature of the relationship and culture.
    - NitiX 5mo ago
      [flagged]
Someone 5mo ago
Could be any (combination) of - looking at components in isolation, not realizing that a component could receive untrusted input - looking at the entire system, but not in a configuration that made the CVE possible - having to be extremely lucky to find the issue through fuzzing, and Apple not hitting that jackpot - having found the issue in testing, but incompletely/incorrectly fixing it - mostly focusing testing on other components because this one’s code didn’t change and hadn’t seen issues in years I don’t think we have enough info to know which (or something entirely different) it is.

pbgcp2026 5mo ago

... because it was vibe coded by someone in ... other country. Cut the corners, deliver fast! Consume tokens!