From nobody@FreeBSD.org  Sat Nov 26 16:41:02 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6588216A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Nov 2005 16:41:02 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id E252F43D6A
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Nov 2005 16:41:01 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id jAQGf1wJ051063
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Nov 2005 16:41:01 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id jAQGf1R0051062;
	Sat, 26 Nov 2005 16:41:01 GMT
	(envelope-from nobody)
Message-Id: <200511261641.jAQGf1R0051062@www.freebsd.org>
Date: Sat, 26 Nov 2005 16:41:01 GMT
From: Jon Passki <cykyc@yahoo.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: virecover follows hardlinks, possibly exposing sensitive data under certain circumstances
X-Send-Pr-Version: www-2.3

>Number:         89589
>Category:       conf
>Synopsis:       virecover follows hardlinks, possibly exposing sensitive data under certain circumstances
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    secteam
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 26 16:50:02 GMT 2005
>Closed-Date:    Sun Jul 01 16:04:36 UTC 2012
>Last-Modified:  Sun Jul 01 16:04:36 UTC 2012
>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:
Responsible-Changed-From-To: freebsd-bugs->secteam 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Mon Dec 12 10:36:17 UTC 2005 
Responsible-Changed-Why:  
For security team evaluation. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89589 
State-Changed-From-To: open->analyzed 
State-Changed-By: csjp 
State-Changed-When: Mon Jul 16 14:08:12 UTC 2007 
State-Changed-Why:  
Sorry for the delay on this. I am not sure what the issue is 
here, virecover doesn't actually provide any data from the file 
to the user at all. Also, it doesn't matter which user created 
the file (or in this case, the hard link) because virecover 
does not get user information from file ownership. 

This information is stored by vi when it generates the recover 
file. Since vi appears to create it's temp file names, I do not 
see any issue here. 

I've put this PR into "analyzed" state to allow anyone to point 
out something that I might be missing. 

Thanks for the report! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89589 
State-Changed-From-To: analyzed->closed 
State-Changed-By: eadler 
State-Changed-When: Sun Jul 1 16:04:35 UTC 2012 
State-Changed-Why:  
closed per csjp - I have not analyzed the issue 

http://www.freebsd.org/cgi/query-pr.cgi?pr=89589 
>Unformatted:
