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

361–370 of 385 posts

Re: Remote code execution, git, and OS X

#361

Post by fjarlq »

mitchty wrote: post #340
fjarlq wrote: post #245

Earlier quoted context omitted.

But that merely enumerates pathnames that contain the word "git", not programs that might still invoke the vulnerable version of git directly via "/usr/bin/git".

So then give find a proper predicate: $ find /usr -name git -type f -xdev -exec {} -v \;

No... tadfisher's point was that even if a fixed version of git is installed, some other program -- say, a wrapper script for git -- might still invoke OS X's vulnerable version if it directly references "/usr/bin/git". So, such a system could become compromised if that wrapper script was used to access an untrustworthy repo.

All your invocation of find does is enumerate every file (or directory) under /usr named "git" and execute it with the -v option. In addition to dumping a lot of error messages, all that would do is eventually run "/usr/bin/git -v" and inform you that yep, your system still has the vulnerable version of git installed.

In other words, tadfisher's point, which I now wish had been made explicitly, is that simply installing the fixed version of git is possibly insufficient to secure your system. You also ought to either disable /usr/bin/git or convince yourself that no program will invoke it. Disabling /usr/bin/git is probably easier.

Re: Remote code execution, git, and OS X

#362

Post by joushou »

pdonis wrote: post #358
joushou wrote: post #315

Earlier quoted context omitted.

> You have the user's execution rights only; you don't have root access. That is also what I said - code execution. Like the git RCE gives you. But, it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? With .bashrc, it doesn't matter how new your git is, there's no reason to exploit it. Also, privilege escalation bugs. > This is true of any program the user…

> code execution Code execution how? How are you going to execute code on my machine if you don't have physical access to it? That's why the RCE makes a difference. > it would be rather redundant to use code execution as a local user to obtain code execution as a local user, no? As I understood the comment that started this subthread, it was talking about using a remote code execution vulnerability to modify .bashrc.…

The original comment was about circumventing a users measure to use a new git from homebrew by having the bad guy modify .bashrc. If the bad guy has that ability, he does not need an RCE. My argument being that using homebrew to install a nee git is fine. The counterarguments being "evil applications" and "evil .bashrc", ehich already means that you're executing the bad guys code.

Re: Remote code execution, git, and OS X

#363

Post by joushou »

pdonis wrote: post #357
Sidnicious wrote: post #336

Earlier quoted context omitted.

It's interesting, lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer (Apple or some Linux distro's community). I configure my package managers (brew, pip, gem…) to install to my home directory and set up my PATH accordingly. This way, I don't have to worry at all about the state of my OS (e.g. whether an upgrade will damage some customizat…

> lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer As an ordinary user, this can be perfectly reasonable. I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user. Developers need a level of control over their machines and configurations that ordinar…

As a developer, and occasionally of the kernel variant, I also prefer to keep the OS stock. It's convenient, and allows for very speedy reinstalls. It also makes my environment identical across operating systems.

Having control does not mean you have to change anything. Also, most developers are regular users.

Re: Remote code execution, git, and OS X

#364

Post by zamalek »

chris_wot wrote: post #235
zamalek wrote: post #212

Earlier quoted context omitted.

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

Yep, I know. What you are basically saying is that you need to turn off some settings and security mechanisms to bypass the integrity of the system. Which is precisely what most folks are doing on OS X - except they have to reboot their system, which I personally find insane. But given this, I don't see the point you are making. Isn't this security through obfuscation precisely what Apple are doing right now?

I think we may be arguing the same point.

Re: Remote code execution, git, and OS X

#365

Post by Sidnicious »

pdonis wrote: post #357
Sidnicious wrote: post #336

Earlier quoted context omitted.

It's interesting, lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer (Apple or some Linux distro's community). I configure my package managers (brew, pip, gem…) to install to my home directory and set up my PATH accordingly. This way, I don't have to worry at all about the state of my OS (e.g. whether an upgrade will damage some customizat…

