Date: Tue, 7 Jan 2003 21:09:57 +0100 (CET) From: System Administrator <root@asarian-host.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/46838: security vulnerability in dump Message-ID: <200301072009.H07K9VMJ000670@asarian-host.net>
next in thread | raw e-mail | index | archive | help
>Number: 46838 >Category: bin >Synopsis: security vulnerability in dump >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Jan 07 12:20:01 PST 2003 >Closed-Date: >Last-Modified: >Originator: Superuser >Release: FreeBSD 4.7-RELEASE i386 >Organization: Asarian-host >Environment: System: FreeBSD asarian-host.net 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Sat Nov 30 17:01:16 CET 2002 root@asarian-host.net:/usr/obj/usr/src/sys/ASARIAN-HOST i386 >Description: I believe I have found a security vulnerability in dump, which, under the right conditions, allows any user with shell-access to gain root-privileges. When dumping to a file, dump writes this file chmod 644. When the root-partition is being backed-up, this leaves the dump-file vulnerable to scanning by unprivileged users for the duration of the dump. I tested this, and, as a non-privileged user, was able to extract the root-password from the dump-file using a simple regex: "(/root:(.*?):0:0::0:0:Superuser:/)". This, of course, based on the fact that /etc/master.passwd also becomes part of the dump-file. My greater point would be that the "run-length" storage of dump, since the file is chmod 644, effectively renders all files it backups world-readable as it passes them along for processing. At least for the duration dump is running (assuming a backup-script would be sensible enough to change permissions directly thereafter). As to how high to rank this exploitability, I am not entirely sure; but I lean to deeming it high, because once the eploit is known, exploiting it is rather easy. Certain conditions need to be met. The dump must be made to file, and the unprivileged user must, naturally, know the name of the dump-file; and the dump, of course, must be made in multi-usermode. >How-To-Repeat: make a dump to file. :) >Fix: The fix, fortunately, is very easy: if the FreeBSD development team made a small adjustment to dump, writing its dump-file chmod 600, then this would immediately solve any and all exploitability. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301072009.H07K9VMJ000670>