Re: maybe this is a dumb question
I missed the first couple of articles on this thread so I don't have them to quote, sorry. I read them on the archive at yahoo though. I expectantly await J. Fennalson's investigation. May even try my own emperical testing. Here are the two thoughts I had when reading Chris' original posting. 1. There has been a discussion in the past that restores to the original location will even remove existing files because the restoration/recovery is to the state as of a specific date. So if on day 1 (a level 0) the file existed but on day 2 (an incremental) it did not, a restore to day 2's date would first put the file there, then (from the level 0 tape) then remove it because of the incremental. That discussion arose because some amanda user, in my above scenario, manually recreated the file on day 3, only to find it removed by the recovery process. An action they felt was incorrect. I think the recovery may affect the properties of files as well as existance. So the permissions would be changed to those that existed as of the date specified in the recovery. Maybe even file types?? In Chris' (and the student's) scenario, if all the above is correct then it seems to me that a) if the recovery date was day 1, just the soft linke would be recovered - no problem b) if the recovery date was day 2, the soft link would be converted to a directory (as it was on day 2) and the files placed in there, not /usr/bin. Time to read code and test :) 2. Supposing the worst, the /usr/bin/passwd file would be trashed, a bad event in itself. But for the specific example it would not be a further security breach for attacks on the password file as the ownership and permissions would also be set to those existing at the backup time. Namely, owned by the user, not root, and setuid'ed to the user, not root. Those permissions would not let anyone change their password (hopefully). Ahh, but what if the users also did the same exploit (assuming it works) for the /etc/password and shadow files. Whoops, can't copy the shadow file, but it a mimic'ing copy could be hand-crafted. Then, if the exploit worked, the user would own the password and shadow files and have installed a program that could change them. Security, nasty stuff, but someone told me I have to do it :) BTW I, like others, only recover/restore to an empty space and copy what I want to the actual location after examining it. Except once recently when I wanted an entire FS recovered to a newly created (thus fresh and empty) partiton. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: maybe this is a dumb question
Jay Lessert <[EMAIL PROTECTED]> wrote: > That does it, right? Doesn't matter what file system or what host the > the amrecover is run on, I've got /bin/ls on that box when it's done > (subject to my qualifiers re: OS and program earlier in the thread). Not if I restore each incremental into a different temp directory /home/joebob/restore1/src (the softlink) /home/joebob/restore2/src (the directory containing ls) It is then up to the user to move the src (either the softlink or the directory back into their home. And if they try to move the softlink, then move the file into it, well, they don't have the proper permissions to accomplish what they want. or am I missing something? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Chris Barnes AOL IM: CNBarnes [EMAIL PROTECTED]Yahoo IM: chrisnbarnes Computer Systems Manager ph: 979-845-7801 Department of Physics fax: 979-845-2590 Texas A&M University
Re: maybe this is a dumb question
On Wed, Aug 27, 2003 at 12:54:12PM -0500, Chris Barnes wrote: > Jay Lessert <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 27, 2003 at 01:33:01PM -0400, Jeremy L. Mordkoff wrote: > >> My policy is to never restore files in place. > > > > I agree that is a good practice (doesn't prevent Chris' student's > > proposed exploit, though). > > Actually, I think it might. Chris, I don't remember your exact example, but not in all cases (unless I'm missing something obvious...): #!/bin/sh cd /home/joebob/src ln -s /bin sleep 86400 rm bin mkdir bin cp -p /home/joebob/bin/my_ls bin/ls sleep 86400 rm -r * mail -s "restore request" [EMAIL PROTECTED] <<'EOMESSAGE' Dear helpful admin, I accidentally did an 'rm -r *' on my src directory this morning: /home/joebob/src Could you please restore it? Thanks! -Joebob- EOMESSAGE That does it, right? Doesn't matter what file system or what host the the amrecover is run on, I've got /bin/ls on that box when it's done (subject to my qualifiers re: OS and program earlier in the thread). -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: maybe this is a dumb question
Jay Lessert <[EMAIL PROTECTED]> wrote: > On Wed, Aug 27, 2003 at 01:33:01PM -0400, Jeremy L. Mordkoff wrote: >> My policy is to never restore files in place. > > I agree that is a good practice (doesn't prevent Chris' student's > proposed exploit, though). Actually, I think it might. If we restore to a temporary location, then the /etc/passwd (from my previous example) won't be overwritten. The malicious user couldn't move it manually (since they wouldn't have write permissions through the softlink). -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Chris Barnes AOL IM: CNBarnes [EMAIL PROTECTED]Yahoo IM: chrisnbarnes Computer Systems Manager ph: 979-845-7801 Department of Physics fax: 979-845-2590 Texas A&M University
Re: maybe this is a dumb question
On Wed, Aug 27, 2003 at 01:33:01PM -0400, Jeremy L. Mordkoff wrote: > My policy is to never restore files in place. I agree that is a good practice (doesn't prevent Chris' student's proposed exploit, though). -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
RE: maybe this is a dumb question
My policy is to never restore files in place. I always restore to a temporary location and ask the owner to copy the file into place. That avoids any stickiness. I remember a case where someone asked to have a file restored, but it was only to do a diff. The restore was done "in place", so afterwards they had the old file, but the new file was gone, which was not an improvement. So this policy protects against stupidity and malice. JLM Jeremy Mordkoff Tatara Systems 978-206-0808 (direct) 978-206-0888 (fax) injustice anywhere threatens justice everywhere -- Dr. Martin Luther King -Original Message- From: Jay Lessert [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 1:15 PM To: Chris Barnes Cc: [EMAIL PROTECTED] Subject: Re: maybe this is a dumb question On Tue, Aug 26, 2003 at 10:34:49AM -0500, Chris Barnes wrote: > The concern is that when a restore is run, the softlink to the /usr/bin > directory will be recreated, then the file will be restored into that > directory, overwriting the file that is supposed to be there (ie. > creating a security issue). > > 1) Is this possible, or does Amanda already do something to prevent > this? Chris, Give your student worker a cookie (or a beer if they're old enough). Though this isn't a new exploit technique, it sure looks to me like if one: - Uses 'program "DUMP"' - Uses amrecover Then your proposed exploit would work. extract_files_child() in extract_list.c just calls 'restore x', and I just tested that ufsrestore (Solaris) will behave exactly as you describe. If instead you run: amrestore | ufsrestore r you're safe, though this is not so convenient for partial restores. :-) I did not test from inside amrecover; if there is deep magic there I am missing, I'd like to hear about it. From an Amanda point of view, this is an issue with 'program', not with Amanda, of course. I did not test 'tar -xpG' (that's how amrecover calls GNU tar). > 2) If it is possbile, are there any security considerations we need to > take into consideration when running backups or restore jobs? Yes. :-) I'm *really* glad I don't admin a student or ISP environment! If I did, I would tripwire everything, I guess. - Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: maybe this is a dumb question
On Tue, Aug 26, 2003 at 10:34:49AM -0500, Chris Barnes wrote: > The concern is that when a restore is run, the softlink to the /usr/bin > directory will be recreated, then the file will be restored into that > directory, overwriting the file that is supposed to be there (ie. > creating a security issue). > > 1) Is this possible, or does Amanda already do something to prevent > this? Chris, Give your student worker a cookie (or a beer if they're old enough). Though this isn't a new exploit technique, it sure looks to me like if one: - Uses 'program "DUMP"' - Uses amrecover Then your proposed exploit would work. extract_files_child() in extract_list.c just calls 'restore x', and I just tested that ufsrestore (Solaris) will behave exactly as you describe. If instead you run: amrestore | ufsrestore r you're safe, though this is not so convenient for partial restores. :-) I did not test from inside amrecover; if there is deep magic there I am missing, I'd like to hear about it. From an Amanda point of view, this is an issue with 'program', not with Amanda, of course. I did not test 'tar -xpG' (that's how amrecover calls GNU tar). > 2) If it is possbile, are there any security considerations we need to > take into consideration when running backups or restore jobs? Yes. :-) I'm *really* glad I don't admin a student or ISP environment! If I did, I would tripwire everything, I guess. - Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: maybe this is a dumb question
On Tue, Aug 26, 2003 at 10:34:49AM -0500, Chris Barnes wrote: > One of my student workers - who happens to be setting up Amanda, > recently came to me with a concern about how the backup/restore process > handles soft links. I suspect that this is a non-issue in that Amanda > has already figured out a way to deal with this, but just in case... > > Let's say a user creates a soft link in their home directory that points > to > /usr/bin, eg: > > lrwxrwxrwx 1 cbarnes barnes 15 July 1 13:35 mybin -> /usr/bin/ > > Then the backups of the home are run. > > Then the user removes the softlink and creates a real directory with > that same name. > > drwxr-xr-x 2 cbarnes barnes 4096 Aug 18 17:23 mybin > > and then puts a modified program into that directory: > > drwxr-xr-x2 cbarnes barnes 4096 Aug 18 17:23 ./ > drwxr-xr-x 13 cbarnes cbarnes 4096 Aug 25 17:31 ../ > -r-s--x--x1 cbarnes barnes 7667 Aug 18 17:26 passwd* > > and backups are run again. > > > The concern is that when a restore is run, the softlink to the /usr/bin > directory will be recreated, then the file will be restored into that > directory, overwriting the file that is supposed to be there (ie. > creating a security issue). > > > 1) Is this possible, or does Amanada already do something to prevent > this? > 2) If it is possbile, are there any security considerations we need to > take into consideration when running backups or restore jobs? Amanda doesn't do anything about this--it just calls the underlying backup mechanism (guntar or dump) to do the dirty work. It's up to the underlying backup mechanism to handle this. So the right people to be asking a question like this are the gnutar maintainers or the dump maintainers. It's been too long since I wrote gnutar for me to remember how it handles cases like this. You should ask a more current maintainer. A similar attack would be to have a directory "mybin" containing a file "passwd" before a dump is done. Then replace "mybin" with a symbolic link to "/bin" and request a restore of "mybin/passwd". I'll check out both of these scenerios and report back on what I find. -- JF
