Date: Sat, 26 Nov 2005 16:41:01 GMT From: Jon Passki <cykyc@yahoo.com> To: freebsd-gnats-submit@FreeBSD.org Subject: conf/89589: virecover follows hardlinks, possibly exposing sensitive data under certain circumstances Message-ID: <200511261641.jAQGf1R0051062@www.freebsd.org> Resent-Message-ID: <200511261650.jAQGo2Om024977@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 89589 >Category: conf >Synopsis: virecover follows hardlinks, possibly exposing sensitive data under certain circumstances >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 26 16:50:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Jon Passki >Release: RELENG_6, RELENG_5 >Organization: Caffeinated Systems >Environment: >Description: etc/rc.d/virecover does not contain a check to see if the recovery file is a link (symbolic or hard). Upon the run of virecover (only boot time or when specifically ran), the following need to be met: --) there is a file in /var/tmp/vi.recover, starting w/ vi.* that is not zero length, is readable, and is not executable --) there is a file in /var/tmp/vi.recover, starting w/ recover.* that is readable and contains the string "^X-vi-recover-path: ", pointing to a file that is non-zero --) virecover is only ran at boot time or explicitly by the sysadmin --) the recover.* file is processed by 'sendmail -t', which requires a valid "To:", "CC:", or "BCC:" entries before a linebreak. A specific attack would be a local user hard linking (tested) or soft linking (can't recall testing) against root's mail queue file. When virecover ran, whomever the first recipient was in the queue (usually root, but could possibly contain other addressees) would receive all of the queue file (assuming mail queue files are in use). A side effect is sendmail doesn't like hardlinked mail queues, so this may bounce (which will just bounce back into the mail queue, odd). Also, the attacker could view all the queues that increased by root's queue size, possibly determining any local accounts that now contain root's queue. >How-To-Repeat: See above. Due to the preconditions, this is being reported as a bug versus directly w/ the security team. >Fix: Possibly use stat and other magic to determine the following on the recover.* file (in order author thinks are strong checks): --) X-vi-recover-path string points to a file owned by the user of the recover.* file --) X-vi-recover-path string points to /var/tmp/vi.recover/ --) It is not a hard link --) It is not executable >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511261641.jAQGf1R0051062>