1. 35
  1.  

  2. 7

    I’m not sure if they actually read the manual page and pretended they didn’t, or just got really lucky with their pick of return. But by returning 0, they actually successfully informed the program that nothing had any extended attributes. Also, this line will keep me up at night:

    Q: Is the return value of 0 important?

    A: Yes. I originally tried 1, but that caused some games to allocate all available memory and crash once none was left.

    1. 1

      Is there any countermeasure applications can take to avoid this kind of “hack”? The fact that anyone with write access to DYLD_LIBRARY_PATH can override a system call or a library function sounds like a huge vulnerability to me.

      1. 6

        The fact that anyone with write access to DYLD_LIBRARY_PATH can override a system call or a library function sounds like a huge vulnerability to me.

        Yep. That’s why the UNIX ideas of users/groups/permissions is woefully inadequate for our modern use cases, where the sole user is trusted but the code may not be.

        1. 2

          the sole user is trusted but the code may not be

          I don’t follow. These type of dynamic linker overrides allow the user to control the code. If the user is trusted, that’s not a problem.

          I think the real problem is “trusted” (locked down) code that doesn’t trust the user. In that case, these options run counter to that goal. However, it’s also not clear to me that it’s a desirable goal - it’s a goal to keep users dependent on vendors, but not a security goal.

          1. 4

            These type of dynamic linker overrides allow the user to control the code. If the user is trusted, that’s not a problem.

            I think we’re conflating two different ideas of “user” here, and my comment could certainly have been written more clearly.

            The first definition is the machine operator. That person should definitely be able to do whatever they want on the machine, and should be able to override dynamic libraries as much as they want.

            The second definition is as a permission boundary; the UNIX sense. If I download an application from the internet, it should not have the same permissions as me, the machine operator, by default. But it does, and it’s able to override DYLB_LIBRARY_PATH and exec whatever it wants. There’s no good reason my text editor should have internet access. macOS’s approach to this is an improvement, but I agree that being reliant on a centralized source of trust is extremely problematic.

            As an aside, I interviewed for Apple’s security engineering and architecture team back in late 2019, so I had the opportunity to talk with their engineers about some of this. I didn’t get the position in the end, but it was an interesting experience. One of the biggest threats they wanted to protect against is phishing and fake apps. I was told that any off-switch is an off-switch that a user can be socially engineered into toggling. Teams inside of Apple seemed to be somewhat isolated, so while Vendor lock-in does seem to be a goal of Apple’s iOS/iPadOS App Store, I don’t think it’s the only goal.

        2. 3

          So the short answer to this is yes this is a major issue, and there are kind of countermeasures. There’s a whole world of “dylib hijacking” and “dll hijacking” (the Windows equivalent which is even more sketchy) that I highly recommend you look up, because it’s awesome and super hacky and so much fun to play with.

          1. 3

            On OS X, if the app turns on library validation DYLD_LIBRARY_PATH and DYLD_INSERT_(something? I can’t recall) and similar are all disabled at the dyld level - it isn’t bypassable