Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

91–100 of 385 posts

Re: Remote code execution, git, and OS X

#91
post #70

Earlier quoted context omitted.

Why does debian do that instead of upgrading everyone to the latest git version?

Debian 'stable' releases mainly target people who like fixed upgrade cycles. No feature/API/etc. changes for the lifetime of a release, only security patches. Means that you can have your servers routinely applying updates with relatively little worry that something is going to stop working because of a change. Even minor feature changes can break things, especially when run in scripts, so they prefer not to risk non…

"testing" is probably the worst choice. It's auto-generated from unstable with a 10 (iirc) day delay if no critical bugs are open. However, if a critical bug is fixed in unstable and another one found that affects both unstable and testing, then the release fixing the first bug won't migrate to testing, so you'll have an even more broken version for a longer time. Testing also receives no security updates. Unstable doesn't get security updates either (in the sense that the security team doesn't provide updates to unstable), but it usually gets fixed versions pretty quickly, and certainly before testing.

"unstable" with apt-listbugs installed works quite well for me. Sometimes I have to boot grml to roll back packages (check out the grml-rescueboot package), but that's very rare.

Re: Remote code execution, git, and OS X

#92

Earlier quoted context omitted.

Except for those who have used it and refuse to use it again. There are prebuilt binaries of up to date git distributed via .pkg. The yeast infection that is Homebrew is unnecessary

That's kind've harsh. What's the issue? Homebrew was about the best option that's existed on OSX for a few years now I thought...

The dependency management is a joke, compile-by-default means it's slow as hell.

Re: Remote code execution, git, and OS X

#93
See, this I don't understand. We have open source distributions who provide massive amounts of packages, for free, on a continual basis and don't have any where near the amount of profits that Apple has. Yet Apple, who have a lot of users and must update severe security flaws, don't have a reasonable way of updating system software.

Instead, we get the updates once ever so often and these security updates don't even come close to fixing all the security bugs in the software on my OS X operating system.

It's really not very good. Vendors such as Apple and Microsoft are far, far too slow in releasing updates.

Re: Remote code execution, git, and OS X

#94
So... to try and get an answer to the unanswered question in the blogpost. The files are probably hardlinks to a single "superbinary" image somewhere. The actual code is probably checking the value of argv[0] to dispatch to the actual git code (or whatever command name was invoked). The question is, why is Apple doing this? Is it some sort of diskspace saving scheme (to avoid duplicating common boilerplate code)? I suspect some part of this answer includes the words "for security" but it's already been proven to be BS at this point.

Re: Remote code execution, git, and OS X

#95
post #89

Same as always. Apple only care about security when people start screaming. I can't wait until a worm or similar wide-spread disaster hits the Apple eco-system and just deletes the system when it's done spreading.

So ... has anybody actually checked to see if Apple has patched the vulnerability in git without bumping the version number, like pretty much every linux distribution does for their stable releases?

You're joking, right? When I use software and I look at the version number, I like to know that it is what it says it is. If they are going to patch the vulnerability, then I want to know if they have done so.

Besides which, this whole question is missing the point somewhat. There is no easy way of updating the system supplied tools like git, even if you wanted to. The latest version of git is v2.8, and I think it would be grand if we could use a version less than 6 months old!

Hell, the same goes with any other system software.

Re: Remote code execution, git, and OS X

#96
post #13
post #4

Remember when I said El Capitan? Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths. Not even root is enough to do it. Can someone explain it to me?

https://support.apple.com/en-us/HT204899 , https://en.wikipedia.org/wiki/System_Integrity_Protection , https://derflounder.wordpress.com/2015/10/01/system-integrit...

So what Apple have designed is a "system integrity protection" system that actively prevents you from mitigating security issues.

Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".

Re: Remote code execution, git, and OS X

#97

So... to try and get an answer to the unanswered question in the blogpost. The files are probably hardlinks to a single "superbinary" image somewhere. The actual code is probably checking the value of argv[0] to dispatch to the actual git code (or whatever command name was invoked). The question is, why is Apple doing this? Is it some sort of diskspace saving scheme (to avoid duplicating common boilerplate code)? I s…

Nah, the binary doesn't actually contain git. It's just a stub (in /usr/bin) that locates Xcode on the system (in /Applications/Xcode.app by default but configurable) and execs the real git binary from there. See also:

https://developer.apple.com/library/mac/documentation/Darwin...

Re: Remote code execution, git, and OS X

#98
post #20

Earlier quoted context omitted.

> This is actually about blasting OS X for not having updated versions of software. No it's not, it's blasting OS X for shipping software with a known remote execution vulnerability, and not allowing the user to easily upgrade that software themselves due to new OS-wide security policies.

>and not allowing the user to easily upgrade that software themselves due to new OS-wide security policies. But the author didn't try that. They merely speculated that upgrading over top of that will almost certainly screw something up later. I upgraded the Subversion that's shipped with XCode 5 on OS X 10.9 (both old, I know) without any problems simply by manually replacing the files in /Applications/XCode.app/Cont…

Note however that on 10.9, the author would have just been able to do chmod -x /usr/bin/git and this wouldn't be a problem.

It's the 'System Integrity Protection' feature in conjunction with this version of git that the author has a problem with.

Re: Remote code execution, git, and OS X

#99

Not everyone has Xcode installed. For those of us who have only installed the Command Line Tools, you will find the Apple supplied git at /Library/Developer/CommandLineTools/usr/bin/git so the command to disable this vulnerable version is: sudo chmod -x /Library/Developer/CommandLineTools/usr/bin/git

I would recommend also installing an updated git through homebrew and using that instead.

The windows equivalent of homebrew (chocolatey) is great but has many out of date packages.

Re: Remote code execution, git, and OS X

#100

Not everyone has Xcode installed. For those of us who have only installed the Command Line Tools, you will find the Apple supplied git at /Library/Developer/CommandLineTools/usr/bin/git so the command to disable this vulnerable version is: sudo chmod -x /Library/Developer/CommandLineTools/usr/bin/git

I would recommend also installing an updated git through homebrew and using that instead.

[deleted]
Post reply on HN