![]() There's no benefit at all to doing this.This alters the default PATH, which will probably break a lot of stuff because it's not all that uncommon to reset PATH back to the default of "/usr/bin:/bin" or to the fairly common "/usr/local/bin:/usr/bin:/bin".This means Apple inventing a brand new system-level nobody-but-Apple-should-really-be-touching-this folder for storing the handful of developer tools shims, for which there is no -nix precedent and so they'd have to make up something new.The only way to test that is for me to intentionally break my Xcode install and I'm not going to do that since I actually need it to work.Įdit 2: Also, why the heck would you try to compromise /usr/bin/git anyway? If you're in a position to do that, you're already in a position to execute whatever code it is you want, so waiting until the user executes `git` to do it isn't very useful. The former only serves to affect scripts that hard-code /usr/bin/git (except that's not very common since it's not at that path on all systems, and hard-coding that means the user can't provide their own version of git if they want to).Įdit: All that said, Xcode and all of its embedded components are code-signed, and it's entirely possible that /usr/bin/git requires the actual git binary to be codesigned by Apple. It's really only protected because all of /usr/bin is protected.Īnother way to look at it is there's not much difference between replacing the binary that /usr/bin/git executes and adding a compromised `git` binary somewhere in the user's PATH, since the user will invoke your malicious tool either way the next time they run `git`. Nothing on the system relies on it working (after all, it doesn't even work at all until you install Xcode). ![]() `git` is not a system-critical component. If someone knows, please inform me rather than voting me down, I'm interested in understanding the logic behind all of this! I recognise that I may be missing something, but for the life of me I'm struggling to see what this might be. but it seems pointless installing executables like git that aren't directly essential to the running of OS X in this system folder in the first place! Sure, other executables haven't been compromised which is a good thing. If I'm a malware author who somehow gains access to root, I just locate where git is actually located and I install my own compromised version. ![]() So what, pray tell, was the point of SIP when their own people poke huge holes like this in their supposedly immutable discretionary access control system? But they use a tool that locates and executes an executable in a directory that can be updated. SIP has been designed to prevent malware authors updating executables in system directories. ![]() So basically, you can update the executable yourself? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |