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

281–290 of 385 posts

Re: Remote code execution, git, and OS X

#281

Post by joushou »

satysin wrote: post #277
joushou wrote: post #240

Earlier quoted context omitted.

I'd like to point out, however, that installing a new version of git is not in any way blocked by either Microsoft or Apple. If you install git with homebrew, you get the newest version, which will take precedence over the Xcode variety unless you mess with your $PATH. Tricking you into using the old version would require execution rights on the machine. You can also remove the /usr/bin/* binaries if you boot the mac…

Does OS X have something like update-alternatives on Debian?

No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them.

I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be annoyingly outdated (Like bash 3.2.57, vs. 4.3.42 from homebrew).

Re: Remote code execution, git, and OS X

#282

Post by teacup50 »

pitkali wrote: post #217
chris_wot wrote: post #179

Earlier quoted context omitted.

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 w…

So what if there's a "sentiment against OS X"?

I've been using Macs for 30 years, including OS X since the 10.0 beta, and the recent changes have left me with a "sentiment against OS X" not unlike the "sentiment against Mac OS" that we had in the 90s when things went pear shaped.

There were people saying we shouldn't speak ill of System 7.5 back then, too.

OS X isn't a systemically marginalized group, it's a product that people are increasingly unhappy with. You may disagree as to why, or with the trade-offs involved, but we're not ignorant as you think we are; SIP likely isn't mentioned because it's obvious.

Re: Remote code execution, git, and OS X

#283

Post by satysin »

joushou wrote: post #281
satysin wrote: post #277

Earlier quoted context omitted.

Does OS X have something like update-alternatives on Debian?

No, the dev tool binaries are magic binaries that check if the "Command Line Tools" package is installed, and if not, asks you if you want to download it. They're protected by System Integrity Protection, so you have to temporarily boot with that disabled to remove or modify them. I think it's a fairly common measure to download a lot of what OS X comes with over homebrew, simply because OS X's versions tend to be an…

That sounds annoying.

Re: Remote code execution, git, and OS X

#284

Post by jordigh »

fauigerzigerk wrote: post #222
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…

The problem with this concept of "stability" is that it depends on a particular software development philosophy that isn't shared by all projects. It works well if developers make sure that bugs in older versions of their software are fixed even after the next version is released. I think that is the case with a lot of infrastructure sort of software. But if developers do not maintain old versions and fix bugs only b…

Debian's system does not require developers to maintain older versions, only to clearly indicate security fixes. Debian patches its own older versions to include the security fixes.

Re: Remote code execution, git, and OS X

#285

Post by Domenic_S »

zwarag wrote: post #203
matt4077 wrote: post #140

Earlier quoted context omitted.

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…

> Also: I'd hate if I had to fiddle around with kernel parameters to get printing, sleeping, networking, waking, font-displaying, account-switching, video-playing, time-knowing or up-backing to work every time canonical decides it's time for a new subsystem. I love linux on the server, but maintaining a function desktop system is simply a waste of time. A somewhat evil waste of productivity, actually, because it feel…

Long time Mac user here, I use awk & sed on a regular basis. Been familiar with $PATH since the DOS days and am equally comfortable SSH'd into a CentOS box as I am on the Mac.

I don't think I'm special here, but I'm for sure a subset of Mac users. My point is, seeing a Mac at someone's desk shouldn't make you assume they're idiots, just like you don't assume someone's a l33t-ub3r-h4ck3r if they're walking around with a lenovo.

Re: Remote code execution, git, and OS X

#287

Post by chris_wot »

raimue wrote: post #272
chris_wot wrote: post #269

Earlier quoted context omitted.

And if you do have them installed? What does it do then - invoke git?

Yes. It uses the tools from the location currently selected as the active developer directory (via xcode-select).

I guess that's better. You still can't kill the execute bit on the binary. But the way that Apple are doing things seems a bit of a ridiculous.

Re: Remote code execution, git, and OS X

#288

Post by dikaiosune »

blub wrote: post #188
lmm wrote: post #155

Earlier quoted context omitted.

If you're going to rewrite in any case surely it's worth going to Rust (or Ada, or another language that simply doesn't have the myriad unsafe possibilities that C++ does).

There are many arguments to be made in favor of C++, such as talent availability, experience from other porting projects, the possibility of doing incremental porting, etc. My impression is that some projects are already experimenting with or using C++ in their C code bases, so C to C++ is quite likely.

Incremental porting is possible in Rust. There are a few ways to go about it, and it is pretty easy to link Rust and C code together.

Re: Remote code execution, git, and OS X

#290

Post by hoke_t »

bertan wrote: post #141
dchest wrote: post #22

Earlier quoted context omitted.

Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.

Why not replace XCode with brew version entirely: sudo cp /Applications/Xcode.app/Contents/Developer/usr/bin/git /somewhere/to/backup/just/in/case sudo rm /Applications/Xcode.app/Contents/Developer/usr/bin/git sudo ln -s /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git

or just

   sudo cp /usr/local/bin/git /Applications/Xcode.app/Contents/Developer/usr/bin/git
Post reply on HN