[HN Gopher] Multiple new macOS sandbox escape vulnerabilities
___________________________________________________________________
Multiple new macOS sandbox escape vulnerabilities
Author : transpute
Score : 424 points
Date : 2024-11-08 06:10 UTC (16 hours ago)
(HTM) web link (jhftss.github.io)
(TXT) w3m dump (jhftss.github.io)
| mike_hearn wrote:
| 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?
| pjmlp wrote:
| 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.
| MichaelZuo wrote:
| 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.
| senko wrote:
| > 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.
| ziddoap wrote:
| > _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://ww
| w.oreilly.com/openbook/opensources/book/appa.html
| abraae wrote:
| This is a fantastic read, thanks for linking it. Linus's
| pragmatic approach really comes to the fore.
| jchw wrote:
| > 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.
| wrs wrote:
| 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.
| saagarjha wrote:
| 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.
| MichaelZuo wrote:
| 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?
| saagarjha wrote:
| Because I read the blog post.
| MichaelZuo wrote:
| 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...
| 98codes wrote:
| > On Windows land you have something similar
|
| I'm still waiting to hear about a kernel-level exploit that
| starts with Visicalc or similar.
| Narishma wrote:
| Visicalc doesn't run on recent versions of Windows without
| emulation.
| greenavocado wrote:
| 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
| asveikau wrote:
| 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
| saagarjha wrote:
| Windows has far worse. Injecting code into other processes
| is routine and almost impossible to get rid of.
| saagarjha wrote:
| 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.
| boesboes wrote:
| Nice work. I wonder whether we are on the right track with such
| architectures though. It seems with every security framework
| envisioned to combat some set of attacks, a whole new class of
| issues pop up. And I don't _feel_ like things are more secure in
| the end. A bit like dutch tax law, it is just a stack of patches
| to fix exploits and it might have achieved consciousness already!
| ;)
| pjmlp wrote:
| Because many of these systems aren't designed end to end to be
| properly secure.
|
| The right way to do it usually fails the market due to
| backwards compatibility or developer pushback to adopt such
| features (see WinRT sandbox).
|
| Mobile phones security has it easier, because there wasn't
| backwards compatibility to care about, and so far the stores
| gatekeeping means that developers that want to play there have
| to oblige anyway.
| freedomben wrote:
| > developers that want to _play_ there
|
| That pun was superb btw
| Y_Y wrote:
| Funny that you should mention Dutch tax law. I don't think it's
| controversial to say that some of those "exploits" were
| deliberately inserted. One may speculate that there are also
| some powerful forces pushing for more vulnerabilities in
| consumer computing.
|
| Here are high-profile examples of each:
|
| https://en.wikipedia.org/wiki/Dutch_Sandwich
|
| https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...
| rustcleaner wrote:
| Barium-class downboats appear to be sinking your battleship!
| :^O
| saagarjha wrote:
| Think again.
| gxt wrote:
| Ultimately security is incompatible with backwards
| compatibility. All OSes in prod today need to be rebuilt from
| the ground up to be secure for the next century. That means
| throwing out a lot of code too. It's the cost to pay.
| fsflover wrote:
| > All OSes in prod today need to be rebuilt from the ground
| up to be secure for the next century
|
| Qubes OS solves this with hardware virtualization, which is
| really fast and secure.
| PhilipRoman wrote:
| Compartmentalization is only a part of the solution. Once
| you have that finished, you still need to deal with the
| actual vulnerabilities in guests, which will contain your
| secrets and be exposed to the internet, one way or another.
| fsflover wrote:
| Guests don't have to be exposed to the Internet [0] or
| even run full OSes [1].
|
| [0] https://www.qubes-os.org/doc/how-to-organize-your-
| qubes/
|
| [1] https://www.qubes-os.org/doc/templates/minimal/
| ylk wrote:
| In what way are [1] not "full OSes"? They're minimal
| templates, but afaik they still run systemd, the kernel,
| etc. needed to boot the standard Linux systems they are.
|
| When I clicked the link I was expecting something like a
| unikernel, eg
| https://roscidus.com/blog/blog/2016/01/01/a-unikernel-
| firewa...
| fsflover wrote:
| You certainly can run distros without systemd [0] or
| something very different like *BSD or Mirage [2].
|
| [0] https://forum.qubes-os.org/t/devuan-or-other-non-
| systemd-tem...
|
| https://forum.qubes-os.org/t/alpine-linux-template-non-
| offic...
|
| [1] https://forum.qubes-os.org/t/openbsd-as-a-ubes-os-
| component/...
|
| [2] https://forum.qubes-os.org/t/mirage-
| firewall-0-9-0-released/...
| ylk wrote:
| > You certainly can run distros without systemd
|
| Does it then become not a full OS anymore? Mirage is what
| I linked to above.
| fsflover wrote:
| > Does it then become not a full OS anymore?
|
| Probably not. I mentioned it, because you mentioned
| systemd. And yes, I saw your Mirage link and showed how
| you can use it on Qubes.
| paulryanrogers wrote:
| Qubes is nigh impossible for normal users, even if setup
| for them. They need extension training and discipline.
| fsflover wrote:
| If you set it up, users can run anything themselves. Just
| use the start menu and the apps will automatically run in
| the corresponding VMs (shown as windows with colored
| borders).
| yadaeno wrote:
| Anything, except for practical applications that people
| actually use.
|
| * music production software * discord * games * copy and
| pasting
| fsflover wrote:
| Everything that works on Linux will generally work on
| Qubes, apart from the GPU-heavy applications [0], which
| will be addressed in the future [1]. Copying and pasting
| works fine [2]. OK, music production may not be possible
| at the moment [3].
|
| [0] https://www.qubes-os.org/faq/#can-i-run-applications-
| like-ga...
|
| [1] https://github.com/QubesOS/qubes-issues/issues/8552
|
| [2] https://www.qubes-os.org/doc/how-to-copy-and-paste-
| text/
|
| [3] https://forum.qubes-os.org/t/question-quality-of-
| external-us...
| rustcleaner wrote:
| I run LM-Studio and [can run] Siemens PLM NX inside a
| Windows Server qube. GPU passthrough is no issue for me
| at least.
| rustcleaner wrote:
| Can't comment on music production since I don't produce
| music (could be the need for realtime).
|
| Discord runs fine both in-browser and in application.
| Raptor Lake seems to have zero issue with video voice
| chat, whereas Comet Lake can drag a bit in large rooms
| without a GPU. Qubes OS makes it dirt easy to
| multiprofile from all around the world.
|
| I don't really game like others do; eye candy doesn't
| draw me in, but solving interesting puzzles/challenges
| does.
|
| Copy & paste is superior in Qubes, skill issue sorry not-
| sorry. GIT GUD!
| retsl wrote:
| I set up Qubes OS for and with technical, less-technical
| and non-technical people and I very much disagree. It
| only works well for those who are prepared and motivated
| to learn, and even then, it sometimes can be frustrating.
|
| The copy-pasting between VMs, mentioned in a sibling,
| requires four steps: (1) copying to the source VM's
| clipboard, (2) copying to the global clipboard, (3)
| copying to the destination VM's clipboard, and (4)
| pasting to the destination. The shortcuts become part of
| your muscle memory after some use, but until they are,
| that is just one way in which Qubes gets in the way of
| productivity.
|
| There are a bunch of minor quirks, often specific to the
| hardware, which the user needs to learn about and find
| workarounds for. But if they do, Qubes is probably the
| most seamless way to work with tons of (well-isolated)
| VMs. For example, SecureDrop [0] is based on Qubes and
| does seem to work well for journalists for securely
| receiving and working with documents from anonymous
| sources.
|
| [0]: https://securedrop.org/
| fsflover wrote:
| > and I very much disagree
|
| > The shortcuts become part of your muscle memory after
| some use
|
| So you agree that it's doable, just that it requires a
| bit more effort. It's definitely true.
|
| > bunch of minor quirks, often specific to the hardware
|
| Which is why there is a list of recommended hardware:
| https://forum.qubes-os.org/t/community-recommended-
| computers...
| jwells89 wrote:
| > That means throwing out a lot of code too. It's the cost to
| pay.
|
| And likely, upsetting power users who want to run with all
| the safeties off.
| HoyaSaxa wrote:
| Impressive finds! As you allude to in your post, it seems very
| likely similar flaws still exist in the wild. I'd imagine we are
| going to see a consistent stream of XPC related CVEs unless Apple
| is redesigning its approach to hardening those services.
| chuckadams wrote:
| > According to Apple, "CVEs are only assigned to software
| vulnerabilities previously released to production and not to
| vulnerabilities for beta-only software." This vulnerability only
| affects the macOS Sonoma Beta version.
|
| IOW it's a fascinating read into security research and macOS
| architecture, but only pertains to a beta release of the previous
| major version.
|
| (edit: I stand corrected, there's multiple vulns as TFA's very
| title says, and some may still be pertinent)
| jmmv wrote:
| You make it sound like the whole article is about
| vulnerabilities in a macOS beta version, but what you quoted
| applies to just two of them.
|
| ... clarifying in case someone else reads it the same way.
| chuckadams wrote:
| Fair enough, good point and good catch. Edited my reply just
| in case this gets lost in the firehose of 32 comments ;)
| lapcat wrote:
| There's an endless stream of bypasses on macOS, because the
| operating system was never designed for these granular
| permissions. You can't just add them later, on top of the legacy
| Mac OS and NeXTSTEP technologies.
|
| I've found a number of bypasses myself, and I'm not even a
| security researcher, just a longtime app developer. I know where
| the bodies are buried, so to speak. However, I ultimately gave up
| looking, because Apple's security vulnerability reporting system
| is absolute trash; their only interest seems to be to keep you
| quiet for as long as possible. It's a waste of time.
|
| My overall feeling is that macOS has become the victim of
| security theater, harming both users and legitimate developers
| with enfeedbled software and an endless stream of permissions
| requests--much like Apple's old parody of Windows Vista--while
| doing nothing to stop real attackers, who can easily bypass the
| security theater whenever they want.
| CraigJPerry wrote:
| >> You can't just add them later, on top of the legacy Mac OS
|
| SELinux managed it, what's fundamentally stopping MacOS?
| result2vino wrote:
| Can your grandma use SELinux? Delusional.
| mu53 wrote:
| SELinux is for distro and package maintainers to use. Not
| end users.
| lmz wrote:
| And yet for a large number of years any RHEL/CentOS
| SELinux issues with third party software were answered
| with "disable SELinux".
| homebrewer wrote:
| Same for Windows' UAC in the Vista era, which doesn't
| make it bad technology or place the fault on Microsoft.
| The world is full of terrible development practices, the
| answer shouldn't be "just disable your security
| mechanisms".
| lmz wrote:
| So you agree that end users _do_ use it and are often
| incapable of getting the things they want to work with
| it?
| snakeyjake wrote:
| A large number of years up to and including "this year,
| right now, like, yesterday".
| johnnyjeans wrote:
| My Grandma doesn't have a need for backwards compatibility
| or the million other things that stop Apple from just
| making a new operating system.
|
| Normal people's use cases for their computer is light file
| management, light document and productivity workflows and
| everything else is done in the browser. Hell, most of the
| document processing and productivity crap is in the browser
| these days too.
| lapcat wrote:
| In other words, your grandma could use an iPad rather
| than a Mac.
| bombcar wrote:
| This is the real answer - 90% of people can use a phone
| or an iPad for their general computational needs - and
| the PC/Mac itself will trend toward that, with harder and
| harder gates to bypass to get a truly "general" computer.
| smm11 wrote:
| Chromebooks, actually.
| homebrewer wrote:
| > delusional
|
| That's rather self critical of you, even if deserved.
|
| My grandma also can't write software, or really do anything
| advanced, no should she be able to. SELinux, just like any
| other security and/or containerization technology, is
| supposed to be used by developers, sysadmins, distribution
| maintainers. Not by end users.
|
| Is the macos sandbox the odd one out? I'm not familiar with
| it, but find it very hard to believe that "my grandma" is
| its target audience.
| cyberax wrote:
| If she has an Android phone, she's already using it.
| lapcat wrote:
| There's a [dead] reply that you may not see, but frankly I
| kind of agree with it: "Can your grandma use SELinux?
| Delusional." https://news.ycombinator.com/item?id=42087188
| nolist_policy wrote:
| Android uses SELinux.
| lapcat wrote:
| So?
|
| You can't compare Android to macOS. Compare Android to
| iOS, which had many more limitations built-in from the
| start than macOS.
|
| Incidentally, this is why iPad has never become the
| desktop replacement everyone claimed it would be. The
| hardware is plenty powerful, but it's always been very
| limited by the software. The greater freedom and
| capabilities of macOS is a huge advantage for desktop-
| class functionality.
| hollerith wrote:
| I think I disagree. If iOS or Android added robust
| support for external monitors, external keyboards and
| pointing devices, I'd probably switch to it to get the
| increased resistance against attacks.
|
| If I could continue to run Emacs, e.g., in a VM like WSL2
| or Crostini, I'd probably switch right away. If not, it
| would take me a year or 2 to transition to a replacement
| before I switch (and, no, that replacement would not need
| to be able to run software written in Emacs Lisp: I'd be
| happy to replace, rewrite or walk away from any
| functionality I currently get from code written in Emacs
| Lisp).
| nextos wrote:
| I use Linux, I would not switch to Android, but I agree
| the Linux userland should take sandboxing much more
| seriously. Things like Firejail show it can be done
| without much friction for the user.
|
| The current model, where executables can access any user
| file or resource, needs to go. We haven't learned
| anything from e.g. compromised pip packages that stole
| ssh keys.
| 6SixTy wrote:
| Android does have support for external keyboards and I
| know mice work but not the totality of pointing devices.
| There was a desktop experience with Samsung's DeX,
| complete with floating windows, but the experience was
| severely broken due to lackluster app support and
| clashing design priorities between touch and mouse.
|
| Thing is that Android is probably no more secure than a
| standard desktop experience specifically due to the very
| uncontained Play Store, the prevalence of sideloading
| apps and rooting doesn't really help at all.
| hollerith wrote:
| >Android is probably no more secure than a standard
| desktop experience
|
| Do you have an opinion on whether GrapheneOS is more
| secure than a standard desktop experience?
|
| >complete with floating windows
|
| The irony is that I don't even use floating windows on my
| (Gnome) Linux install: I maximize all the windows as if
| it were iPadOS or something.
| zie wrote:
| > If iOS or Android added robust support for external
| monitors, external keyboards and pointing devices, I'd
| probably switch to it to get the increased resistance
| against attacks.
|
| They basically do now?
|
| On iOS I've never seen a BT keyboard not pair and I've
| never had problems with external monitors. Sometimes
| getting the right dongle so it plugs in is the bigger
| problem, but iPads have been USB-C for a while now,
| making it pretty much a non-issue, whenever I've tried.
|
| I haven't tried with Android in a while, but I'd be
| surprised if it's much different than iOS at this point
| in time.
| hollerith wrote:
| Can iPadOS display a UI tailored to the native resolution
| of the external monitor such that the user need never
| interact with the iPad's own display?
|
| Is using a mouse with Mobile Safari a pleasant experience
| if the user is doing many hours of interaction that way?
|
| (Actually, now that I think about it, iPadOS is too
| restrictive for me: I can't configure it in ways I would
| want to, but _GrapheneOS_ doesn 't have that problem what
| with being almost entirely open-source.)
| lmz wrote:
| Usability. And/or good taste.
| CraigJPerry wrote:
| Usability is apple's thing. My AirPods just work, every
| Bluetooth headset before just annoyed. Why can't they
| achieve usability in this space? To be honest, redhat's
| solution is pretty darned usable - in the context of an
| enterprise Linux box(1). it helps that they built that
| database of policy profiles but even creating my own policy
| is pretty straightforward (3 commands + whatever it takes
| to make my app exercise all its code paths)
|
| (1) apples context is obviously different
| acdha wrote:
| SELinux can be part of the solution but it doesn't solve the
| problem. The median Linux system is far behind the median Mac
| because while SELinux exists you still have to craft fine-
| grained policies and deal with all of the exceptions needed
| to have the system still be usable. This is more a function
| of budget than anything else.
| CraigJPerry wrote:
| >> SELinux can be part of the solution but it doesn't solve
| the problem
|
| Hold on that's changing the goalposts a bit here. SELinux
| doesn't solve this problem on RHEL boxes by virtue of just
| existing. It is the tool that Redhat uses to solve the
| problem. And they have solved the problem by using this
| tool. To the point that for years now, by default, RH boxes
| are installed in enforcing mode.
|
| >> The median Linux system is far behind the median Mac
|
| I'm not really interested in the median because for better
| or worse, Redhat is the most serious game in town for
| SELinux. Comparing Mac to RHEL, there's only one place
| where Mac is ahead and that is a default Mac install at
| least on Apple silicon will have an immutable root. Redhat
| has irons in the fire here (rpm ostree can infuturue unlock
| a user friendly immutable root). Of course you can do
| immutable root today (and immutable usr and even epehemeral
| var if you want), but I'm not going to argue those are user
| friendly. An experienced sysadmin will take a minute to
| flip over between immutable root file systems during an
| upgrade process.
|
| >> This is more a function of budget than anything else.
|
| Agreed, but the Apple chequebook looks plenty beefy.
| acdha wrote:
| > And they have solved the problem by using this tool. To
| the point that for years now, by default, RH boxes are
| installed in enforcing mode.
|
| They've shipped it, yes. It doesn't count as solved until
| all of the apps are running with policies which actually
| block attacks like this, just as having a fire
| extinguisher on the shelf doesn't mean your fire is
| guaranteed to be out.
|
| > Comparing Mac to RHEL, there's only one place where Mac
| is ahead and that is a default Mac install at least on
| Apple silicon will have an immutable root.
|
| Also they have far more common use of sandboxing for
| applications (including the harder bits about selective
| permissions for apps), code signing, memory protection,
| pervasive use of HSM and robust layered storage
| encryption, etc. - all out of the box, whereas even in
| the much easier case of servers you're looking at many
| hours of skilled labor to configure an equivalent.
|
| My point about budgets is that this is just a lot of
| work. Apple's not perfect but a lot of people have a
| mental model from the 2000s which is no longer true.
| criddell wrote:
| Is SELinux what you would use if you wanted to deny
| access to the microphone or camera or photos to all
| applications by default?
| nyrikki wrote:
| Complete different set of tradeoffs.
|
| This is one of those situations where there is no good
| option, just the least worse option.
|
| SE had mostly servers, depends on package vendors being
| altruistic, and people mostly just disabled it when it caused
| problems.
|
| That is a very different set of assumptions and challenges
| than what Apple faces.
| CraigJPerry wrote:
| Agreed, I'm not suggesting selinux itself is the solution
| for Apple. I'm just saying faced with the same problem, and
| accepting that they have different usability constraints on
| them (sysadmins vs potentially novice computer users),
| another group found a solution. Why can't Apple - they have
| the money to buy the engineering resource to bottom this
| out.
| throw0101a wrote:
| > _SELinux managed it_
|
| Not when you have _SELINUX=disabled_ (rather than
| _SELINUX=enforcing_ ), which is what I've seen in most
| environments.
|
| Personally I've had better experiences with AppArmour.
| CraigJPerry wrote:
| >> Not when you have SELINUX=disabled
|
| Yeah of course, but by default Redhat will install in
| enforcing mode. This is taking a horse to water, the
| drinking is left to the horse.
| danieldk wrote:
| I think this legacy is a burden in all mainstream operating
| systems? There are capability-based system, but none of them
| have any traction.
|
| I am not sure what the solution is. Trying to bolt on security
| still seems better than doing nothing at all, where an
| application vulnerability immediately means a compromise of the
| a full user account?
| mike_hearn wrote:
| The researcher who wrote this article seems to have been able
| to get a lot of holes patched with credits, albeit, some of
| these CVEs seem years old.
|
| I guess a company wanting as much time as possible to fix bugs
| is a part of the game though, are other companies really keen
| for you to announce found vulns ASAP? They don't control how
| fast people upgrade so announcing slower is _always_ better for
| end users, and that must ultimately take priority over the need
| of researchers for publicity. Isn 't this something that one
| has to accept when finding holes in a consumer OS as an
| external?
|
| The Apple sandbox architecture seems well designed to me,
| usually at least. There seems to have been some breakdown in
| architecture or communication in this case. To the extent there
| are bypasses it's because we demand a lot of functionality from
| desktop operating systems, arguably they are the most
| sophisticated and complex kind of operating system out there -
| far more so than server platforms. Web browsers also have a lot
| of CVEs and it's for the same reason. We want security, but
| also functionality, and inevitably there's going to be a
| tension point in the middle where the two rub up against each
| other.
| lapcat wrote:
| > The researcher who wrote this article seems to have been
| able to get a lot of holes patched with credits, albeit, some
| of these CVEs seem years old.
|
| Yes, it requires a _lot_ of time and patience. And I bet that
| the researcher has more reported vulnerabilities that he can
| 't talk about and aren't fixed. He's been doing this for many
| years.
|
| > I guess a company wanting as much time as possible to fix
| bugs is a part of the game though, are other companies really
| keen for you to announce found vulns ASAP?
|
| Apple is notorious for poor communication with security
| researchers... and with developers, and with everyone else.
| Apple also tends to patch vulnerabilities more slowly than,
| say, Google, and Apple frequently stiffs people on the
| security bounty.
| bzzzt wrote:
| > Apple frequently stiffs people on the security bounty.
|
| Having seen the receiving end of a bounty program of a
| relatively small SaaS business it's shocking to see how
| many people are abusing such a program with irrelevant or
| plain false 'vulnerabilities' and keep begging for a bounty
| (even when it's clearly stated it's impossible to send
| money to their countries). I can't imagine how many filters
| Apple has to employ to just get rid of the noise and get
| something of value from such a program.
| saagarjha wrote:
| Said researcher has expressed basically this exact concern
| fwiw. Just because they're being paid on some bugs doesn't
| mean their life is all sunshine and rainbows.
| CharlesW wrote:
| > _You can 't just add them later, on top of the legacy Mac OS
| and NeXTSTEP technologies._
|
| Apple can (and has been) since it owns the whole stack,
| evidenced by the fact that they've been gradually hardening
| macOS software and hardware for two decades.
|
| It's been gradual enough that most end users haven't noticed,
| but macOS developers are painfully aware of the security-
| related issues they have to reckon with in both major and minor
| updates to macOS. Example:
| https://eclecticlight.co/2024/08/27/launching-apps-in-
| sonoma-14-6-1-full-security/
| https://eclecticlight.co/2024/08/28/launching-apps-in-
| sonoma-14-6-1-reduced-security/
| https://eclecticlight.co/2024/08/29/launching-apps-in-
| sonoma-14-6-1-known-malware/
| https://eclecticlight.co/2024/09/03/launching-apps-in-
| sonoma-14-6-1-conclusions/
| lapcat wrote:
| > Apple can (and has been) since it owns the whole stack,
| evidenced by the fact that they've been gradually hardening
| macOS software and hardware for two decades.
|
| This is kind of an empty reply. Of course Apple can _try_ and
| has been trying. The question is whether they can do it
| _successfully_ , and I would argue it hasn't been successful.
|
| > It's been gradual enough that most end users haven't
| noticed
|
| This is not true at all. Users have definitely noticed all of
| the permissions dialogs and other related settings.
| CharlesW wrote:
| > _The question is whether they can do it_ successfully _,
| and I would argue it hasn 't been successful._
|
| Security has no finish line, unfortunately. But here are a
| few security-related things Sequoia has that Mac OS X 10.0
| did not:
|
| A firewall. VPN support. FileVault and FileVault 2. Secure
| Empty Trash. Increasingly-secure sandboxing. Library
| randomization. Address Space Layout Randomization.
| XProtect. Increasingly-secure versions of Gatekeeper.
| Increasingly-secure memory management. SIP. Kernel exploit
| mitigations. New update mechanisms for security patches.
| APFS and its associated security improvements.
| Notarization. Read-only system volume. Separation of user
| data and system files. Activation Lock. Improved system
| logging and auditing. Signed System Volume. Private Relay.
| Lockdown Mode. Visual indicators of mic/camera/location
| use. DriverKit to replace the use of kexts. Secure Enclave
| for hardware-based root of trust and secrets management.
|
| I'm just someone who pays attention. I imagine actual
| security experts could list 20+ other improvements off the
| top of their head.
| lapcat wrote:
| A number of those are security theater, and some of them
| aren't even for security at all. Also, the secure empty
| trash feature was actually removed from macOS, and I'm
| not sure what you mean by the "associated security
| improvements" of APFS.
|
| But it's not even a question of whether security has a
| "finish line". The question is whether a specific
| security feature works on not, and some of them just
| don't work.
| talldayo wrote:
| > Security has no finish line, unfortunately.
|
| Unfortunately? _Unfortunately!_
|
| I beg your pardon. Apple's service revenue is very
| fortunate for the neverending excuse of security. Want
| third-party payment processors? It's not that it would
| upset our revenue stream, it's just too insecure. You
| want to sideload with the flick of a switch? It's not
| like we already offer that feature to other users of our
| products and paying developers, it's not secure enough to
| attempt. Want an open bootloader for your iPhone like
| those Apple Silicon Macs? It's not that Apple can't do
| it, it's just that they claim it's not secure enough.
|
| The real kicker? None of us have a privileged enough view
| of the ecosystem to even know if Apple is right or not.
| The fact that security has no finish line should be
| carefully construed as not to excuse companies that move
| the goalposts of security for petty means. Apple is
| grateful that customers will accept "security" as a
| carte-blanche answer to completely unrelated topics.
| newaccount74 wrote:
| Every year I battle with a few permission related bugs in
| my app. Somehow macOS will randomly block some file
| accesses on some machines in some circumstances.
|
| Take security scoped bookmarks. The only way that
| sandboxed apps can persistently access files outside
| their sandbox. It's an important feature. It's broken on
| some Macs. I know from logs that about 0.5% of my users
| run into this bug. It's been broken for years, and every
| time I report the problem to Apple they ask me for steps
| to reproduce or and Xcode sample project. I have no idea
| what to do, it's a bug in ScopedBookmarkAgent or in
| SecKeychain somewhere.
|
| With Sequoia, they managed to break the feature for about
| 10% of users. That was apparently enough to get Apple to
| pay attention, so they fixed it in macOS 15.1. I think
| it's back to 0.5% now.
|
| Somehow Apples own apps aren't affected by these bugs.
| Bugs that mostly affect 3rd party apps seem to slip
| through a lot more easily.
|
| The security tech in macOS is unreliable garbage. And
| people praise it, they just think 3rd party apps are
| buggy. But for a lot of my bugs, the bug is in the macOS
| frameworks, but users come to me and complain.
|
| It's no wonder that many developers don't sandbox their
| apps. It's just perpetually broken.
|
| I wish they would make their tech reliable.
| cyberax wrote:
| That's because the reason for these limitations is to make it
| harder for the third-party developers to compete with Apple's
| products.
| rustcleaner wrote:
| Responsible disclosure is immediate public disclosure with no
| embargoes. Embargoes are how we as users are absorbing the
| costs of poor security practices. If the culture was a no-
| warning publish culture, I would expect feature iteration and
| API breaks to slow down to more conservative levels as
| bikeshedding that stuff dwindles.
|
| Punish fast software development iteration with public
| embarrassment and lost users who got hosed by the
| vulnerability. If Apple or whoever start dicking around and not
| paying bounties, release it... or better yet: sell it on the
| darknet; you have got to be paid for your good work, and
| NSA/NSO are going to need more 0-day vulnerabilities with WWIII
| underway!
| RoxaneFischer1 wrote:
| those overlooked xpc services in the pid domain are a clever way
| to bypass sandbox limits on macos. that dyld injection trick to
| dodge entitlement checks is slick. apple's patching here feels
| kinda bandaid-y--maybe they need a real overhaul on how sandbox
| inheritence works?
| StrangeDoctor wrote:
| I know it's more complicated than what I'm about to ask but,
|
| Does escaping the sandbox just get you back to a state where
| there isn't one? Or does it allow you an even more privileged
| state?
| lapcat wrote:
| Mostly, it just gets you to a non-sandboxed state. However, I
| do seem to recall vaguely one issue I saw where escaping the
| sandbox got you a higher privileged state, I think because of a
| bug in the kernel logic that enforces the sandbox.
| pram wrote:
| MacOS should really have some kind of capabilities based Darwin
| containers, rather than what seems like a giant tangle of
| blacklists.
| doctorpangloss wrote:
| https://github.com/darwin-containers
|
| https://news.ycombinator.com/item?id=37655477
|
| There's no security model for desktops that works well.
|
| Like another commenter said iOS has no legacy cruft and could
| deliver the security model that made sense.
|
| On the other hand, when Telegram asks you to share all your
| contacts and images with it, people do.
| fsflover wrote:
| > There's no security model for desktops that works well.
|
| Qubes OS works quite well, if you need security on desktop.
| rustcleaner wrote:
| Seconded. Been daily driving it on ThinkPads now for
| something like two years. I will never go back, and one of
| the few things which might draw me off Qubes OS is if
| OpenBSD cleanroom reimplemented Qubes OS with their own OS
| and hypervisor. (OpenBSD because nobody beats their long
| term code quality and consistency.)
| nolist_policy wrote:
| I like ChromeOS' security model: Nail everything shut, but
| leave a Linux VM as a escape hatch.
| pyeri wrote:
| Let us simplify our IT layers and stacks before it is too late.
|
| It's time to introspect and ask those critical questions: Is it
| really necessary to install each one of these apps, every single
| one of these libraries and frameworks? How can I remove
| dependencies from these libs and do a little core work myself?
| And tell the same thing to your partners, colleagues, coworkers,
| etc. If you find 4-5 apps doing basically the same thing (like
| communication or productivity tool), see if you can consolidate
| them into one.
| danudey wrote:
| > If you find 4-5 apps doing basically the same thing (like
| communication or productivity tool), see if you can consolidate
| them into one.
|
| If I could get all of my friends to switch to one communication
| app, that would be great, but that's only going to happen if
| they can get their friends to switch, and so on. Unfortunately,
| doing so requires them to install additional apps for
| communication, and no one can get _everyone_ they talk to to
| switch, so they 're just going to have more people on one app
| than another and in the end the problem gets worse.
| Syonyk wrote:
| Matrix bridges solve a lot of this problem, though... aren't
| really reducing complexity at all ends of the system. It does
| radically reduce end user app complexity, though.
|
| I've been hosting a Matrix homeserver for... oh, 4-5 years,
| now, and I have bridges installed for my use and a few other
| people who use it that bridge Signal, Google Chat, Facebook
| Messenger, and maybe one or two other services into Matrix -
| so I almost _never_ have to bother with the other clients, I
| just use a Matrix client everywhere. There are the occasional
| quirks you have to deal with, most of which are solved by
| upgrading your bridge (and the new bridges are a lot easier
| to deal with than the older ones).
|
| As people decide to go Matrix-native, I can talk to them that
| way as well.
|
| That said, as far as non-Matrix options go, Signal seems to
| be a fairly common one and easy enough to get people to
| switch to.
| paulryanrogers wrote:
| In my circles Signals died when they dropped being the SMS
| app.
|
| I wish they had gone the other way, and been a bridging app
| like Pidgin with plugins.
| knotimpressed wrote:
| Just heard of Matrix and it seems super interesting; how
| clunky are the bridges in practice? Is the UX/setup
| painless or does it have some issues?
| Syonyk wrote:
| I mean, how's your Linux command line these days?
|
| https://docs.mau.fi/bridges/go/setup.html?bridge=signal
| is the setup for the Signal bridge, and you'll also need
| to look at the initial config setup. Once you have a
| working Matrix homeserver, it's mostly "Create a new
| database table, point the bridge at it, add the proper
| incantations to your homeserver config so it knows the
| bridge is permitted, and start things up."
|
| I don't find it bad in the slightest, but I'm also a
| legacy Linux sysadmin sort.
|
| There are also Docker methods of doing it, if you prefer
| that: https://docs.mau.fi/bridges/general/docker-
| setup.html?bridge...
|
| If you're a GUI-only sort, it will be painful. If you're
| competent with older styles of Linux sysadmin, it's
| fairly straightforward, though getting Matrix federation
| working reliably can be a slight pain. Just make sure
| your certs update...
| rustcleaner wrote:
| Yeah and that one app will be SimpleX or I may as well be dead
| to everyone, if I went down that road.
| Syonyk wrote:
| This is, unfortunately, the sort of thing that motivates QubesOS.
| We are, as humans writing code, _not good_ at complexity, and as
| Apple 's lockdown mode admits, parsing complicated stuff, even
| when you design security boundaries around it, is hard to do
| properly. Lockdown just punts a ton of complexity entirely out of
| the system, and the tradeoff is rather substantially improved
| security against a wide class of attacks.
|
| QubesOS design philosophy is essentially, "Everything in a booted
| OS image must be assumed to be able to, some way or another,
| access everything else in there." So you have various silos that
| have extremely limited communication between them (you can "push"
| from one VM to another, but you can never "pull" from another VM,
| the framebuffer is simple, etc). You're totally free to add
| sandboxing as useful, but it's not considered a full security
| boundary. Hardware virtualized VMs are, on a fairly stripped down
| Xen that removes a lot of attack surface in terms of legacy
| device emulation and other features they don't need.
|
| Apple has done a lot of security focused improvements over the
| years, but modern computers and OSes are just _so_ complicated
| that even they struggle to get it right regularly. And the
| attackers only need one mistake to achieve their goals. :(
|
| //EDIT: As far as practicality goes, I do daily drive QubesOS as
| my main computer on a 2C/4T laptop with 16GB RAM - old X250.
| There are plenty of things it's not great at, but I'm not heavy
| on the "videos or video games" thing anyway. Dual booting for
| gaming is an option, as is a separate desktop that doesn't do
| anything important for gaming, but you don't need some monster
| machine to do practical things with Qubes. I can't have a
| thousand browser tabs open, but I don't do that anyway, I browse
| "JITless" (disable Javascript JIT as it's a ton of attack surface
| that's regularly exploited), and... it's a less-intense form of
| computer use than standard, but it also means I don't have a
| desire to spend all my time on a computer.
| normie3000 wrote:
| Interesting set up, thanks for sharing. Do you write code, or
| use docker at all?
| Syonyk wrote:
| I write code, yes. I'll just spin up a development VM as
| needed, things work fine. I don't use Docker, but as long as
| you're not using the hardware virtualized modes, it should
| work just fine on namespaces. Every VM is running a full
| featured Linux kernel. There's just not nested virtualization
| support, which I'm totally fine with, because nested
| virtualization on x86 is a rather complex mess to get right.
|
| The main thing you lose is GPU acceleration. I don't
| particularly care.
| rustcleaner wrote:
| I argue never dual-boot Qubes [with it installed on an internal
| drive] because Windows can [theoretically] read those
| partitions. Better to just get a separate application-specific
| system for gaming.
|
| I daily drive Qubes on i7 Comet and Raptor Lakes, 64GB and
| 128GB RAM respectively. I run LLMs on their GTX and RTX cards
| (albeit slowly on the Comet Lake/GTX system). Digital crac...
| err gaming is the only thing I am pretty well locked out from.
| Syonyk wrote:
| It really depends on your threat modeling and what you're
| concerned about. I agree, dual booting isn't ideal, but also,
| "dual booting Qubes and Ubuntu for gaming" cannot be any
| worse than "simply running everything on Ubuntu," as long as
| you don't believe Qubes is impervious to anything nasty in
| that configuration.
|
| The main storage partitions are encrypted for Qubes (... or
| had better be, I guess you could avoid that, but why?), so
| the dual booting attack path would have to be through the
| boot partition, load something that can then compromise the
| install. It's a fairly specific sort of attack that, if
| someone's coming after you with that, it's probably a
| question of "How and when you're screwed, not if." But for
| general users, I think dual booting is an acceptable
| compromise. Just don't do much of anything in the other
| install!
|
| I dual boot my laptop. There are a handful of things that are
| far easier to do in Ubuntu than Qubes (movies on a long
| flight, run a Windows VM to run particular software to talk
| to cars, and Minecraft for LAN parties). I'm aware of the
| risks, and don't consider them to be enough to remove the
| ability to do a few other things on one machine. I try not to
| have too large of piles of single purpose computers these
| days...
| imglorp wrote:
| SBPL (sandbox profile language) is interesting. Some details
| here: https://github.com/0xbf00/simbple
|
| I'm curious if there's a Scheme interpreter somewhere as part of
| macos that consumes these?
|
| PS looks like it's "sandbox-exec" that does this. Ref:
| https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...
| mdaniel wrote:
| I first learned about it from iTerm2's build process:
| https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170
| and https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb
| Szpadel wrote:
| I love and hate sandboxes.
|
| They're great second line of defence, but large organisations
| tend to reject fixing RCE when you are not able to escape sandbox
| and so anything meaningful, so they use them as main line of
| defense and that makes me sad.
| Analemma_ wrote:
| > but large organisations tend to reject fixing RCE when you
| are not able to escape sandbox and so anything meaningful
|
| Wait, who does this? AFAIK Apple, Microsoft and Google all have
| bug bounties which obviously offer bigger rewards for sandbox
| escape, but still pay something if you find a vulnerability
| which is blocked by the sandbox. They're all well aware that
| bad guys collect and store non-functional RCEs in the hopes of
| using them when a sandbox escape is found.
| aidenn0 wrote:
| Depending on where it is in the product lifecycle, I've seen
| this extreme pushback against fixing symptomless bugs.
|
| I was working on a project where someone thought to turn on
| tools for catching malloc errors (use past the end of
| allocated buffer, use after free &c.). The team that did this
| found bugs in their own code, of course, but also many from
| other teams.
|
| I was there in the room as people went item-by-item
| litigating whether or not each bug should be fixed. Things
| like "sure this is use-after-free, but it's used immediately
| after the free and because of the struct offset, it can't
| corrupt the heap linked-list, so we won't fix it"
| w10-1 wrote:
| Also exploitable in iOS (~2B active devices, vs ~100M mac's)
| wannacboatmovie wrote:
| Maybe it's time Apple admit that maybe next-gen AV has a place on
| the Mac platform, and not rely on the current model of hope and
| good vibes to mitigate new attacks. This includes not allowing
| their community moderators to continue to gaslight customers into
| thinking all security software is bad and that their OS is
| invincible with 2000s-era propaganda on their support forums.
| saagarjha wrote:
| Can you explain to me how you see security software as helping
| here?
___________________________________________________________________
(page generated 2024-11-08 23:00 UTC)