Remote code execution, git, and OS X • Hacker News Board

Re: Remote code execution, git, and OS X

#81

Post by fauigerzigerk » Mon, Apr 18, 2016, 7:42 AM UTC

mjn wrote: post #70

fauigerzigerk wrote: post #67

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…

What if I want to decide for each individual package if it should get

(a) upgraded to the latest version

(b) upgraded to the latest version that the developer considers API compatible

(c) kept frozen

Is there a way to do that with the debian package management system?

Re: Remote code execution, git, and OS X

#82

Post by joelkesler » Mon, Apr 18, 2016, 7:44 AM UTC

yelnatz wrote: post #38

dchest wrote: post #34

Earlier quoted context omitted.

This is in the linked post. Do this to disable it: sudo chmod -x /Applications/Xcode.app/Contents/Developer/usr/bin/git

chmod: /Applications/Xcode.app/Contents/Developer/usr/bin/git: No such file or directory I don't have Xcode installed, do I have to install it back to do this?

If you do not have Xcode installed but do have the Command Line Tools, you will find the vulnerable git /Library/Developer/CommandLineTools/usr/bin/git

so the command would be:

  sudo chmod -x /Library/Developer/CommandLineTools/usr/bin/git

Re: Remote code execution, git, and OS X

#83

Post by joelkesler » Mon, Apr 18, 2016, 7:47 AM UTC

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

Re: Remote code execution, git, and OS X

#84

Post by joelkesler » Mon, Apr 18, 2016, 7:49 AM UTC

joelkesler wrote: post #83

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.

Re: Remote code execution, git, and OS X

#85

Post by bdash » Mon, Apr 18, 2016, 7:49 AM UTC

cyphar wrote: post #72

valleyer wrote: post #52

Earlier quoted context omitted.

You need to do that from the Recovery OS, by the way.

You can use an nvram command to do it from the main OS. nvram boot-args="rootless=0" EDIT: Actually, it looks like that no longer works. Dammit.

I believe that toggling a boot-arg only disabled SIP on early developer betas of OS X 10.11. For shipping releases of El Capitan you need to use csrutil from the recovery partition as a parent comment mentioned.

Re: Remote code execution, git, and OS X

#86

Post by yAnonymous » Mon, Apr 18, 2016, 7:55 AM UTC

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.

Re: Remote code execution, git, and OS X

#87

Post by StreamBright » Mon, Apr 18, 2016, 8:00 AM UTC

fniephaus wrote: post #80

Same problem is valid for Python. The subprocess module on El Capitan has a bug that has caused me a lot of trouble recently: http://bugs.python.org/issue26083#msg258011 You'll need to put an updated subprocess.py in your Python path, editing the one provided by OS X is prevented by the System Integrity Protection... ¯\_(ツ)_/¯

Are you not using virtualenv? I always use virtual environments as much as possible to avoid being locked in on an older version (for example Python in this case).

Re: Remote code execution, git, and OS X

#88

Post by benley » Mon, Apr 18, 2016, 8:00 AM UTC

fauigerzigerk wrote: post #81

mjn wrote: post #70

Earlier quoted context omitted.

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…

What if I want to decide for each individual package if it should get (a) upgraded to the latest version (b) upgraded to the latest version that the developer considers API compatible (c) kept frozen Is there a way to do that with the debian package management system?

Generally if you want to use only debian packages, the answer is "stop wanting that".

But, you can get a little closer if you run debian Stable and also include apt sources from testing and/or unstable, and do some clever things in /etc/apt/preferences to pin package priorities. It can get messy fast, though.

Re: Remote code execution, git, and OS X

#89

Post by benley » Mon, Apr 18, 2016, 8:02 AM UTC

yAnonymous wrote: post #86

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?

Re: Remote code execution, git, and OS X

#90

Post by lorenzhs » Mon, Apr 18, 2016, 8:02 AM UTC

fauigerzigerk wrote: post #81

mjn wrote: post #70

Earlier quoted context omitted.

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…

What if I want to decide for each individual package if it should get (a) upgraded to the latest version (b) upgraded to the latest version that the developer considers API compatible (c) kept frozen Is there a way to do that with the debian package management system?

Not completely, but there are ways to achieve this partially. You can add multiple sources (say, stable and unstable) and set the priorities so that by default, stable is preferred. Then you can choose to install certain packages from unstable. However, since these frequently depend on newer libraries (e.g. libc6), it's hard to pull this off without upgrading most fundamental libraries to the version from unstable. In that case, you might just as well run unstable.