Re: libspf2 crash

On a final note (and just for the record), here is the GDB output required to 
prove this was the issue:

(gdb) bt
#0  0x00bab7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00bec815 in raise () from /lib/tls/libc.so.6
#2  0x00bee279 in abort () from /lib/tls/libc.so.6
#3  0x08065638 in segfault_handler (received_signal=11) at common/signals.c:36
#4  <signal handler called>
#5  0x00d7ae88 in __ns_name_skip () from /lib/libresolv.so.2
#6  0x00d742dc in __dn_skipname () from /lib/libresolv.so.2
#7  0x0065e205 in __ns_skiprr (ptr=0xb3caae21 "", eom=0xb3caae21 "", 
section=ns_s_an, count=-1278574864) at __ns_initparse.c:84
#8  0x0065e37e in __ns_initparse (msg=0xb3ca8862 "�\f", msglen=9697, 
handle=0xb3ca8810) at __ns_initparse.c:124
#9  0x00657a19 in SPF_dns_resolv_lookup (spf_dns_server=0xb3e3330, 
domain=0xb7a46c18 "citylinenews.com", rr_type=ns_t_mx, should_cache=1)
     at spf_dns_resolv.c:188
#10 0x00656dbc in SPF_dns_lookup (spf_dns_server=0xb3e3330, domain=0xb7a46c18 
"citylinenews.com", rr_type=ns_t_mx, should_cache=1)
     at spf_dns.c:114
#11 0x0065737c in SPF_dns_cache_lookup (spf_dns_server=0xb3e3358, 
domain=0xb7a46c18 "citylinenews.com", rr_type=ns_t_mx, should_cache=1)
     at spf_dns_cache.c:387
#12 0x00656dbc in SPF_dns_lookup (spf_dns_server=0xb3e3358, domain=0xb7a46c18 
"citylinenews.com", rr_type=ns_t_mx, should_cache=1)
     at spf_dns.c:114
#13 0x0065b60f in SPF_record_interpret (spf_record=0xb7a92358, 
spf_request=0xb7a5bd28, spf_response=0xb7a928b0, depth=0)
     at spf_interpret.c:778
#14 0x0065cfc3 in SPF_request_query_record (spf_request=0xb7a5bd28, 
spf_response=0xb7a928b0, spf_record=0xb7a92358, err=SPF_E_SUCCESS)
     at spf_request.c:224
#15 0x0065d02c in SPF_request_query_mailfrom (spf_request=0xb7a5bd28, 
spf_responsep=0xb3ca924c) at spf_request.c:255
#16 0x08069484 in smtp_check_spf (session=0xb3ca9320) at smtp/smtp_spf.c:136
#17 0x0805dd55 in smtp_process_rcptto (session=0xb3ca9320) at 
smtp/smtp_process_connection.c:407
#18 0x0805f39d in smtp_process_connection (session=0xb3ca9320) at 
smtp/smtp_process_connection.c:1260
#19 0x0806520c in worker_thread () at common/worker.c:84
#20 0x00da33cc in start_thread () from /lib/tls/libpthread.so.0
#21 0x00c8e1ae in clone () from /lib/tls/libc.so.6
(gdb) frame 9
#9  0x00657a19 in SPF_dns_resolv_lookup (spf_dns_server=0xb3e3330, 
domain=0xb7a46c18 "citylinenews.com", rr_type=ns_t_mx, should_cache=1)
     at spf_dns_resolv.c:188
(gdb) print dns_len
$1 = 9697
(gdb) print sizeof(response)
$2 = 2048
(gdb) quit

Note that 9697 is greater than 2048.

Ladar Levison wrote:
> I believe I've tracked down the issue. It has to do with 
> SPF_dns_resolv_lookup(), and where it calls res_nquery(). Basically 
> res_nquery() is returning 5600, a length greater than sizeof(response), 
> which is a hard coded buffer size of 2048. Once the __ns_skiprr function 
> reads past the 2048 bytes, your reading random data which is what's 
> causing segfaults (and the Valgrind errors).
> 
> The solution is two fold. Increase the buffer size to 8196, and then 
> check whether the return value of res_nquery() is less than 8196. If 
> dns_len is greater than 8196, set it to 8196.
> 
> I believe what's happening, and I'd like confirmation on this, is 
> res_nquery() is returning the amount of data it could read if the buffer 
> length was sufficient. Its the client's responsibility to check whether 
> this is greater than the buffer size (something libspf2 isn't doing). 
> Anyone else have thoughts on this?
> 
> I'm running on CentOS 4.6.
> 
> Ladar Levison wrote:
>> If you execute the attached code right now (Tuesday, 12:30am) you'll 
>> be able to reproduce the crash. Note that these spammer domains 
>> disappear often, so I'm not sure how long this will last. Also note 
>> I'm loading the library dynamically, so update the code accordingly. 
>> The Valgrind output is:
>>
>> ==22263== Conditional jump or move depends on uninitialised value(s)
>> ==22263==    at 0x555E8E: __ns_name_skip (in /lib/libresolv-2.3.4.so)
>> ==22263==    by 0x54F2DB: __dn_skipname (in /lib/libresolv-2.3.4.so)
>> ==22263==    by 0x40166BF: __ns_skiprr (__ns_initparse.c:83)
>> ==22263==    by 0x4016839: __ns_initparse (__ns_initparse.c:123)
>> ==22263==    by 0x400F3D4: SPF_dns_resolv_lookup (spf_dns_resolv.c:188)
>> ==22263==    by 0x400E5E6: SPF_dns_lookup (spf_dns.c:114)
>> ==22263==    by 0x4013513: SPF_record_interpret (spf_interpret.c:778)
>> ==22263==    by 0x4015289: SPF_request_query_record (spf_request.c:224)
>> ==22263==    by 0x401530B: SPF_request_query_mailfrom (spf_request.c:255)
>> ==22263==    by 0x8048623: main (main.c:134)
>>
>> I'll continue to investigate, and if I come up with a patch, I'll post 
>> it.
>>
>>
>>
>