Hacker News Reader

Comment by mike_hearn | Hacker News Reader

It's a bit odd that the response here is to patch every single XPC service individually. This feels like some kind of design issue in the sandbox itself. Why are so many XPC services that are clearly intended to be app private reachable from sandboxed apps?

View on HN

Yep, it is the most likely the compromise to retrofit this into macOS, without breaking everything in UNIX and NeXTSTEP land that has been ported into macOS.

On Windows land you have something similar, there is the WinRT sandbox, Win32 app sandbox, secure kernel, driver guard, and a miriad of other stuff, but there are also the cracks of backwards compatibility, specially if you want a single executable able to run across all those configurations.

Mobile OSes have it easier, because of no backwards compatibility and the restrictions that are able to impose as execution model.

XNU, or more specifically the Mach part of it, also had some very questionable design choices that likely compounds the issue as it forces people to work around it in increasingly awkward ways. As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.

> As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.

You may be thinking of Andrew S. Tanenbaum, who created MINIX, and was famously blasted by Linus for not having industry experience.

Mach was written by guys who ended leading Microsoft Reaearch and software development at Apple.

>was famously blasted by Linus for not having industry experience.

I answered my own question (where to read more about this), and found the relevant information from https://www.oreilly.com/openbook/opensources/book/appa.html

This is a fantastic read, thanks for linking it. Linus's pragmatic approach really comes to the fore.

> To put this discussion into perspective, when it occurred in 1992, [...] many companies that are household names today--Netscape, Yahoo, Excite--simply did not exist.

That sure has aged interestingly since 1999.

They did that later, but it is accurate to say that when Mach was first designed, Rick Rashid and others lacked "industry experience". However, they had a lot of practical experience making real systems for academic purposes. The CS departments at U of Rochester and CMU are serious about building stuff.

None of this has to do with the Mach part of XNU. There are genuine bugs there (everyone hates the memory code for example) but again that is completely irrelevant here.

How do you know Mach wasn’t the cause of some workaround in the 90s, and that 5 workarounds in a row later it becomes harder to resolve this issue in 2024?

Because I read the blog post.

So can you actually write the argument here?

That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…

No, I won't. Your request is unreasonable. You posted a claim that is not true. This bug has nothing to do with the Mach layer of XNU, and the blog post has enough detail to explain why. When I call you out on that, you don't get to retreat to an absurd position and ask me to substantiate it: there's probably six degrees of separation between what I ate for breakfast and these bugs shipping. This is something that is basically impossible to falsify, but also deeply uninteresting. So I am not going to entertain it for you.

Your opinions can’t ever outweigh my opinions, or any other HN user’s opinions for that matter, so this adds nothing to the conversation.

You can feel however you want about it but if you were to show up in a thread about GNOME security bugs and start talking about how Linux was designed by this random guy from Finland with no real experience which is why everything is so broken that’s really where people would stop taking you seriously.

Therefore…? Is there some other point your trying to prove?

You're missing the point. You made an unsubstantiated claim, and then you demanded an argument that it's impossible for your unsubstantiated claim to be true. I agree with the reply that this is a totally unreasonable demand.

The burden of proof is on you to provide evidence for your unsubstantiated claim. The burden is not on everyone else to disprove it.

It doesn’t matter who anyone believes the burden falls on… that’s my point.

Edit: If there’s no desire to write anything, there’s no force chaining your hands to the keyboard… and even if there was, no other user is obligated to do this or that.

> I’m not requesting anyone to reply to me nor prove anything to me

I mean... everyone can see that this claim is false. Earlier:

> So can you actually write the argument here?

> That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…

That was a request for a reply and a proof.

Of course nobody has to accede to your request, but it's undeniable that you made a request.

Huh it does sound like that in retrospect, so I edited the comment to remove the offending sentence.

At the time of writing it was meant to be a rhetorical question, since it seemed extremely unlikely for there to have been any such argument or implication in the blog post referenced.

But my point still stands, it simply doesn’t matter because HN users can’t place any kind of mandatory obligations on one another.

Not true: opinions carry the weight of their underlying reasons. Not all opinions are equally supported.

The underlying reasons have to actually be written out though in the first place and viewable on a screen… I’m not a telepath, nor likely is anyone else.

And after all that has been demonstrated, along with some other necessary features such as logical consistency and so on, then it’s definitely more than an opinon.

Really? I remember Bertrand Serlet or maybe it was Avie himself, taking pride in that.

I think both of them left before XPC shipped.

> On Windows land you have something similar

I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.

Visicalc doesn't run on recent versions of Windows without emulation.

I guess it is a form of emulation... but

You can run 16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows with https://github.com/otya128/winevdm

I got Microsoft Encarta 98 to work on Windows 11 this way

Encarta 98 has to be 32 bit... Win16 was pretty dead for new products by that time.

Though it's conceivable that an installer could start off with 16 bit code to show an error message that you need Windows 95 ...

Edit: it seems Encarta 95 could run on win16, but Encarta 98 required win95 or nt4

Windows has far worse. Injecting code into other processes is routine and almost impossible to get rid of.

I've never heard of that from store apps

The store which doesn't even provide one of the most useful Microsoft product (Visual Studio)?

Yeah. That really doesn’t need to be from the store.

I really hate going through the Apple Store to download Xcode. We all know how to download software. I’d rather go through a dev portal than a consumer portal.

YMMV

Xcode can be downloaded from developer.apple.com too, it's not an App Store exclusive.

Command line: https://github.com/XcodesOrg/xcodes

GUI: https://github.com/XcodesOrg/XcodesApp

> I’d rather go through a dev portal than a consumer portal.

You actually can, alongside with conmand line tools, additional xcode utils, debug kernels et cetera.

Readers here are all very likely to appreciate some links alongside statements, cause really this is a sensitive topic. Both statements need certain context as it seems it’s not the universal understanding of what goes on and how often.

SetWindowsHookEx is a blast.

Not sure it can be proven with citations but it's well known that process injection is widely used on Windows. GPU drivers are known to do it. Utilities have historically often injected code into Explorer. Raymond Chen has written in the past about this problem and how hard it made it to evolve the platform.

> Raymond Chen has written in the past about this problem

That would be a citation. Do you have a link?

You install tortoiseSVN or something similar, look at explorer.exe process or any process that use a standard "Open File" widget, and you will see some dll from the utility loaded by the process. (Easy to see with process explorer from sysinternals)

I think tortoiseSVN and consorts are "just" a shell extension, though, which is an officially supported concept, even if that means that potentially any random software using the standard file dialogues ends up loading your DLL, too.

Three random Explorer examples:

https://devblogs.microsoft.com/oldnewthing/20230911-00/?p=10...

https://devblogs.microsoft.com/oldnewthing/20230324-00/?p=10...

https://devblogs.microsoft.com/oldnewthing/20220613-00/?p=10...

For code injection into applications that don't load third-party DLLs as plugins, see, e.g., Microsoft's (unsupported) toolkit for runtime API interception:

https://github.com/microsoft/Detours

No, it has nothing in to do with NeXTSTEP. XPC was designed recently and for macOS/iOS. This is just that it was not designed with security in mind along this axis.

That is the thing, the OS architecture wasn't revamped across the board, XPC became another little island how to do IPC.

It's definitely a big island on Darwin

XPC has been in shipping platforms for more than 13 years... I suppose that is recent compared to NEXTstep :)

Reply on news.ycombinator.com