[dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
list-dns-operations at dragon.net
Wed Aug 18 01:02:12 UTC 2021
dukhovni> A client using 18.104.22.168 as its iterative resolver and
dukhovni> delegating all input validation to that upstream becomes
dukhovni> vulnerable not only to data forgery, but also to validation
dukhovni> bypass if an MiTM pretending to be 22.214.171.124 returns unvalidated
In a perfect world, sure. But the reality is that much of the world's
devices use their ISP or google or their company resolver and accept
whatever those resolvers say without doing validation in the OS.
dukhovni> The only stub resolver one can expect to not be bypassed is
dukhovni> the stub resolver in the OS libraries. These stub resolvers
dukhovni> vary from OS to OS, and don't get a lot of maintainer
And that lack of love is why expecting the OS stub to be the good actor
isn't a quick fix.
dukhovni> So whether you like it or not, the burden is on the
dukhovni> application, and any higher level libraries known to deliver
dukhovni> syntactically validated results.
Nothing to do with what I like. It's what the majority of the world does
that we have to deal with.
Asking the world to do better is worth trying but how many OS stub
resolvers validate? How many in-browser stubs validate?
On the other side, how many apps just take whatever the OS stub hands
them and how many OS stubs just take whatever the upstream resolver
hands them? We can't ignore reality and we must do what we can now.
More information about the dns-operations