From owner-freebsd-security Thu Feb 13 15:04:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA16723 for security-outgoing; Thu, 13 Feb 1997 15:04:53 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA16716 for ; Thu, 13 Feb 1997 15:04:48 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vvABU-0001Vm-00; Thu, 13 Feb 1997 16:03:20 -0700 To: Julian Assange Subject: Re: trusting dns addresses Cc: security@freebsd.org In-reply-to: Your message of "Fri, 14 Feb 1997 09:37:31 +1100." <199702132237.JAA00545@profane.iq.org> References: <199702132237.JAA00545@profane.iq.org> Date: Thu, 13 Feb 1997 16:03:20 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702132237.JAA00545@profane.iq.org> Julian Assange writes: : > This attack requires there to be a bug in the resolver in order to even : > have a chance of succeeding. If that were the case, better to fix the : > resolver than to fix all places in the source tree where it returns : > data. : : I strongly disagree with this view. The problem should be fixed in : both places. Trusting a protocol independent resolver to always : return 4 byte addresses is nothing but bad programming. In fact, at : the moment, despite the additional length checks, it can return 16 byte : ipv6 addresses. No doubt as other protocols are added in the future : we will see other lengths. This was the point that I missed. I didn't think it was possible to have anything but a 4 byte quantity in an A record which is returned. Are you saying that gethostbyname will return AA records as well as A records? Wow, that sounds like a bug to me. However, that's the sort of thing that attackers might take advantage of... : It's bad. Its shoddy. It is a security hole now and likely one into : the future and across domains. It breaks encapsulation. It needs : be addressed. This is more of a defensive programming issue rather than a known hole exploit fix. the current sockaddr_in structure has 8 bytes of padding on the end, which will cause at most 4 extra bytes to be written outside of the buffer. I have trouble seeing how one would exploit that. Wouldn't be be better to issue a diagnostic and halt (for programs) or return -1/NULL (for libs) than to truncate the reply and keep going? In any event, it is sloppy and wouldn't hurt to fix, especially given the patches that you've submitted. Warner