On Sat, 2006-10-21 at 03:12 +0200, Frank Ellermann wrote: > Douglas Otis wrote: > > > Ten or eleven SPF records can be chained, where each set may contain > > 10 mechanisms > > 10 chained records => 10 "include" or "redirect" => limit of 10 reached. > The next contained mechanism - anything more elaborated than an "ip4", > "ip6", or "all" - results in a PermError.
Many SPF RRs have wildcard labels. A series of 10 subsequent SPF RR transactions with random sub-domains (enabled with SPF local-part macros) will never be found in DNS cache. Multiply this sequence by each message name being resolved, multiply again for each instance within the message path where an SPF check is made (MTAs & MUAs), and multiply again for each recipient receiving the message. These transactions can be destructive by targeting DNS while not producing an error. The initial SPF RR can also point to any large TXT records causing fragmentation in a manner similar to the EDNS0 exploit. Terminate the initial SPF RR with "+all" as does Bell Canada, and the attack provides a "PASS" without wasting a mechanism. Invoking an error may actually cause another SPF RR transaction to occur. > > each mechanism may then invoke up to 10 additional DNS transactions > > The two mechanisms doing that are "ptr" and "mx", and "ptr" depends on > the IP of the SMTP client. That leaves "mx" as the only mechanism for > this consideration. This is making assumptions about the nature of an attack. However, a redirected attack is likely to utilize the SPF MX mechanism for the greatest gain and flexibility. > > Each name resolved using SPF may target a victim not seen anywhere > > within the message with 100 DNS transactions. > > The attacker can construct a policy with 10 "mx" mechanisms, with 10 > fabricated names per MX in the attacked domain. The attacker won't > send the IPs of those names in the q=mx reply by his name server, so > that results in 100 queries to the name server of the attacked domain. > > After that the SMTP server in question has these 100 answers cached. Review the attack outlined in the draft. About 70% of spam is from compromised systems, often sent in concert at a low rate. Resolving a name with SPF may invoke more than 100 targeted DNS transactions. Some SPF libraries take shortcuts and do not limit subsequent MX address resolutions or even the number of mechanisms, using recursion limits and time-outs instead. To ascertain the impact, the overhead must be multiplied by each name being resolved, multiplied again by each instance within the message's path where an SPF check is made, and multiplied again by the number of recipients. A query made for 100 non-existent address records still provides 64:1 amplification for one name, one instance, and one recipient. (There are techniques to increase this gain, but not covered by the draft.) This gain is multiplied by the number of names, instances, and recipients. The amplification of this exploit can exceed 1000:1 and even 10,000:1, where including DKIM names substantially increases risks, as there is no limit on the number of DKIM signatures per message. With extremely high amplification and a likelihood that message sources are measured in the tens of thousands, the rate of messages being sent by each source can be extremely low and virtually impossible to detect. The victim will not be evident in any SMTP log. Each message can use different and unrelated originating domains, and still target the same victim. Repeating a query for the same non-existent address only needs to be delayed by the duration of negative caching. The high amplification and low send rates means this negative caching delay for a sustained attack may permit recycling (repeating the local-part used by the trigger message) after a set of a dozen messages. When done in concert, spam is still sent without affecting its delivery. Although not apparent at the source, the resulting attack may still taking down backbone connections, disable any number of DNS servers, and poison any number of DNS resolvers. Efforts directed toward BCP38 and ACLs for recursive DNS resolvers offer no protection from this threat. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
