5 ms·

Is there a reason they aren't making this change only for apps compiled with the latest SDK?

yakubin 4y ago
Does iOS use different libc dynamic libraries for applications compiled with different SDKs? I'm not an iOS developer, so I don't know, but I would assume there is only one libsystem_c.dylib[1] on iOS. [1]: Or even 0, as in Big Sur, where it's provided inside the runtime linker(/loader), instead of being a separate file.
- TheTon 4y ago
  They don’t (usually) have different versions but they do have “linked on or after checks”. So one libsystem, but it can look at the sdk the software was built against and adjust its behavior accordingly. But I have no idea if they’re doing that here.
- saagarjha 4y ago
  Usually no.
kevingadd 4y ago
Security, probably. UAF attacks are going to be slightly harder to perform if the data you put there is zeroes now.
- rs_rs_rs_rs_rs 4y ago
  >UAF attacks are going to be slightly harder to perform SOME attacks are going to be harder, others are going to be easier(at least that's what a Project Zero researcher thinks) https://twitter.com/ifsecure/status/1572902862128295937 https://twitter.com/ifsecure/status/1572902862128295937
  - jeffbee 4y ago
    If they “worked until now” doesn’t that imply that the app ecosystem makes too little use of sanitizers like ASAN? Sanitizers will stomp on deallocated regions, and much much more.
  - kevingadd 4y ago
    That appears to be the effect of changes to calloc, though. The change to free is a security improvement.
josho 4y ago
Yes. This protects your data against a malicious app. Your proposal gives a malicious app a workaround to avoid this. Is there a reason you don’t want this on by default?
- kllrnohj 4y ago
  No it doesn't. Malicious apps aren't impacted by this at all. It's a hardening technique for non-malicious apps to help protect them against malicious inputs. Which any maintained, updated app would naturally just get when they update, and in the meantime there's no regression in security from previous releases. It's only on-everywhere because Apple doesn't do backwards compatible. Update or get kicked out is the expectation.
  - josho 4y ago
    Aren't both benefits? E.g. a malicious app mallocs a large buffer and just reads the memory looking for anything interesting? AND as you pointed out a non-malicious app that doesn't handle input. > It's only on-everywhere because Apple doesn't do backwards compatible. If this causes issue in an app then doesn't it mean that app has a possible vulnerability? So, it can be argued that breaking an app is increasing the security of the ecosystem. And yes, I understand the other side too of having an obscure app that you depend upon breaking because it is no longer supported. That's also the type of app that doesn't have a high probability of being exploited.
    - esprehn 4y ago
      > E.g. a malicious app mallocs a large buffer and just reads the memory looking for anything interesting? No, the OS zeros pages before giving them to a new process, otherwise you'd have all kinds of information leaks across security boundaries. You only see dirty memory within the same process when you malloc and then free and malloc again and get a page from the free list within the process. Increasingly allocators are zeroing those too though to reduce the attack surface from malicious inputs (which is what changed in iOS).
    - kllrnohj 4y ago

Does iOS use different libc dynamic libraries for applications compiled with different SDKs? I'm not an iOS developer, so I don't know, but I would assume there is only one libsystem_c.dylib[1] on iOS. [1]: Or even 0, as in Big Sur, where it's provided inside the runtime linker(/loader), instead of being a separate file.

TheTon 4y ago
They don’t (usually) have different versions but they do have “linked on or after checks”. So one libsystem, but it can look at the sdk the software was built against and adjust its behavior accordingly. But I have no idea if they’re doing that here.
saagarjha 4y ago
Usually no.

kevingadd 4y ago

Security, probably. UAF attacks are going to be slightly harder to perform if the data you put there is zeroes now.

rs_rs_rs_rs_rs 4y ago
>UAF attacks are going to be slightly harder to perform SOME attacks are going to be harder, others are going to be easier(at least that's what a Project Zero researcher thinks) https://twitter.com/ifsecure/status/1572902862128295937 https://twitter.com/ifsecure/status/1572902862128295937
- jeffbee 4y ago
  If they “worked until now” doesn’t that imply that the app ecosystem makes too little use of sanitizers like ASAN? Sanitizers will stomp on deallocated regions, and much much more.
- kevingadd 4y ago
  That appears to be the effect of changes to calloc, though. The change to free is a security improvement.

josho 4y ago

Yes. This protects your data against a malicious app. Your proposal gives a malicious app a workaround to avoid this. Is there a reason you don’t want this on by default?

kllrnohj 4y ago
No it doesn't. Malicious apps aren't impacted by this at all. It's a hardening technique for non-malicious apps to help protect them against malicious inputs. Which any maintained, updated app would naturally just get when they update, and in the meantime there's no regression in security from previous releases. It's only on-everywhere because Apple doesn't do backwards compatible. Update or get kicked out is the expectation.
- josho 4y ago
  Aren't both benefits? E.g. a malicious app mallocs a large buffer and just reads the memory looking for anything interesting? AND as you pointed out a non-malicious app that doesn't handle input. > It's only on-everywhere because Apple doesn't do backwards compatible. If this causes issue in an app then doesn't it mean that app has a possible vulnerability? So, it can be argued that breaking an app is increasing the security of the ecosystem. And yes, I understand the other side too of having an obscure app that you depend upon breaking because it is no longer supported. That's also the type of app that doesn't have a high probability of being exploited.
  - esprehn 4y ago
    > E.g. a malicious app mallocs a large buffer and just reads the memory looking for anything interesting? No, the OS zeros pages before giving them to a new process, otherwise you'd have all kinds of information leaks across security boundaries. You only see dirty memory within the same process when you malloc and then free and malloc again and get a page from the free list within the process. Increasingly allocators are zeroing those too though to reduce the attack surface from malicious inputs (which is what changed in iOS).
  - kllrnohj 4y ago