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

321–330 of 385 posts

Re: Remote code execution, git, and OS X

#321

Post by joushou »

pdonis wrote: post #294
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…

> 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 Sure, but the fact remains that OS X deliberately hides things from you, and you have no way of knowing that you've found all the hidden things. And for a developer, I think that's unacc…

It doesn't hide anything related to git. The binary in /usr/bin is there to shat xcode-select works and points to /Application/Xcode.app/Contents/.../bin/git. It's not hidden, it's merely a convenience so that you can actually get git, and stay at least a little up to date. There's nothing hidden about it, and installing new, modifying your path, whatever is done just like you would on any other machine.

The binaries are protected by "rootless mode"/System Integrity Protection, but you can disable this and get full root access to your development machine. Just run "csrutil disable" from recovery mode (It wouldn't really help if you could disable it from a running system).

The only locked down things on OS X are proprietary GUI stuff, such as windowserver or some menubar API's. Regular operation is not locked down.

Re: Remote code execution, git, and OS X

#322

Post by chris_wot »

kuschku wrote: post #320
chris_wot wrote: post #184

Earlier quoted context omitted.

As someone who has also spent time in a mental institution, I just want to say that I really think you need to be less sensitive on this one. That's just an expression and not in any way aimed at people who have mental illness.

Accidentally downvoted you, I’m so sorry :/

All good :-)

Re: Remote code execution, git, and OS X

#323

Post by r3bl »

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…

I just checked my Ubuntu 14.04 and got this as an output:

    $ git --version
    git version 1.9.1
Unacceptable.

Re: Remote code execution, git, and OS X

#324

Post by pjmlp »

samirm wrote: post #311
falcolas wrote: post #270

Earlier quoted context omitted.

That still gives you Lisp, Ada, Go, Haskell, and Java, if you make the (imo incorrect) assumption that "low level" tools can only be written in languages which compile down to bytecode. Of course, Mercurial gives lie to this assumption.

Java? You won't get any performance out of it compared to something like C.

In what scale?

What it matters is if it is fast enough for the use case being targeted.

As side note I remember when C compilers for home computers generated worser code than junior Assembly programmers.

Re: Remote code execution, git, and OS X

#325

Post by fishywang »

joushou wrote: post #318
fishywang wrote: post #303

Earlier quoted context omitted.

Imagine that you are a corp IT and managing a fleet of developers with Macs. You can push a newer version of git to them, and you can even change their default PATH so that the version of git you pushed are before the git comes with Apple. But you still cannot remove the one comes with Apple, and you cannot prevent it from being used.

Well, you can, but it's inconvenient and requires manual intervention with each machine. I would argue, though, that if you have developers that intentionally circumvent the version of git you provided them with, despite being told that it's there for security reasons (and is newer, better, flashier and all), then you're dealing with people that can't be helped, and shit will happen regardless. I'm not arguing that i…

That might be unintended. For example some software might stupidly hardcoded /usr/bin/git instead of using the default one from PATH, or the PATH is actually quite tricky on Mac (bashrc controls what comes by default from bash, but the PATH in GUI is controlled by other files).

Re: Remote code execution, git, and OS X

#326

Post by jordigh »

fauigerzigerk wrote: post #310
jordigh wrote: post #301

Earlier quoted context omitted.

> I understand that, but it means that debian inevitably distributes buggy software in a supposedly 'stable' distribution. Bugs are a matter of perspective. If alleged bugfixes actually make you modify your currently working setup, then I don't consider that much of an actual bugfix, just something that makes me do work for no real benefit: http://stevelosh.com/blog/2012/04/volatile-software/ I like Debian stable. Tw…

Many people are unhappy about living with old bugs or missing features for years, even if you are not. And as a result we get a proliferation of many different update mechanisms on the same system. Some of them interactive and unscriptable. Some less than secure. This is not an ideal situation by any stretch. It's not a huge problem either as long as Linux is used almost exclusively by professionals and mostly on ser…

You know what people really hate? Change. Ask around how many people like it when Facebook changes its UI. Most don't. Sure, if there's a bug people hate living with the bug, but people really hate change even more.

Re: Remote code execution, git, and OS X

#327

Post by pjmlp »

ryandrake wrote: post #316
pjmlp wrote: post #264

Earlier quoted context omitted.

It is opt-in, because it depends on the STL, which many shops forbid. I have always been on the C++, in the C vs C++ wars, but I am also aware of all those developers that just code C with a C++ compiler, hence opt-in.

I'd hope people are not using the STL nowadays, in favor of the C++ Standard Library which is part of the C++ standard.

People like myself that know C++ since the "C++ Annotated Reference Manual" tend to keep using STL to designate the standard library, but I guess you already knew that.

If it makes you happy I can use the ANSI C++ section number instead.

Re: Remote code execution, git, and OS X

#328

Post by fauigerzigerk »

jordigh wrote: post #326
fauigerzigerk wrote: post #310

Earlier quoted context omitted.

Many people are unhappy about living with old bugs or missing features for years, even if you are not. And as a result we get a proliferation of many different update mechanisms on the same system. Some of them interactive and unscriptable. Some less than secure. This is not an ideal situation by any stretch. It's not a huge problem either as long as Linux is used almost exclusively by professionals and mostly on ser…

You know what people really hate? Change. Ask around how many people like it when Facebook changes its UI. Most don't. Sure, if there's a bug people hate living with the bug, but people really hate change even more.

I agree with you that this is a very strong sentiment. People don't want everything to change all the time underneath them, especially not the UI.

But freezing everything for years puts too many people in a situation where they just have to upgrade for one reason or another. It's not always their choice and it's rarely a desire for change that makes them do it.

Re: Remote code execution, git, and OS X

#329

Post by landr0id »

chris_wot wrote: post #196
anu_gupta wrote: post #189

Earlier quoted context omitted.

> Incidentally, calm down a bit - you sound pretty outraged yourself! This seems to be your pattern when you get upset. You've told someone else they were being defensive, now you're saying I need to calm down. I guess that's easier than rebooting a server and turning off SIP.

I'm more amused than upset. You seem rather steamed up there though... Now how about answering my actual question. What if I don't want to turn off SIP but I want to use dtruss to troubleshoot my system? If Apple truly doesn't want me to use dtruss, then why do they bundle it?

You can use dtruss, you just can't use it on certain binaries. A friend said that you can disable certain parts of SIP to enable functionality like this but I haven't tried myself.

Looks like this is the command:

    csrutil enable --without dtrace

Re: Remote code execution, git, and OS X

#330

Post by bsder »

blub wrote: post #261
falcolas wrote: post #252

Earlier quoted context omitted.

Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages. When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".

No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.

Git is not a "low-level" tool.

The fact that a Java rewrite of git actually exists demonstrates the falsity of this statement.

Post reply on HN