From owner-freebsd-security Mon Apr 29 16:31:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA22658 for security-outgoing; Mon, 29 Apr 1996 16:31:45 -0700 (PDT) Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA22649 for ; Mon, 29 Apr 1996 16:31:37 -0700 (PDT) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id AAA11207; Tue, 30 Apr 1996 00:30:39 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Tue, 30 Apr 96 0:28:44 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 29 Apr 96 23:28:42 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Mon, 29 Apr 96 23:28:42 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:21237-960429232842-6570] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Mon, 29 Apr 96 23:28:42 +0000 Content-Identifier: Re: CERT Advisor Message-Id: <"11363-960429232834-79C3*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: cschuber@orca.gov.bc.ca, freebsd-security@freebsd.org In-Reply-To: <"SunOS:5836-960429012804-059C*/DD.RFC-822=owner-security(a)FreeBSD.ORG/O=internet/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/"@MHS> Subject: Re: CERT Advisory CA-96.09 - Vulnerability in rpc.statd Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The following CERT Advisory documents a vulnerability in rstatd. It also > states that BSD/OS is not vulnerable. Considering BSD/OS' and FreeBSD's > common heritage, would FreeBSD also be not vulnerable? > Topic: Vulnerability in rpc.statd ^^^ Actually, this is rpc.statd not rpc.rstatd. None of the -release versions contain any sort of rpc.statd at all, so are obviously not vulnerable. The version of rpc.statd in -current was written by me, and I do not believe it suffers from this. I find the wording of the advisory to be somewhat confused, seeing as the rpc.statd protocol doesn't pass any filenames at all, but my understanding of the problem is: - Most (Sun-derived) implementations store the status for remote hosts in a bunch of very small files /var/somewhere/ - The protocol does not prescribe any particular relationship between the hostname supplied in text in the protocol and the IP address from which the request came, and in any event the initial request is proxied through the local rpc.lockd so the statd doesn't get to see the original packet [this is the bit where I find the advisory to be confused]. - If you come along claiming that your hostname is "../../etc/passwd" and the rpc.statd is fool enough to believe you, it will go and store your status in that file. My implementation does not use one file per host, so does not suffer from this - I have one large file containing the host names and their statuses which I mmap(). Arguably my way is less efficient for very large numbers of client hosts, though I am now quite glad I did it that way. BTW - I never see FreeBSD quoted as a 'vendor' on these things. Is this because CERT doesn't recognise FreeBSD as a vendor, or just because there is no effort available to liase with CERT? Andrew. [PS. I promise to get back to work on the rpc.lockd when I get some vacation time this summer...]