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

211–220 of 385 posts

Re: Remote code execution, git, and OS X

#211

Post by chris_wot »

joelkesler wrote: post #84
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.

I'm still trying to understand why Apple install XCode command line utilities into an area of the system that is protected by SIP.

There is nothing hugely special about their tools - every other app apparently has to install into a different location as best practice, so I don't understand why Apple don't follow their own guidelines!

Re: Remote code execution, git, and OS X

#212

Post by zamalek »

chris_wot wrote: post #200
zamalek wrote: post #194

Earlier quoted context omitted.

Windows is still targeted far more than Mac, it could be argued that the lack of impetus originates from this phenomenon. I'm worried about when (not "if") this changes, people are snapping up Macs all around me and thusly the platform won't be protected from worms due to" hacker disinterest" forever.

Windows has UAC that does something similar, and the Windows\System32 directory can't be written to by an ordinary user. The malware I see doesn't install in this directory, but in Program Files - and they can't really lock this down. The way that folks get themselves into a mess and get malware installed are largely via programs with network access. Locking down the /usr directory isn't going to prevent this sort of…

> the Windows\System32 directory can't be written to by an ordinary user.

You need to be able take claim ownership from TrustedInstaller, so administrators only: yes (you'll need to acquire a UAC token, but the GUI prompts you automatically). You'll also need to turn off installation integrity to prevent Windows from replacing the file. All documented. It isn't obfuscated in any way whatsoever and I figured it out first time in 2 minutes with no Google.

Security through obfuscation is known to be a broken concept.

Re: Remote code execution, git, and OS X

#213

Post by chris_wot »

acdha wrote: post #208
chris_wot wrote: post #125

Earlier quoted context omitted.

Wow, my innocent question seems to have pissed off a few people! Anyway, so only system updates can update the OS X system? Which involves a system reboot? How does the "system protected" software get updated? But not making it easy to update flawed software sounds like a great vector for malware.

They didn't change the user experience in any way - most updates do not require a reboot, the ones which do are fast - so I'm guessing that the kernel checks the code signature on the process doing the write when deciding what to block and possibly even requires a valid Apple signature on the new file.

Yeah, it's looking increasingly that way.

I'd still love to know their thinking behind put git into a directory that SIP makes deliberately hard to update! I mean, git is additional software and not even part of their base operating system, my understanding about SIP was that it was meant to prevent people from tampering with the underlying system software and installing rootkits.

git (and ssh for that matter) aren't going cause rootkits by themselves - and all they are doing is forcing people to use homebrew to install versions that's aren't protected by SIP!

Re: Remote code execution, git, and OS X

#214

Post by acdha »

mattbillenstein wrote: post #64

Did they also have a problem with that bash shellshock vuln years ago? I remember OSX running a really old version of bash at one time.

That's a somewhat more complicated issue: they're shipping the last version of bash using GPL v2. Upgrading would be a significant legal question and I'd be surprised if the long run outcome wasn't removing bash.

Re: Remote code execution, git, and OS X

#215

Post by Manishearth »

acdha wrote: post #209
Manishearth wrote: post #205

Earlier quoted context omitted.

We use a mac server as a build machine. It's pretty annoying; given that you need to graphically log in to accept a license every now and then to use lldb (a non-graphical debugger) among other things. In our case I think rebooting the server works, but you can't be aware of all usecases.

Try: sudo xcodebuild -license

Ooh, thanks!

Re: Remote code execution, git, and OS X

#216

Post by Fuxy »

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…

While I agree with canonical being a pain the answer to that is simple just don't user Ubuntu.

I prefer Mint if I need a Ubuntu fork that's quite stable and has most things already configured generally used at work and as my personal desktop I use Arch mostly because compatibility with the hardware required the latest kernel at the time.

I like playing with the latest features and not having to install the OS every other year because some major update from canonical broke everything.

As far as fiddling with the kernel I never had to do anything like that to get the things you mentioned working the most I had to do is install some software and configure it correctly.

In the years I've been running Arch on the desktop it only breaks on average about 2 or 3 times a year which is quite decent considering it's a rolling release and I haven't had any major issues with mint since I started using it about 2-3 years ago.

I crashed the window manager a few times but that's about it in comparison Unity used to crash on me constantly and the entire experience of using plain Ubuntu as a desktop was awful so I understand why you would be against using it if that is all you knew of Linux as a desktop.

Re: Remote code execution, git, and OS X

#217

Post by pitkali »

chris_wot wrote: post #179
developer2 wrote: post #172

Earlier quoted context omitted.

I didn't get a negative vibe from the opening paragraph on its own. If you read the rest of the post, you find a lot of unnecessary negativity regarding the entire Apple ecosystem. >> I know, I'll just strace it to see what it execs! Oh wait, this isn't Linux. Uh, I'll dtruss it to see what it execs! Someone who is not in the process of bashing as much as possible would have simply said something like "I'll dtruss it…

All that first sentence points out is that Rachel was more familiar with Linux than OS X, and mistakenly thought that strace would be on the system, and then reverted to using dtruss. She's just showing her process for trying to troubleshoot Unix processes to see what is going on under the hood, in a conversational tone. As for the "If you rely on machines like this, I am truly sorry" - I don't really blame her. She…

The sentiment against OS X might not show that strong, but it is clearly there. She doesn't even mention that what protects /usr/bin is System Integrity Protection, or that it can be disabled. The very idea that people might not be using system git is not even mentioned.

All in all, it really feels as if it was written from the perspective of someone that does not usually work with OS X and does not know the system well. In other words, she has not done her homework. Which is fine, if you acknowledge what you don't know. But then the condescending tone would be totally out of place.

The sentiment is there, and it does not help in spreading the message, unless what you really want is to flare up all the emotions. Otherwise, it's not the best course of action.

Fun fact, since we're comparing default system installations, my Ubuntu apparently still has git 2.5.0. I suppose I should find some PPA or something to update it.

Re: Remote code execution, git, and OS X

#218

Post by amake »

chris_wot wrote: post #211
joelkesler wrote: post #84

Earlier quoted context omitted.

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

I'm still trying to understand why Apple install XCode command line utilities into an area of the system that is protected by SIP. There is nothing hugely special about their tools - every other app apparently has to install into a different location as best practice, so I don't understand why Apple don't follow their own guidelines!

> I'm still trying to understand why Apple install XCode command line utilities into an area of the system that is protected by SIP.

They don't. Plenty of comments explain where the Xcode git actually is.

Re: Remote code execution, git, and OS X

#219

Post by zymhan »

OJFord wrote: post #170

> 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.

This doesn't prevent someone from writing "/usr/bin/git/" into their OS X exploit.
Post reply on HN