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

191–200 of 385 posts

Re: Remote code execution, git, and OS X

#191

Post by userbinator »

chris_wot wrote: post #182
userbinator wrote: post #167

Earlier quoted context omitted.

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

In other words: if you want to live in a walled garden with lots of holes, then use SIP. Good to know.

Only Apple-approved holes.

Re: Remote code execution, git, and OS X

#192

Post by lmm »

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.

My impression is that projects that mix C and C++ tend to use the C-like subset of C++ (with classes), so they wouldn't gain any safety advantage from moving to C++.

Many other languages support C linkage in a way that's comparable to C++.

Re: Remote code execution, git, and OS X

#193

Post by joushou »

blub wrote: post #190
joushou wrote: post #149

Earlier quoted context omitted.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

Yes it would, because this is basically string processing where C is the worst possible language one could use. I've detailed in another comment how std::string could be used.

You're talking about naked char[]. You can just as easily make a struct{ int len; char* str; } in C, and combined with the "n" variants of string operations, would work just fine with common tools.

Again, C++ does not make anything safer, and its types can easily be replicated in any other language.

Re: Remote code execution, git, and OS X

#194

Post by zamalek »

chris_wot wrote: post #139
comex wrote: post #133

Earlier quoted context omitted.

Perhaps they should. But then again, a large percentage of Linux users use distros that lag even further behind (albeit arguably with a better security fix backporting process)... stability is valuable too.

I'm not sure about this. Anyone who wants to use a decent Linux distro will get fairly frequent updates - Fedora, Debian, SuSE, Ubuntu and even Slackware get frequent updates and Fedora, Debian and SuSE are well known for backporting security fixes. Apple are known to be tardy in taking their time to release security fixes unfortunately. This whole point might be mitigated if they were more responsive, but they aren'…

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.

Re: Remote code execution, git, and OS X

#196

Post by chris_wot »

anu_gupta wrote: post #189
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…

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

Re: Remote code execution, git, and OS X

#197

Post by discreditable »

userbinator wrote: post #153
atdt wrote: post #78

Earlier quoted context omitted.

The problem is that System Integrity protection was put in place for my benefit and marketed to me as a feature that had been "designed to help prevent potentially malicious software from modifying protected files and folders on [my] Mac", and now that I have it and paid money for it (or the Apple hardware it runs on), I find out that it is making me less secure by preventing me from removing a software component whi…

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.

The core issue is that the system is vulnerable in its default configuration.

Re: Remote code execution, git, and OS X

#198

Post by NoGravitas »

blub wrote: post #190
joushou wrote: post #149

Earlier quoted context omitted.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

Yes it would, because this is basically string processing where C is the worst possible language one could use. I've detailed in another comment how std::string could be used.

You could stay in C and use glib strings.

Re: Remote code execution, git, and OS X

#199

Post by claudius »

joushou wrote: post #149
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.

A rewrite in C++ would not make it any safer. Rewriting it to make it easier to understand could make it safer, but you do not need a different language for that.

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/Haskell…

Something like:

std::string path_name(std::vector const& dirs, std::string const& name) { std::string p; for(auto const& dir : dirs) { p += (dirs + "/"); } p += name; return p; }

should work. If you feel like it, you can also add something like:

  std::size_t len = name.size();
  for(auto const& dir : dirs) { len += dir.size(); }
  p.reserve(len);
Of course, len may overflow, but even if it does, all the harm that causes is that the string will have to reallocate memory during growth until running in a segfault when further memory allocation fails.

Re: Remote code execution, git, and OS X

#200

Post by chris_wot »

zamalek wrote: post #194
chris_wot wrote: post #139

Earlier quoted context omitted.

I'm not sure about this. Anyone who wants to use a decent Linux distro will get fairly frequent updates - Fedora, Debian, SuSE, Ubuntu and even Slackware get frequent updates and Fedora, Debian and SuSE are well known for backporting security fixes. Apple are known to be tardy in taking their time to release security fixes unfortunately. This whole point might be mitigated if they were more responsive, but they aren'…

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 thing from occuring - what will stop it is not allowing users to run as admins by default, which OS X is doing already.

At which point, the way malware will get installed is via software vulnerabilities, in things like git. It won't be occurring because Apple stopped me from turning off the execute flag on potentially vulnerable programs like the git that they install by default.

Post reply on HN