[HN Gopher] macOS Sequoia 15 may bypass DNS encryption
___________________________________________________________________
macOS Sequoia 15 may bypass DNS encryption
Author : HelenePhisher
Score : 235 points
Date : 2024-09-17 19:46 UTC (3 hours ago)
(HTM) web link (www.obdev.at)
(TXT) w3m dump (www.obdev.at)
| skrrtww wrote:
| The title sort of implies this is intentional or privileged to
| Apple, while it rather seems more like just a bug.
|
| I also wish people would post the FB numbers and the details of
| their report when they say they've reported things like this.
| pkulak wrote:
| Yeah, if it was intentional, it would probably be a hard-coded,
| encrypted URL. Some devices are starting to do that to get
| around ad blocking.
| hiatus wrote:
| Good thing you can still see the domain over the network if
| you control the network.
| lukevp wrote:
| You can't control anything if they do DNS over HTTPS to a
| hardcoded IP they control and cert pin so you can't MITM
| the connection, can you?
| Reptur wrote:
| Devil's advocate would say: They could do this and make it look
| like a bug that never gets fixed in order to avoid backlash.
| How it gets achieved is flexible if the goal is met.
| asplake wrote:
| > Update 2024-09-17, 7:10 p.m.
|
| > After further investigation, we found that this bug has already
| existed at least since macOS 14.5 Sonoma (maybe even earlier, but
| we currently don't have access to an older 14.x system for
| testing).
| mattl wrote:
| Which is pretty wild too, considering they're selling the
| product and the new OS came out _yesterday_.
| taspeotis wrote:
| Did they test it ever worked with getaddrinfo? Or did they just
| see it worked once with CFNetwork and called it a day and then
| later publish a blog post saying it's broken?
| hypeatei wrote:
| > After further investigation, we found that this bug has already
| existed at least since macOS 14.5 Sonoma
|
| Isn't this an inherent risk when attempting to do network stuff
| in userspace? You're at a very high level so hoping that lower
| level things comply seems risky if DNS encryption is critical to
| your use case.
| newaccount74 wrote:
| Apple removed support for kernel extensions, and instead added
| a bunch of APIs that allow to do network filtering etc in user
| space. Unfortunately, some of their networking code just
| bypasses those network filter extensions (probably because of
| bugs) -- this is not the first time the developers of Little
| Snitch publicized a bug like this.
| xyst wrote:
| If I recall, Apple deprecated use of certain network apis for
| third party developers. But Apple's own apps (App Store) do not
| have these same restrictions. Thus, when trying to filter network
| traffic via app firewall via new APIs. It would fail since App
| Store uses legacy APIs.
|
| Maybe part of this old bug (that I thought was fixed)
| newaccount74 wrote:
| getaddrinfo() is not a legacy API, it's a standard cross
| platform API for doing DNS lookups.
| indrora wrote:
| Specifically defined by POSIX: https://pubs.opengroup.org/onl
| inepubs/9699919799/functions/g...
| trillic wrote:
| It's POSIX which Apple generally abides by except for
| timer_create. macOS is historically officially a UNIX, which
| would require getaddrinfo.
| keyboardcaper wrote:
| Funny how that goes: macOS is POSIX certified but no other
| desktop BSD or Linux is.
| nox101 wrote:
| it is apparently on Mac and arguably with good reason. See
| this comment https://news.ycombinator.com/item?id=41572770
| unluckier wrote:
| Sequoia also breaks an application's ability to use DNS (or
| presumably anything UDP-based) if the macOS firewall is enabled,
| and an app is listed as "Block incoming connections".
| https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...
| OptionOfT wrote:
| Honestly, I'm fine with that. Applications themselves should
| not be resolving DNS outside of what I set in settings.
|
| The reasons applications do this is to prevent users from
| blocking telemetry etc. It's my computer, I should have final
| say on what goes out.
| Spivak wrote:
| Yep, I wish they would go the full way and block socket
| access entirely so your own outgoing traffic is always
| introspectable even with cert pinning. It would make it
| blatantly obvious when apps try shady shit.
| newaccount74 wrote:
| Shady shit? Not every network request is a call to an HTTP
| REST API.
|
| Blocking socket APIs would break every app that supports
| other protocols. Goodbye file transfer apps, VPN apps, file
| sync apps, database tools, SSH clients, remote desktop
| clients, audio and video conferencing apps, etc.
| 9dev wrote:
| As long as I can add exceptions for those apps to my
| firewall, I'm kind of... okay with that?
| Spivak wrote:
| Shady shit meaning really obvious when you're making http
| calls with encrypted opaque blobs.
| amluto wrote:
| There is no such thing as a remotely cross-platform DNS
| resolution API that has the system do the lookup and does not
| utterly suck for asynchronous use.
| wtallis wrote:
| I suspect "cross-platform" is doing a lot of heavy lifting
| for your claim. Browser engines and application frameworks
| built on top of them have no trouble using platform-
| specific APIs under the hood.
| spookie wrote:
| Yeah, but frameworks are yet another level of abstraction
| and dependency that just kills momentum.
| nullindividual wrote:
| All major browsers now implement the ability to use a
| browser-defined resolver.
| Dalewyn wrote:
| Seeing this getting downvoted is fucking wild.
|
| I remember 20+ years ago when one of the most commonly seen
| attacks was malware configuring a proxy server in Internet
| Explorer which by design overrode the operating system's
| configuration.
|
| What a lot of software does today by ignoring the operating
| system in lieu of their own shit is just like the above. If
| your program doesn't (or can't) respect the operating system,
| your shit is malware and you should reconsider who you write
| code for.
| yndoendo wrote:
| Those ideas are not isomorphic.
|
| One malicious overrides universal network communication
| while the other just conducts DNS queries limited to a
| single application domain.
| Dalewyn wrote:
| >just conducts DNS queries
|
| Queries that will ignore configurations you set.
|
| If I see something ignoring/evading my configured DNS
| server, that shit is fucking malware.
| fmajid wrote:
| At some point in my copious spare time, I plan on writing
| software to allowlist in my firewall outbound connections
| only to IPs resolved using my DNS servers.
| mrkstu wrote:
| Have fun troubleshooting Java apps w/their own cert
| stores...
| altruios wrote:
| You are describing something that violates system setting
| for it's own benefit instead of the end user.
|
| You are describing malware. Benign malware is still
| malicious, even if it does no active harm. Intent (of how
| the software operates) matters.
| nox101 wrote:
| I have one browser setup to do DNS differently than another.
| I don't want to have to set it at a system level and then
| need multiple systems just to run 2 browsers with different
| DNS lookup
| garyrob wrote:
| After upgrading to Sequoia, I could not browse with Safari or
| Mozilla. What fixed it for me was to go to the DNS settings for
| my Wi-Fi connection, and add Google's DNS servers (8.8.8.8. and
| 8.8.4.4). They replaced the autofilled DNS servers that were
| there.
| JumpCrisscross wrote:
| > _could not browse with Safari or Mozilla_
|
| FYI, it looks like Firefox fixed this.
| zakki wrote:
| So not macOS error?
| JumpCrisscross wrote:
| > _not macOS error?_
|
| It worked before I upgraded to Sequoia. But I don't know
| enough to point fingers. Just mentioning that turning off
| the firewall long enough for Firefox to update fixes the
| problem.
| greyface- wrote:
| Were the autofilled DNS servers in RFC1918 private space
| (10.0.0.0/8, 192.168.0.0/16, etc.)? I had issues after the
| upgrade with Google Chrome being unable to access hosts in
| these ranges, and fixed it by going to System Settings ->
| Privacy & Security -> Local Network and toggling Google
| Chrome off and on again.
| garyrob wrote:
| No, they weren't local. I have no idea where they came
| from. I couldn't even delete them, but when I added the
| Google servers, they autofilled ones were automatically
| deleted.
| kccqzy wrote:
| They came from DHCP or RDNSS in RA.
| TechRemarker wrote:
| Before Sequoia when using OpenDNS for VPN, could be on VPN and
| iMessage and other apps still work, but since Sequoia, when on
| VPN iMessage (text messages) etc no longer work. Once I
| disconnect to VPN all goes through. Is this related at all? Do
| have macOS firewall enabled. But not block all incoming
| connections.
| lapcat wrote:
| I can't reproduce this. Some people say it has to do with ESET:
| https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
| zinekeller wrote:
| Confirmed, it is from an old ESET network filter:
| https://support.eset.com/en/alert8723-network-connection-
| los...
| bradgessler wrote:
| I've had issues using the Resolv library in Ruby when I'm
| connecting to the internet via a tethered iPhone. Never ran into
| that until Sequoia. I wonder if that's related?
|
| TBH I'm too lazy to dig in and find out. Has anybody else run
| into this issue?
| unluckier wrote:
| See: https://waclaw.blog/macos-firewall-blocking-web-browsing-
| aft...
|
| If disabling the firewall (for testing) solves this problem,
| this is likely your issue.
| elashri wrote:
| I maybe imagining but I feel like deja vu that there will be a
| problem with DNS that would affect Little snitch., Mullvad and
| others with new releases of iOS and Mac. If true I would really
| question what apple is doing during their months long developer
| and beta testing.
| mzs wrote:
| the (complicated) rules: man 5 resolver
|
| also try with a domain that exists
| Legion wrote:
| I always love the announcements of, "Bug found in new OS release!
| EDIT: Actually it's been there for a while!"
| lapcat wrote:
| Dupe: https://news.ycombinator.com/item?id=41568128
| kelnos wrote:
| It's a little weird to me that getaddrinfo() is considered a
| "low-level legacy API". Maybe things are drastically different on
| macOS, but getaddrinfo() is _the_ way to resolve names on Linux
| and I suspect the *BSDs.
|
| Sure, I expect most macOS apps will use something in Foundation
| or some other NetworkKit-type framework to do DNS queries, but
| it's odd to me that the code there wouldn't then call down to
| getaddrinfo() or the like to do the dirty work. I guess GAI is
| blocking, so presumably there's some other low-level non-blocking
| call?
| unethical_ban wrote:
| I'll pile on, as someone who has never developed for Apple
| systems: What APIs are supposed to be used for DNS resolution?
| * Host file * Configured DNS server * App-specific
| DNS server if it exists
|
| What "API" is there? Why doesn't an app doing system-wide DNS
| modifictions just modify the settings for default resolver?
| threeseed wrote:
| > This library wraps around the dnssd framework and the
| c-ares C library with Swift-friendly APIs and data
| structures.
|
| https://github.com/apple/swift-async-dns-resolver
| josephcsible wrote:
| It feels like Embrace, Extend, Extinguish to claim that a
| portable API is "legacy" and that its replacement is Apple-
| only.
| virtue3 wrote:
| no no, it's just "ours is better", "think different", and
| "it just works". /s
| tpmoney wrote:
| As near as I can tell, Apple doesn't call it a legacy
| API. The article does, but the article wasn't written by
| nor does it appear to be quoting Apple.
| threeseed wrote:
| You actually think that a Swift developer, developing
| against Cocoa APIs, targeting Mac and iOS devices cares
| about a portable API.
|
| Because not sure if you know this but the _entire_
| software industry is built on high level libraries on top
| of largely portable code. For example this Swift library
| wraps c-ares a portable API.
| kccqzy wrote:
| Well but the portable API is too low-level and error
| prone. What is the last time you used getaddrinfo? How
| often do you actually need to use it?
|
| One can make a good technical argument based on the merit
| of the portable API without immediately resorting to the
| EEE argument.
| o11c wrote:
| getaddrinfo isn't its predecessors, there's nothing
| error-prone about it. The only thing that's nontrivial is
| falling back if the first server is unresponsive, and
| even there the obvious calling code is fine for almost
| all apps.
| mzs wrote:
| That's what you use to create a utility like nslookup in
| swift, Apple does not want you to do any resolving
| yourself, just pass a hostname instead:
|
| https://developer.apple.com/documentation/network/nwendpo
| int...
| roywashere wrote:
| Yes, this! I even wonder how else you would do this. By the
| way I worked with many IoT devices that do not use your dhcp
| dns but just hardcode quad 8 or similar
| cj wrote:
| We recently had a developer join our team and he got stuck
| setting up his dev environment.
|
| We use a .dev domain as a localhost alias, and turns out
| his ISP's DNS wouldn't resolve 127.0.0.1 (or whatever it
| is) for the .dev domain. Changing his resolver at the
| network level to 1.1.1.1 fixed it.
|
| I imagine there are lots of difficult support tickets for
| app devs, and at a certain point they just hardcode the DNS
| to remove one variable from the equation when debugging bug
| reports.
| X-Istence wrote:
| Not resolving 127.0.0.1 or RFC1918 addresses or even ULA
| for IPv6 is done to avoid DNS rebinding attacks. For most
| end users that is probably the correct move.
| lxgr wrote:
| My home router even seems to inspect any UDP/53 traffic
| and redact any responses containing local/private A
| entries, so not even switching to a public resolver
| bypasses the protection.
|
| I agree that it's usually the right behavior.
| troyvit wrote:
| Wayyyy back in 1995 or '96 I was working for a non-profit
| called "Next Generation Magazine" and our goal was to
| have young people write content for web sites to get
| their names out there. Back then it was all local ISPs,
| so we went to our ISP and asked for ngm.org and were
| stoked when we got it! We built out the site (Thanks to
| Building Killer Websites of course) and it looked
| awesome!
|
| Only problem was that nobody in my family out of state
| could see it. It took awhile to realize realize that we
| never bought that domain. Our local ISP just added it to
| their DNS records, and since we all hooked into them we
| thought we were live across the 'net.
| mannyv wrote:
| Yes, things are drastically different on MacOS. There's like a
| whole nother level of APIs ip there
|
| /s
| krackers wrote:
| >so presumably there's some other low-level non-blocking call
|
| Correct, CFNetwork is open source so you can check
| implementation but last I remember it used some variant like
| `getaddrinfo_async`. But Apple really doesn't want you (the
| end-user) to use getaddrinfo (or the async variant CF exposes)
| to resolve an IP and then directly connect() via that ip,
| everything is geared towards connect-by-hostname since then
| Apple's can internally handle the implementation of happy-
| eyeballs.
|
| Edit: You can read
| https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf for
| their thoughts on why they don't like the getaddrinfo() model
| [there are speaker notes at the bottom of each slide]
| conradev wrote:
| If you do need the lower-level control, Apple does still
| recommend `getaddrinfo`. It handles NAT64 translation for
| IPv6-only carrier networks:
|
| https://developer.apple.com/library/archive/documentation/Ne.
| ..
| krackers wrote:
| I'm actually surprised they suggest getaddrinfo() directly
| over the async CF wrapper.
| mzs wrote:
| indeed: https://opensource.apple.com/source/Libinfo/Libinfo-2
| 22.1/lo...
| jmull wrote:
| > It's a little weird to me that getaddrinfo() is considered a
| "low-level legacy API"
|
| I don't think it is considered legacy. The blog post gets that
| wrong.
|
| (Whether it's "low-level" or not just depends on your
| perspective.)
| pushupentry1219 wrote:
| > Maybe things are drastically different on macOS, but
| getaddrinfo() is the way to resolve names on Linux and I
| suspect the *BSDs.
|
| I'm not sure if this is the case in this case, but it might be
| worth noting that some system functions with the same name have
| drastically different internal/implementation differences
| between Linux/*BSD/MacOS. With there being differences between
| the *BSDs too.
|
| So on some systems one function call is "the way", because its
| been maintained over the years, but then on another it might
| actually be old and not useful.
| whalesalad wrote:
| encryption adds latency, so this is a performance win.
| xd1936 wrote:
| yeah we should ban encryption everywhere
| zakki wrote:
| yeah, not macOS fault
| Avamander wrote:
| Deploying DNS encryption on macOS is in general really tedious.
| Applying it as a system or user profile has different results.
| Switching between providers or temporarily disabling DNS
| encryption is painful.
|
| I also still haven't figured out how to get SSID-based switching
| to work, does it even?
| Reason077 wrote:
| > _" To protect (DNS lookups) from prying eyes, Little Snitch 6
| offers a new feature: DNS encryption."_
|
| Browsers such as Firefox have offered this directly for a while.
| Of course, that only covers DNS lookups made from the web
| browser, but it doesn't rely on OS-level hooks that (at least in
| Apple's case) can break.
| Mainsail wrote:
| What am I missing here? Reading the article, it appears that
| Firefox is the browser that seems to be bypassing.
| Reason077 wrote:
| In this case they're using Little Snitch as an OS-level DNS
| proxy, which should intercept all DNS requests from any app
| and encrypt them. But, depending on what API the app uses for
| its DNS lookups, some DNS requests do not go via the proxy.
| Presumably Firefox, in its default configuration with DNS
| encryption set to OFF ("Use your default DNS resolver"), uses
| one the affected APIs.
| jedisct1 wrote:
| The standard way to use dnscrypt-proxy is to set the resolver to
| 127.0.0.1.
|
| Does Little Snitch do things differently?
| system7rocks wrote:
| Hmm. I use NextDNS for this feature. I think. May have to do some
| testing to see whether or not it is operational at all.
| tankenmate wrote:
| I use routedns [0] as my local stub resolver so that I can pick
| and choose which requests go to where and also what transport
| they use. It can also blocklist, re-write, cache, load balance,
| and/or handle fall back requests; so it give you lots of control.
|
| I use a stub listener on localhost:53 for local requests and then
| forward them via UDP QUIC (TLS 0-RTT) requests to Cloudflare
| (1.1.1.1) with caching for most requests. Fast and reasonably
| secure.
|
| [0] https://github.com/folbricht/routedns
| ggm wrote:
| "Mac OSX has complex paths into name-to-address translation and a
| single entrypoint is not well enforced."
|
| this is not "bypass encryption" this is "uses a range of ABI/API
| bindings in code which don't expose well into a single control
| point"
| pkilgore wrote:
| My read of this is that it shouldn't affect pi.hole given the
| system's default nameserver would still received by DDNS and thus
| be the pi.hole? Or do these requests go somewhere that's hard-
| coded?
| tpmoney wrote:
| No this appears to be if an application registers a DNS
| resolver proxy on the local system, getaddrinfo doesn't use the
| proxy, and presumably just hits whatever the network
| interface's configured DNS server is.
___________________________________________________________________
(page generated 2024-09-17 23:00 UTC)