From owner-freebsd-security Thu Feb 20 10:05:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA27039 for security-outgoing; Thu, 20 Feb 1997 10:05:28 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA27034 for ; Thu, 20 Feb 1997 10:05:23 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vxcrh-0007cg-00; Thu, 20 Feb 1997 11:05:05 -0700 To: Andrew Kosyakov Subject: Re: Coredumps and setuids .. interesting.. Cc: marcs@znep.com, security@freebsd.org In-reply-to: Your message of "Thu, 20 Feb 1997 14:31:06 +0300." <199702201131.OAA14947@magrathea.chance.ru> References: <199702201131.OAA14947@magrathea.chance.ru> Date: Thu, 20 Feb 1997 11:05:04 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199702201131.OAA14947@magrathea.chance.ru> Andrew Kosyakov writes: : So, you mean that someone may want to add an ability for an : unprivileged process to attach to the address space of a privileged : process? Well, certainly, there will be such people, but I guess : they'll have to break freefall again in order to implement that :-) : (sorry if you consider this joke to be rude). If you look at the ptrace code in 2.1.7 you'll notice that the checks for attaching to a process don't take into account that the process may have once been owned by root. This would allow a person who started, say, ftp to attach to the ftpd process once he'd logged in as himself and grab passwords. The attach functionality in 2.1.7 was broken in other ways, so it wasn't actually enabled, so the 2.1.7 systems aren't volunerable to this attack (and -current does the right thing). While it makes sense to fix these sorts of problems as they are discovered, it also makes sense to destroy sensitive data when you are done with it so that if an unknown system problem exists that causes this information to be disclosed to a third party, the window for doing so is shortened and closed completely for as many of the cases as possible. That's what I'm saying. : And I'd like to ask again: is there an official patch for 2.1.* to disable : P_SUGID process to dump core? Many people can't afford to upgrade the whole : OS on their production machines :-( David already sent this out, but you really should be tracking -stable, or at least upgrade to 2.1.7. Many security related fixes have come down the pipe, some quietly, and you really want to have all of them in a production machine that has users that aren't 100% trusted or that is accessible to the internet. Warner