[HN Gopher] macOS 11's hidden security improvements
___________________________________________________________________
macOS 11's hidden security improvements
Author : ingve
Score : 103 points
Date : 2021-08-20 19:28 UTC (3 hours ago)
(HTM) web link (blog.malwarebytes.com)
(TXT) w3m dump (blog.malwarebytes.com)
| thepangolino wrote:
| But does it scan your pictures???
| Scoundreller wrote:
| It ingests but it doesn't exhale.
| comex wrote:
| Note that, although it was published recently, this article
| covers macOS 11 (Big Sur) which released last year, not macOS 12
| (Monterey) which is in beta.
| justinzollars wrote:
| I feel absolutely violated by Apple. Privacy and Security are now
| words I would not associate with that brand.
| sillysaurusx wrote:
| > NO_SMT disables Simultaneous multithreading (SMT), the CPU
| feature better known under Intel's trade name of "Hyper-
| Threading". SMT allows a CPU core to execute two or more threads
| at the same time, for improved performance at the cost of
| contention for per-core resources, such as caches, TLBs etc.
|
| > Letting multiple threads share invisible resources carries the
| risk of letting a malicious thread steal secrets from a "sibling"
| thread running on the same core--a risk that over the years has
| materialized into multiple attacks, like TLBleed, PortSmash,
| Fallout, ZombieLoad, RIDL. A straightforward mitigation for this
| entire family of attacks, past and future, is then to simply
| disable SMT, which is what NO_SMT does.
|
| BAHAHA cperciva was right! It's a decade later and people care
| now! Linus didn't care at the time!
|
| I'm on mobile otherwise I'd link to relevant refs, but it was an
| "I told you so" 10 years in the making. Maybe longer? When was
| cperciva's cache stealing research?
| mzs wrote:
| How many years until this from last year is regretted?
|
| introduce memfd_secret system call to create "secret" memory
| areas
|
| v11: * Drop support for uncached mappings
|
| https://lwn.net/ml/linux-kernel/20201124092556.12009-1-rppt@...
| gregsadetsky wrote:
| Discussed here:
|
| https://news.ycombinator.com/item?id=16082909
|
| cperciva's paper from 2005 (linked above):
|
| http://www.daemonology.net/papers/htt.pdf
| sillysaurusx wrote:
| Hmm. That commenter's username seems familiar...
|
| Thanks. :)
|
| > The problems introduced by caches have been further
| exacerbated by the current trend towards increased
| parallelism. On recent processors implementing simultaneous
| multithreading [18], such as Intel's "Hyper- Threading"
| processors [11], access to the L1 cache is shared between two
| independent instruction streams
|
| And here we are 16 years later, with NO_SMT. Neat.
|
| Perhaps my emotional outburst wasn't substantive, but boy was
| it satisfying. I'll try to restrain such urges in the future,
| but somehow I doubt a 16 year "told ya so" will pop up again
| any time soon. It's half as old as I am.
|
| I wish I could remember Linus' remark about cperciva's attack
| being merely "theoretical."
| gregsadetsky wrote:
| https://lkml.org/lkml/2005/5/16/152
|
| Linus: "[...] I'd be really surprised if somebody is
| actually able to get a real-world attack on a real-world
| pgp key usage or similar out of it (and as to the covert
| channel, nobody cares). It's a fairly interesting approach,
| but it's certainly neither new nor HT-specific, or
| necessarily seem all that worrying in real life. [...]"
| kccqzy wrote:
| Interesting tidbit about Chrome using POSIX_SPAWN_NP_CSM_ALL now.
| But I would point out that according to the open-source Chromium
| code base, these CPU security mitigation APIs offer process-wide
| protection rather than thread-based protection (commit message at
| https://source.chromium.org/chromium/chromium/src/+/46e23c81... )
|
| Some more digging shows that Chrome started using a weaker
| version of CSM, TCSM (thread CSM I assume) two years ago in NaCl:
| https://source.chromium.org/chromium/_/chromium/native_clien...
|
| Firefox of course uses TCSM too: https://hg.mozilla.org/mozilla-
| central/rev/cd1ccb74af7c And so does Safari:
| https://trac.webkit.org/changeset/244233/webkit
|
| I hope this at least somewhat assuages the fears of people who
| prefer Firefox or Safari over Chrome.
| darwingr wrote:
| But can it ignore your firewall settings?
| azinman2 wrote:
| My understanding is if you change firewall settings using PF
| let's you have total control, unlike network extensions.
| GekkePrutser wrote:
| Correct, though both layers remain active. The application-
| level firewall in the macOS GUI and the packet-based pf layer
| work on top of each other (I believe pf is on top of the
| application layer one but not 100% sure).
|
| So if you have the application firewall on, opening ports in
| pf won't help.
|
| I'm kinda surprised pf is still in there to be honest. I know
| some security solutions like McAfee Firewall use it under the
| hood. But they could do similar things with network
| extensions. I have expected them to drop it for years now.
| user3939382 wrote:
| The security improvement I want is that when I run 'ps ax' on a
| fresh install, I have reduced attack surface instead of dozens of
| random daemons hardwired into launchd like the one for
| classrooms(??), iCloud and photo sharing even when those features
| are disabled, etc.
| uniqueuid wrote:
| I'd be interested to hear from someone with deep security
| knowledge:
|
| Some people have dismissed OpenBSD's mitigations as overhyped
| (i.e. - things like W^X are not the main problem, linux has long
| caught up, etc).
|
| But now we see Apple adding precisely some of these mitigations.
|
| Where does this leave such architectural countermeasures? Are
| there real gains from investing in such low-level things? Are
| they irrelevant in an age where many laptops still have ports
| that give direct DMA access, users are not savvy and sandboxes
| incomplete?
| fay59 wrote:
| It's clear that W^X isn't "solving security", but it's not a
| bad idea just because it's a low-hanging fruit. On Apple
| platforms, I think that it came to be as a natural consequence
| of the ability to toggle RX mappings to be RW without a
| syscall.
|
| Almost all DMA-capable peripherals on Apple Silicon (including
| iDevices) are gated behind an IOMMU.
| comex wrote:
| Which mitigations exactly?
|
| macOS has enforced W^X in most cases for many years.
|
| As for the two mitigations mentioned in the article:
|
| NO_SMT seems to be equivalent to Linux's "core scheduling"
| feature, which landed recently [1]. This approach, involving
| disabling SMT (aka hyperthreading) for specific processes, is
| different from OpenBSD's more brute-force approach of disabling
| SMT systemwide; there are pros and cons to both approaches.
|
| As for the other one, forcing VERW to be executed on every
| return from the kernel, _both_ Linux and OpenBSD chose the
| brute-force approach of doing this for all processes by
| default; both added this feature in 2019 as part of the
| coordinated disclosure of the MDS vulnerability class. Apple is
| instead doing it on a per-thread basis. Again, pros and cons.
|
| [1] https://lwn.net/Articles/861251/
| saagarjha wrote:
| (To provide more context, before the new APIs Apple used to
| flip actual page memory protections, which required going
| through the kernel. The new SPRR APIs allow for essentially
| the same thing, except they work per-thread and just set a
| register accessible from userspace that essentially applies
| an extra mask on the permission bits, which is much faster.)
| saagarjha wrote:
| W^X is a good mitigation to prevent attackers from just
| spraying shellcode into a RWX heap. This is how most JIT
| engines used to be attacked, and many exploits continue to
| include WebAssembly just because Chrome will create a RWX arena
| for this. Many of the OpenBSD mitigations are actually a good
| idea, but some are fanciful junk. The posture that the team has
| towards pushing those latter ones is what generally makes
| people unhappy.
|
| Also, do note that Apple silicon puts everything behind a DART
| (essentially an IOMMU). This is noted in the article:
|
| > Device isolation was another M1-only feature, that uses the
| more powerful IOMMU of that platform to make sure hardware
| devices can only share memory with the operating system and not
| with each other. Cross-device memory sharing is a historical
| custom, based on a blind, unfounded trust in hardware.
| bangonkeyboard wrote:
| Very hidden. The 11.5.2 patch from last week had no release notes
| (https://eclecticlight.co/2021/08/15/last-week-on-my-mac-
| trus...), and Apple replied to inquiries with "No further details
| on the Big Sur 11.5.2 update will be released" (https://twitter.c
| om/ClassicII_MrMac/status/14256327792624312...).
| GekkePrutser wrote:
| Sounds good but a problem with Apple's latest releases are that a
| lot of its security features listen only to Apple and not to the
| user.
|
| This doesn't concern most of the improvements mentioned in the
| article, those are purely technical improvements at a very low
| level. But the signed system volume for example (also mentioned),
| while a good idea, lacks a convenient way for the user to make
| changes to it. I'm not very happy leaving my security to a black
| box and just trusting the supplier implicitly. This is a supplier
| that introduced a "get root with blank password" bug and the
| "your password hint is your actual password" one. Sure, everyone
| makes mistakes, especially for that reason I'd want to have more
| access than they offer now.
|
| macOS is becoming more and more like iOS, which is also way too
| closed in my opinion. More locks is always good but the user
| should have a key, not just the supplier.
| goodpoint wrote:
| > its security features listen only to Apple and not to the
| user
|
| That's the definition of backdoors.
| tyre wrote:
| No, it isn't.
|
| The password hint bug, for example, was "only listening to
| Apple" in the narrow sense that the OS wouldn't let you run
| your own implementation of password hints or login. But it's
| not a backdoor.
|
| There are plenty of built-in features that aren't
| configurable, which is fine and good. Because most people
| have no idea what those things do, most of the rest shouldn't
| touch them, and leaving them as configurable or editable
| opens up a whole class of malware.
| azinman2 wrote:
| You can always disable CSR/SIP generally. macOS is unlike iOS
| in that many security mitigations can be disabled. The fact
| that new M1 Macs let you side load a diff non-Apple in iOS
| should be the ultimate proof you need of this motivation to
| allow user control on Macs.
| cma wrote:
| Won't the next update still wipe out your system changes,
| putting you back to insecure openssh password auth, etc., or
| do they have a system to merge your changes over now?
| upbeat_general wrote:
| Except doing so doesn't let you run iOS apps and not to
| mention is a pain to do so after every update (I believe SSV
| requires that).
|
| The list of things to disable seems to grow every year. Even
| with Gatekeeper, CSR/SIP disabled I'll still have issues
| opening applications which may (or may not) be fixed by
| taking it out of quarantine, changing the signature, etc
| saagarjha wrote:
| You can disable SIP once and it will stay off (although
| maybe not if you do a full system update).
| jchw wrote:
| If one mentions Android's "openness" as a plus, people
| (rightly) point out that sure, it is technically open source
| and you can often sideload, but that doesn't mean it is
| friendly towards those things necessarily. A lot of downsides
| come with rooting and bootloader unlocking after all. That is
| when comparing to iOS, which is _more_ restrictive than
| macOS, as you point out.
|
| I mention this because I think that it's good Apple lets you
| use some of the hardware you own with relatively little
| restriction if you so choose, but it is a lot less practical
| than the previous status quo and other systems. You
| definitely lose some functionality (on M1, I believe you lose
| at least iOS application support.) If we're going to be frank
| about it with Android, I think it's fair to be frank about it
| with macOS/M1.
|
| I would guess things could be better if user choice was as
| much of a focus as vendor control.
| ChuckNorris89 wrote:
| > _A lot of downsides come with rooting and bootloader
| unlocking after all._
|
| I think you might be confused. You don't need to root or
| unlock the bootloader on an Android device to side load
| apps. Just download desired APK and accept the security
| prompt of installing from unknown sources. It's literally
| that easy.
| eropple wrote:
| Those applications can't get root, though, and that does
| limit user control of the device.
|
| (I used to root Android phones in the 4.x days, and then
| stopped, and then went back to iOS as I found myself
| doing progressively less and less with my phone.)
| jchw wrote:
| No, I'm not confusing them, although I am conflating a
| bunch of stuff because the details aren't too important.
| Sure, sideloading is relatively free of any negatives,
| but to really take control you need custom ROMs and
| rooting. The point of this is that downsides to Android's
| limitations regarding "openness" are totally fair game
| for critique, and the same for Apple platforms too.
|
| Obviously, there's some path forward that provides better
| tradeoffs than the ones we have now. Most designs today
| do not strongly regard user choice and rights as
| important. This is not _just_ an Apple issue; I would say
| I have disdain for the ways Microsoft approached secure
| boot on consumer desktops too. They backpedaled on some
| of it, but it would be better if designs started out
| considering users rights in the first place.
| GekkePrutser wrote:
| Yes you can disable it, but then you disable it completely
| and totally. There is no middle ground. Most of the time
| these things are totally great ideas. Apple is doing really
| great work on the security front for sure. It's just what
| they lack is a way to customise them. Most security
| improvements they make involve giving Apple the keys and them
| alone. It doesn't have to be that way.
|
| For example I would want to be able to just make an exception
| for some of the files I want to change.
| Klonoar wrote:
| There actually is a middle ground, in some cases - csrutil
| can, for instance, allow you to disable unsigned kext
| blocking but keep the rest of SIP enabled.
| GekkePrutser wrote:
| I thought those were entirely separate things? There's
| now a GUI option for the unsigned kernel extension block
| (in the startup security utility). I don't think that's
| part of SIP per se. It's also the one you need to run any
| other OS. Whereas SIP is a thing within the OS itself as
| far as I know. But I have to admit this is where my
| knowledge gets fuzzy :)
|
| The kind of control I'd want is allowing to add a
| signator for approved kernel extensions. So that I could
| add my own key and sign kernel extensions myself. Or
| trust another party to do this. Just like you can add
| your own keys to Secure Boot on a PC. The same with the
| app notarisation. Another feature that's essentially
| great, but fully under the control of Apple. For example,
| as a corporate admin it'd be great to be able to notarise
| which apps I'd allow our employees to use.
|
| These security tools would be super powerful and useful
| if we would be allowed to configure them more.
| hdjjhhvvhga wrote:
| On the other hand, Linux is getting better and better. And with
| the prevalence of web apps, the main obstacle to running non
| (MS | Apple) systems is getting smaller. With Linux, you can
| adjust the level of security you need _and_ you keep the key.
| Security improvements appear also in BSDs, especially OpenBSD,
| but honestly I wouldn 't recommend people used to macOS to
| switch to OpenBSD (yet).
| robbyking wrote:
| It's the year of the Linux desktop!
| marricks wrote:
| It always is! (in a good and bad way)
| GekkePrutser wrote:
| Indeed. I switched to FreeBSD myself.
|
| Reasons were the excellent jails system, the ports
| collection, the ZFS on root (though Ubuntu is starting to
| offer that) and the great documentation. I also don't like
| the scale of corporate involvement in Linux development. In
| the end that leads to companies trying to insert their own IP
| with a view to monetisation (like Ubuntu with Mir, Upstart,
| now snaps). It's also the most suitable for a desktop system
| of all the BSDs I think.
|
| But it's not for everyone. For one the hardware support is
| limited. I didn't even bother trying to get the WiFi or
| bluetooth going (I run this on a pure desktop). For laptop
| use I'd use a flavour of Linux, though I'm not entirely sure
| which I'd use :) It also doesn't hold your hand as much as
| most Linux distros, though it's not nearly as barebones as
| arch either! I'd consider it something a bit in the middle
| like Manjaro. Overall I'm really happy with it though.
|
| I still use Macs for work though and I administered them for
| a long time. It's always a struggle if you need to do
| something that Apple doesn't really want you to do. You may
| get it working, but there's a good chance it'll get broken in
| whatever minor patch that's coming along without warning :)
| Unfortunately in a business with less than 1% Macs you can't
| always do things the Apple way.
| smoldesu wrote:
| This, a million times. Now that Mojave is starting to get
| dropped, Linux is exactly what the doctor ordered for me. I
| feel a lot safer in a system where I can check the locks
| instead of being told "the door's closed, you're fine."
| saagarjha wrote:
| > I've not seen anybody mention the fact that the
| cryptographically sealed filesystem underlying SSV is internally
| code-named "Cryptex".
|
| Might as well mention it here: crytex is how you get code on the
| Security Research Device, rather than SSV.
| [deleted]
___________________________________________________________________
(page generated 2021-08-20 23:00 UTC)