> lately I've been changing my view on this and looking at everything outside of my home directory as the realm of my OS maintainer As an ordinary user, this can be perfectly reasonable. I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user. Developers need a level of control over their machines and configurations that ordinar…

> I specifically said "as a developer" to make clear that my requirements in this respect are not necessarily the same as those of an ordinary user.

I was speaking as a developer, too. What kinds of things do you count as needing "that level of control"?

The things installed in my home directory include my text editor, clang and gcc, installations of Go, Node, and multiple versions of Python, etc.

Re: Remote code execution, git, and OS X

#366

Post by claudius »

joushou wrote: post #343
claudius wrote: post #199

Earlier quoted context omitted.

If you can change the name_path struct to a standard STL data structure (std::vector might work just fine), you can easily rewrite the function such that all memory allocation and all exploitable memory access is delegated to STL containers. If your STL std::string has a buffer overflow issue, you’re of course still in trouble, but the same is true if there are bugs in the STL/implementation of Go/Rust/Python/Java/Ha…

Right, and you can do the same with C, using libraries providing this functionality wrapped as well. There's plenty of std::string and std::vector like containers, which handle the magic for you. But even then, you can work with struct {len int; void* data;} to get your vector, and replace void* with char* to get a string. A simple vector and simple string is in no way difficult to implement, and many implementations…

The difference is that using STL containers such as std::string or std::vector are very much the default in C++ (much the same way ‘safe’ code is the default in Rust), whereas you have to do some manual work in C to get them. The result is that using std::string and std::vector here is the natural solution in C++, whereas likely very experienced C programmers stuck to the manual approach.

Re: Remote code execution, git, and OS X

#367

Post by pritambaral »

satysin wrote: post #353
joushou wrote: post #352

Earlier quoted context omitted.

Hah, and that might not even take that long at the current rate! But we still got a better terminal emulator by default over here! Terminal.app is a pretty darn good terminal emulator, although iTerm2.app is better. That is actually one of the things I like about OS X - I have not found a terminal emulator for Linux (and certainly not for Windows) that compares with iTerm2. Not in speed, nor in interface.

I am pretty sure we will see a better terminal come out thanks to this new Linux sub-system or whatever they decide to call it.

WSL is only a CLI layer. The GUI is still cmd.exe.

Re: Remote code execution, git, and OS X

#368

Post by pritambaral »

r3bl wrote: post #323
pitkali wrote: post #217

Earlier quoted context omitted.

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.

14.04 is an LTS release, which is, by definition, stable. 2.8.0 (latest, what I'm running) is vastly different from 1.9.1.

Stability is not the same thing as insecurity. As long as a stable release is supported, the maintainer promises to keep it secure. If your version of git had that vulnerability, Ubuntu would have backported the patches/fixes and made it available to you.

The version number 1.9.1 is a release identifier, not a security status identifier.

Re: Remote code execution, git, and OS X

#369

Post by gpvos »

matt4077 wrote: post #144
gpvos wrote: post #124

Earlier quoted context omitted.

Can you inunstall XCode again once you have installed a compiler, toolchain, and git via Homebrew?

You can just install the command line tools without xcode. From those tools, most can be replaced with their homebrew versions so you only need them for bootstrapping. But if you want to do hardware- or OS X related development, you will need to keep the tools around. CUDA, for example, needs clang et. all. They don't take much space, though, and the toolchain is treated a bit better by Apple than utilities like git,…

I don't know about homebrew, but macports has clang and other toolchain stuff, so I think it might be possible to uninstall Xcode after installing all necessary tools through macports?

Re: Remote code execution, git, and OS X

#370

Post by OJFord »

raimue wrote: post #175
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.

Then you will get caught by some GUI that uses /usr/bin/git. Be aware changes to PATH in your shell startup files do not affect graphical applications at all. Just installing git from Homebrew or MacPorts is not enough to be safe from this remote code execution.

Does it come pre-installed? I thought it came only with XCode Command-Line Tools. Which personally I don't have (anything I use is from Homebrew).

If it is there without XCLT, then anyone reading this is more than capable of removing it, and dealing with anything that subsequently can't find it.

Post reply on HN