Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution, git, and OS X

rachelbythebay.com

Post reply on HN
Print view View original

161–170 of 385 posts

Re: Remote code execution, git, and OS X

#161

Post by lmm »

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?

You can override per-package, yes, if you really want to, and you can pin versions for C. As others have said, in practice a newer version of one package often depends on a newer version of another (the system will generally stop you rather than blindly installing incompatible things), and obviously you'll miss out on the testing of an integrated system that's the selling point of debian stable, but you can do it.

Re: Remote code execution, git, and OS X

#162

Post by chris_wot »

lmm wrote: post #158
chris_wot wrote: post #148

Earlier quoted context omitted.

You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway. https://github.com/gdbinit/rootfool Incidentally, calm down a bit - you sound pretty outraged yourself! You m…

> Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software. I can imagine git might be necessary for a…

In that case, then git is a vector through which SIP can be bypassed. But it's not used to apply updates as it's part of XCode command line utilities and not the core system.

Re: Remote code execution, git, and OS X

#164

Post by efdee »

matt4077 wrote: post #140
Fuxy wrote: post #110

Earlier quoted context omitted.

It's times like this that prove I made the right choice sticking to Linux. There's nothing I hate more than the inability to fix things that are broken on my system or the fact that I would have to jump trough a lot of unnecessary hoops to do it. The few small advantages are just not worth it in the end for me.

There really isn't a hoop tp jump through... Everyone uses homebrew, which happens to work extremely well (to the point where it's apparently being ported to linux now – go figure). With the homebrew git installed, the stars really have to align for that vulnerability to be exploited. You can possibly get a user to clone from your repository. But if you can also get him to use the git version you want, we're at the p…

Claiming this isn't a hoop to jump through is Apple fanboyism at its best.

Re: Remote code execution, git, and OS X

#165

Post by vertex-four »

matt4077 wrote: post #152
eyko wrote: post #145

Earlier quoted context omitted.

The stars don't really have to be aligned: any script could invoke system git directly.

Yeah, but a script that intentionally invokes /usr/bin/git has already achieved the non-privileged access the git vulnerability could provide. A script that unintentionally invokes (i. e. not to exploit) would then need to be combined with a malicious repository, which may be tricky. But I don't want to dismiss this vulnerability – it's so easy to fix on Apple's part that they don't have an excuse. There are a few to…

> Yeah, but a script that intentionally invokes /usr/bin/git has already achieved the non-privileged access the git vulnerability could provide.

Or, in Old New Thing terms, "it rather involved being on the other side of this airtight hatchway".

https://blogs.msdn.microsoft.com/oldnewthing/20140529-00/?p=...

Re: Remote code execution, git, and OS X

#167

Post by userbinator »

chris_wot wrote: post #157
userbinator wrote: post #153

Earlier quoted context omitted.

Disable it, reboot, fix the problem, reboot again with it enabled. Big f'ing deal. I'm far from a fan of Apple's protectionism, and yet this doesn't seem like anything to be up in arms about.

Sometimes I think that Apple are increasingly trying to lock down OS X to prevent anything from being installed outside of its own walled garden. The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature…

The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature that is preventing the security vulnerability from being fixed.

I understood the point perfectly well, and that's why I think it's a bit overblown. This security feature is precisely designed to prevent you from modifying your system and encourage you to defer that to Apple. It should be obvious that such a feature will also prevent you from fixing things yourself, which Apple either hasn't gotten around to fixing or refuses to. But since they give you some way of disabling it, you just do that and fix it yourself (and presumably SIP will then protect your fixed version of git?)

Re: Remote code execution, git, and OS X

#168

Post by rndstr »

scottydelta wrote: post #130
jnardiello wrote: post #18

I might be wrong here, but using brew will NOT remove git shipped with xcode, so you are still vulnerable.

yes, that is why you set path variable in your bash_profile so that when you do 'which git', you are not pointed to /usr/bin/git but /usr/local/bin/git. you might also want to do sudo chmod a-x to /usr/bin/git.

What about scripts that explicitly call /usr/bin/git?

Re: Remote code execution, git, and OS X

#169

Post by trywerwerwer »

userbinator wrote: post #160
blub wrote: post #103

Earlier quoted context omitted.

I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better. A lot of Linux C utilities would benefit from such a treatment.

Rewriting in any language won't help with this one unless the language has builtin integer overflow checking. The solution here is actually quite trivial: just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.

> just restrict filenames to 255 bytes and nesting to 255 levels, which limits paths to 64KB at most. Anyone trying to use git repositories exceeding either of those limits should be considered insane.

Funny, because I've actually been locked up for being insane five times. Speaking from experience, they'd only consider me insane if I said something like 255 was an important number because there are two sides to every problem and five fingers on each hand, and the path, which two feet take, is six one way / half a dozen the other, to the four corners of the earth, which is the natural limit.

So... you don't really know what insane is. Jus' sayin'.

Re: Remote code execution, git, and OS X

#170

Post by OJFord » 

    > They are basically screwed until Apple deigns to
    > deliver a patched git unto them
Actually, no. Don't use the tools that come pre-installed.

All you have to do* is:

    brew install git
*and make sure that brew installs are prioritised in your $PATH. Which you should do anyway.
Post reply on HN