From owner-freebsd-security Sun Jun 21 23:24:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27972 for freebsd-security-outgoing; Sun, 21 Jun 1998 23:24:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27664; Sun, 21 Jun 1998 23:23:31 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA16784; Sun, 21 Jun 1998 23:19:50 -0700 (PDT) Message-Id: <199806220619.XAA16784@implode.root.com> To: Nicholas Charles Brawn cc: security@FreeBSD.ORG, bde@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: non-executable stack? In-reply-to: Your message of "Sat, 20 Jun 1998 21:21:14 +1000." From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Jun 1998 23:19:50 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I was pondering the following after reading about solaris 2.6's >non-executable stack option. > >1. How feasible is it to implement a non-executable stack kernel option? >2. If it *is* feasible, what do people think of a sysctl-based interface >to enable/disenable it? >3. If both 1 & 2 were implemented, how about making it impossible to >disenable at say.. securelevel >= 1? > >If I remember the discussions on bugtraq right, a non-exec patch isn't a >cure-all for buffer overflow attacks. However it would be an overall >security enhancement and prevent many script-based attacks. > >What are peoples thoughts on this? I believe that making the stack non-exec will break the signal trampoline in FreeBSD. Although this may have changed in recent times without me noticing. Bruce? Peter? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jun 23 09:24:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12860 for freebsd-security-outgoing; Tue, 23 Jun 1998 09:24:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12842 for ; Tue, 23 Jun 1998 09:24:19 -0700 (PDT) (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id MAA19313 for ; Tue, 23 Jun 1998 12:18:10 -0400 (EDT) Date: Tue, 23 Jun 1998 12:24:16 -0400 (EDT) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: freebsd-security@FreeBSD.ORG Subject: adduser chmod permissions Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1125508220-898619056=:4022" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1125508220-898619056=:4022 Content-Type: TEXT/PLAIN; charset=US-ASCII I've sent this to a couple of people now. This pertains to adduser on 3.0-current. I havent checked on a 2.2x adduser. I'm wondering what purpose if any the perms on "other" have in adduser. adduser is set to o=-w. Why by default should adduser allow home directories to be executable and read by "others". I mean if the default policy of IPFW is to default to closed, and the admin has to choose to open up his server, shouldnt the default for adduser be to create home dirs closed to "others" and the user has to open them up? Makes sense to me anyway. I think having adduser have ANY perms on other brekas the man page. "UNIQUE GROUPS Perhaps you're missing what can be done with this scheme that falls apart with most other schemes. With each user in his/her own group the user can safely run with a umask of 002 and have files created in their home directory and not worry about others being able to read them." To me that means give the user his own unique group name like user foo group foo, and then perms on other should be ---, so that only user foo can read,w,x files and group foo can read and execute files. Thats how I read it anyway. Unless there is some reason /home dir's need to be "rx" for "other" that I can't seem to find. I attached a patch to adduser to chmod o=-rwx. As I think it should be. Chris -- "Linux... The choice of a GNUtered generation." ===================================| Open Systems Networking And Consulting. FreeBSD 2.2.6 is available now! | Phone: 316-326-6800 -----------------------------------| 1402 N. Washington, Wellington, KS-67152 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting-Network Engineering-Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- --0-1125508220-898619056=:4022 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="adduser.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: adduser.diff patch KioqIC91c3Ivc2Jpbi9hZGR1c2VyCVNhdCBKdW4gMTMgMTY6Mzk6NDcgMTk5 OA0KLS0tIGFkZHVzZXIJU2F0IEp1biAxMyAxNjozOToyNiAxOTk4DQoqKioq KioqKioqKioqKioNCioqKiA5OTQsMTAwMCAqKioqDQogICAgICAjIHJlbmFt ZSAnZG90LmZvbycgZmlsZXMgdG8gJy5mb28nDQogICAgICBwcmludCAiQ29w eSBmaWxlcyBmcm9tICRkb3RkaXIgdG8gJGhvbWVkaXJcbiIgaWYgJHZlcmJv c2U7DQogICAgICBzeXN0ZW0oImNwIC1SICRkb3RkaXIgJGhvbWVkaXIiKTsN CiEgICAgIHN5c3RlbSgiY2htb2QgLVIgdSt3clgsZ28tdyAkaG9tZWRpciIp Ow0KICAgICAgc3lzdGVtKCJjaG93biAtUiAkbmFtZTokZ3JvdXAgJGhvbWVk aXIiKTsNCiAgDQogICAgICAjIHNlY3VyaXR5DQotLS0gOTk0LDEwMDAgLS0t LQ0KICAgICAgIyByZW5hbWUgJ2RvdC5mb28nIGZpbGVzIHRvICcuZm9vJw0K ICAgICAgcHJpbnQgIkNvcHkgZmlsZXMgZnJvbSAkZG90ZGlyIHRvICRob21l ZGlyXG4iIGlmICR2ZXJib3NlOw0KICAgICAgc3lzdGVtKCJjcCAtUiAkZG90 ZGlyICRob21lZGlyIik7DQohICAgICBzeXN0ZW0oImNobW9kIC1SIHUrd3JY LGctdyxvLXJ3eCAkaG9tZWRpciIpOw0KICAgICAgc3lzdGVtKCJjaG93biAt UiAkbmFtZTokZ3JvdXAgJGhvbWVkaXIiKTsNCiAgDQogICAgICAjIHNlY3Vy aXR5DQo= --0-1125508220-898619056=:4022-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jun 23 16:54:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07241 for freebsd-security-outgoing; Tue, 23 Jun 1998 16:54:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07135 for ; Tue, 23 Jun 1998 16:54:02 -0700 (PDT) (envelope-from fullermd@shell.futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) id SAA12486; Tue, 23 Jun 1998 18:53:57 -0500 (CDT) Message-ID: <19980623185357.25223@futuresouth.com> Date: Tue, 23 Jun 1998 18:53:57 -0500 From: "Matthew D. Fuller" To: Open Systems Networking Cc: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Open Systems Networking on Tue, Jun 23, 1998 at 12:24:16PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 23, 1998 at 12:24:16PM -0400, Open Systems Networking woke me up to tell me: > > I've sent this to a couple of people now. > > This pertains to adduser on 3.0-current. > I havent checked on a 2.2x adduser. > I'm wondering what purpose if any the perms on "other" have in adduser. > > adduser is set to o=-w. Why by default should adduser allow home > directories to be executable and read by "others". I mean if the default > policy of IPFW is to default to closed, and the admin has to choose to > open up his server, shouldnt the default for adduser be to create home > dirs closed to "others" and the user has to open them up? Makes sense to > me anyway. I think having adduser have ANY perms on other brekas the man > page. Well, for starters, you'll need to have at least execute to have web directories under ~. There's a great difference in philosophy between home dirs and IPFW. If you're running IPFW, that's because you want to keep things out. If you have home directories, that's because you want users. Part of the philosophy that's been with unices from the beginning is sharing of information. Having readable home dirs makes that possible. I've always had my umask as 077. My home dir is readable, but the files aren't. If I have files I want to share, I chmod them so they're readable (or executable, ATCMB). It really comes down to 2 philosophies: 1) Share unless there's a reason to not, and 2) Hide unless there's a reason to share I happen to like 1. It was one of the cornerstones of unix in the first place; share unless there's a reason not to, and when not sharing, lock it down tight. And as for 'each user in their own group', well, that defeats some of the niceness of groups. I have a group user, which all normal users belong to, and no others. So if someone breaks in as 'daemon' or 'nobody', they can't get at a lot of stuff, whereas normal users have no problem. Sorry, I only have a dime. Need $.08 change, please. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | FreeBSD; the way computers were meant to be | * "The only reason I'm burning my candle at both ends, is * | that I haven't figured out how to light the middle yet."| * fullermd@futuresouth.com :-} MAtthew Fuller * | http://keystone.westminster.edu/~fullermd | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jun 23 17:08:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10306 for freebsd-security-outgoing; Tue, 23 Jun 1998 17:08:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10291 for ; Tue, 23 Jun 1998 17:08:28 -0700 (PDT) (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id UAA03962; Tue, 23 Jun 1998 20:02:14 -0400 (EDT) Date: Tue, 23 Jun 1998 20:08:20 -0400 (EDT) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: "Matthew D. Fuller" cc: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions In-Reply-To: <19980623185357.25223@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 23 Jun 1998, Matthew D. Fuller wrote: > Well, for starters, you'll need to have at least execute to have web > directories under ~. > There's a great difference in philosophy between home dirs and IPFW. If > you're running IPFW, that's because you want to keep things out. If you > have home directories, that's because you want users. Part of the > philosophy that's been with unices from the beginning is sharing of > information. Having readable home dirs makes that possible. That is what "group" is for. GROUP sharing of files. > I've always had my umask as 077. My home dir is readable, but the files > aren't. If I have files I want to share, I chmod them so they're > readable (or executable, ATCMB). > It really comes down to 2 philosophies: > 1) Share unless there's a reason to not, and > 2) Hide unless there's a reason to share > I happen to like 1. It was one of the cornerstones of unix in the first > place; share unless there's a reason not to, and when not sharing, lock > it down tight. Thats hte point of "group" though. IMO you wanna share, fine but do it with group as i believe it was meant. but do NOT make "other" shareable I believe "other" covers areas that user and group cant. Kind of like a wildcare scenario. If we cant get what we want with user/group do it with "other" > And as for 'each user in their own group', well, that defeats some of the > niceness of groups. I have a group user, which all normal users belong > to, and no others. So if someone breaks in as 'daemon' or 'nobody', they > can't get at a lot of stuff, whereas normal users have no problem. But that is what the man page reads AFAICT. At least thats how I decypher it. Also the argument of users having their own group is not the issue. THAT is an administrative issue. If the admin wishes to put each user into their own group or a shared group called users is up to him. I'm directly dealing with the ability of a users home directory to be safe from prying eyes by default. No one signs up for unix saying hey, I LOVE the fact that ANYONE can read my files by default wether I want it or not. So I think it comes down to a majority rules outlook. Do the majority of users enjoy having their home directories created by default to be readable and executable by ANYONE, or do the majority wish to see it closed to everyone by default. I think this should be revisited. So I would like to hear everyones input into this. Am I a crazy lunatic that thinks users, the majority of which dont even know about u,g,o and permissions, would rather see there home directories NOT viewable and executable by ANYONE? I mean if the majority of people like the status quo then naturally dont fix what isn't broken. But if there is a majority that think "other" should be -rwx, then I think it is worth debating. Chris -- "Linux... The choice of a GNUtered generation." ===================================| Open Systems Networking And Consulting. FreeBSD 2.2.6 is available now! | Phone: 316-326-6800 -----------------------------------| 1402 N. Washington, Wellington, KS-67152 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting-Network Engineering-Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jun 23 20:03:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA07456 for freebsd-security-outgoing; Tue, 23 Jun 1998 20:03:16 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA07447 for ; Tue, 23 Jun 1998 20:03:11 -0700 (PDT) (envelope-from tcrimi+@andrew.cmu.edu) Received: (from postman@localhost) by po6.andrew.cmu.edu (8.8.5/8.8.2) id XAA10067 for freebsd-security@FreeBSD.ORG; Tue, 23 Jun 1998 23:03:05 -0400 (EDT) Received: via switchmail; Tue, 23 Jun 1998 23:03:03 -0400 (EDT) Received: from lister.net.cmu.edu via qmail ID ; Tue, 23 Jun 1998 23:02:03 -0400 (EDT) Received: from lister.net.cmu.edu via qmail ID ; Tue, 23 Jun 1998 23:02:01 -0400 (EDT) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.lister.net.cmu.edu.sun4m.54 via MS.5.6.lister.net.cmu.edu.sun4_51; Tue, 23 Jun 1998 23:02:01 -0400 (EDT) Message-ID: Date: Tue, 23 Jun 1998 23:02:01 -0400 (EDT) From: Thomas Valentino Crimi To: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd have to somehow think that the majority of uses (read: home desktop users) give accounts to friends and family, and in such an environment would encourage sharing. It's very often that someone would say "It's right in my homedirectory". Things like say, mail are already by rather strong default made private, so what else do most people on a friend's machine plan to keep private? If you don't trust someone you wouldn't give them account on your home box, correct? The group that would seek user privacy I would imagine would be the ISP, and such people generally have far more elaborate concerns creating an account to begin with, so modifying adduser would be the least of their problems. One thing whcih I've seen implemented is that of the 'private' directory, something that specfically points a user to note that their homedirectory by default isn't private but if they do have something to hide from view they can move it into there. I, of course, just believe in educating people using a system on what they are getting themselves into. We all must know the means to which one must go for 'absolute' security. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Jun 23 23:15:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10549 for freebsd-security-outgoing; Tue, 23 Jun 1998 23:15:02 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10408 for ; Tue, 23 Jun 1998 23:14:10 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ("port 3551"@[139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IYM5V4SQJ40044P2@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Wed, 24 Jun 1998 12:53:34 +1000 Received: from gsms01.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IYM5V2WB6O8WWMNK@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Wed, 24 Jun 1998 12:53:32 +1000 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id MAA17918 for freebsd-security@FreeBSD.ORG; Wed, 24 Jun 1998 12:53:31 +1000 (EST) Date: Wed, 24 Jun 1998 12:53:31 +1000 (EST) From: Peter Jeremy Subject: Re: adduser chmod permissions To: freebsd-security@FreeBSD.ORG Message-id: <199806240253.MAA17918@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 23 Jun 1998 18:53:57 -0500, "Matthew D. Fuller" wrote: >And as for 'each user in their own group', well, that defeats some of the >niceness of groups. I have a group user, which all normal users belong >to, and no others. So if someone breaks in as 'daemon' or 'nobody', they >can't get at a lot of stuff, whereas normal users have no problem. Actually, IMHO, your approach defeats much of the usefulness of groups :-). One of the niceties of the BSD model is that users can belong to multiple groups. The BSD security model is based around putting different files & directories in different groups to control who can access them. Eg, all games are in group games and if a user wants to use them, he has to be in the games group. You could similarly restrict access to (eg) X11, source code and development tools. By giving each user his own group, you are allowing each user to define what other users he will share his files with. (Ideally, this needs a tool which allows a non-root user to control the contents of `her' entry in /etc/group). There are a couple of gotcha's with using this approach on a big system: - By default a user can only belong to 16 groups (defined by NGROUPS_MAX in sys/syslimits.h) - NFS V2 (or at least some variants thereof) only allow 8 groups. - /etc/group is limited to 1024 char lines and no more than 200 users per group. Unfortunately, these particular arbitrary limits appear to be spread around in a variety of places (I've found 4 different places where the 200 users per group limit is defined, and there may be others. I haven't even looked for the 1024-char line limit). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 02:34:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA16906 for freebsd-security-outgoing; Wed, 24 Jun 1998 02:34:10 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA16681; Wed, 24 Jun 1998 02:32:10 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id RAA11498; Wed, 24 Jun 1998 17:29:39 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806240929.RAA11498@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: dg@root.com cc: Nicholas Charles Brawn , security@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: non-executable stack? In-reply-to: Your message of "Sun, 21 Jun 1998 23:19:50 MST." <199806220619.XAA16784@implode.root.com> Date: Wed, 24 Jun 1998 17:29:39 +0800 From: Peter Wemm Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Greenman wrote: > >I was pondering the following after reading about solaris 2.6's > >non-executable stack option. > > > >1. How feasible is it to implement a non-executable stack kernel option? > >2. If it *is* feasible, what do people think of a sysctl-based interface > >to enable/disenable it? > >3. If both 1 & 2 were implemented, how about making it impossible to > >disenable at say.. securelevel >= 1? > > > >If I remember the discussions on bugtraq right, a non-exec patch isn't a > >cure-all for buffer overflow attacks. However it would be an overall > >security enhancement and prevent many script-based attacks. > > > >What are peoples thoughts on this? > > I believe that making the stack non-exec will break the signal trampoline > in FreeBSD. Although this may have changed in recent times without me > noticing. Bruce? Peter? Yes, it would, if the entire stack was non-executable. However.. since the x86 can't turn off execute permission at the page level, it has to use the segments system, and this is byte or paragraph addressible. I'm not totally familiar with the Linux patches to do this, in particular I don't know if the user segment descriptor lengths are "shrunk" to prevent %cs and/or %ds addressing of the stack (ouch!), or whether there's a new segment to contain the stack and %ss is loaded with that, or something else entirely. It might be enough to shorten the %cs segment to prevent stack executability, but that doesn't help threaded programs with their own stacks, and it sounds too easy. :-) And it doesn't solve the trampoline problem. The reason we have the trampoline at all is so that we can have the process do a 'sigreturn()' syscall after calling the handler. Making the process execute the handler directly wouldn't be too hard since it'd be just register and stack frame twiddling, but getting it to execute the syscall that's needed to resture the pre-signal context (some of which is privileged) is the problem. A binary interface modification would work (ie: have signal, sigaction etc use their own trampoline directly), but that would break binary compatability in a big way. The cost of an extra page outside the stack and within the user %cs space to provide the trampoline would not be insignificant to everybody. On a system with 1000 processes, an extra 4K page is 4MB total. On the other hand, ram is cheap at the moment, perhaps this is a tradeoff that people would be happy to make? Incidently, I have found that causing 'int 0x80' (the linux syscall entry point) in a bsd executable to immediately kill and core dump the process and printf a console message has been quite enlightening on shell server machines over the past year or so. > -DG Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 03:11:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA22928 for freebsd-security-outgoing; Wed, 24 Jun 1998 03:11:46 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hotpoint.dcs.qmw.ac.uk (hotpoint.dcs.qmw.ac.uk [138.37.88.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA22767 for ; Wed, 24 Jun 1998 03:10:57 -0700 (PDT) (envelope-from scott@dcs.qmw.ac.uk) Received: from brunos-sun.dcs.qmw.ac.uk [138.37.88.185]; by hotpoint.dcs.qmw.ac.uk (8.8.7/8.8.5/S-4.0) with SMTP; for ""; id LAA18738; Wed, 24 Jun 1998 11:10:43 +0100 (BST) Date: Wed, 24 Jun 1998 11:10:43 +0100 (BST) Message-Id: <199806241010.LAA18738@hotpoint.dcs.qmw.ac.uk> Received: locally by brunos-sun (SMI-8.6/QMW-client-3.2b); poster "scott"; id LAA16427; Wed, 24 Jun 1998 11:05:17 +0100 From: Scott Mitchell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thomas Valentino Crimi said: > > I'd have to somehow think that the majority of uses (read: home >desktop users) give accounts to friends and family, and in such an >environment would encourage sharing. It's very often that someone would >say "It's right in my homedirectory". Things like say, mail are already >by rather strong default made private, so what else do most people on a >friend's machine plan to keep private? If you don't trust someone you >wouldn't give them account on your home box, correct? Absolutely. Just about every Unix system I've used (admittedly all university or private machines) had home directories world readable, with a umask of 002 (and periodic mail from the admins telling people to protect their mail directories...) But as you say, these are environments that encourage sharing; perhaps it is different in the real world. Maybe this could be an option in adduser -- home directory world-readable (y/n)? I thing the default .profile, etc set the umask to 002 anyway, so you would have to change that as well if you were really concerned about this. Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID |"If I can't have my coffee, I'm just | 0x54B171B9 | like a dried up piece of roast goat" QMW College, London, UK | 0xAA775B8B | -- J. S. Bach. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 05:51:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25770 for freebsd-security-outgoing; Wed, 24 Jun 1998 05:51:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25706 for ; Wed, 24 Jun 1998 05:50:49 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id IAA17305; Wed, 24 Jun 1998 08:50:43 -0400 (EDT) Date: Wed, 24 Jun 1998 08:50:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Matthew D. Fuller" cc: Open Systems Networking , freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions In-Reply-To: <19980623185357.25223@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Personally, my skel account tree has something like this in it: public/ private/ prototypes/ dot.* public_html/ index.html public/ is work readable, user readable/writable private is only user readable/writable prototypes is only user readable/writable, and contains the dot.* files that are normally in the skel directory (I have fairly all-encompassing /etc/csh.*,profile stuff) public_html/ has appropriate permissions, and contains a sample web page for the user. This way it is clear to my users where files should and shouldn't go; I also don't get to explain how to set permissions on a public_html directory for ftp/samba users. :) With the prototypes/ arrangement, I don't have to deal with the forever morphing prototype dot files across various versions of BSD resulting in each user having a markedly different environment. One thing I really miss in FreeBSD having had accounts in AFS/Coda is the ability for users to create and maintain their own groups. Very useful to be able to say .. fs sa friends/ rnw:friends read Etc. Maybe ACLfs (whenever) should add user-definable group support? :) Certainly the Coda port to FreeBSD should do that. A new protection server was/is being written at Yale to provide distributed group information across a Coda realm. I'm not sure when that gets integrated with the main Coda distribution. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 07:10:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA10873 for freebsd-security-outgoing; Wed, 24 Jun 1998 07:10:19 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (NOSvSuxxFSPB6OKcRzzqSErQz+entwRE@heron.doc.ic.ac.uk [146.169.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA10802 for ; Wed, 24 Jun 1998 07:10:03 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([w4Sm7+cwV9nJ7w6v6VOmM70ZKe+2pYKc]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0yoqEt-0001oh-00; Wed, 24 Jun 1998 15:09:31 +0100 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0yoqEs-0002io-00; Wed, 24 Jun 1998 15:09:30 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Wed, 24 Jun 1998 15:09:30 +0100 In-Reply-To: Nicholas Charles Brawn "non-executable stack?" (Jun 20, 9:21pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Nicholas Charles Brawn , security@FreeBSD.ORG Subject: Re: non-executable stack? Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 20, 9:21pm, Nicholas Charles Brawn wrote: } Subject: non-executable stack? > I was pondering the following after reading about solaris 2.6's > non-executable stack option. > > 1. How feasible is it to implement a non-executable stack kernel option? > 2. If it *is* feasible, what do people think of a sysctl-based interface > to enable/disenable it? > 3. If both 1 & 2 were implemented, how about making it impossible to > disenable at say.. securelevel >= 1? > > If I remember the discussions on bugtraq right, a non-exec patch isn't a > cure-all for buffer overflow attacks. However it would be an overall > security enhancement and prevent many script-based attacks. It would be nice to have a filesystem non-executable-stack flag so that it could be enabled/disabled on a per file basis. Another option would be to only turn it on for set[ug]id executables. There are a number of other "features" like this that would be useful, for example the ability to specify that only printable ascii characters can appear in the arguments or environment of a process before it can exec another. I haven't checked if its possible to write shellcode using just plain ascii characters, if you can then this is obviously worthless, but I'd be surprised if it's possible. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 07:53:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA16503 for freebsd-security-outgoing; Wed, 24 Jun 1998 07:53:06 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.iserv.net (mail.iserv.net [204.177.184.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA16453 for ; Wed, 24 Jun 1998 07:52:35 -0700 (PDT) (envelope-from matt@zigg.com) Received: from wibble (wibble.iserv.net [206.114.47.48]) by mail.iserv.net (8.8.5/8.8.5) with SMTP idi for ; Wed, 24 Jun 1998 10:53:42 -0400 (EDT)KAA03703 for ; Wed, 24 Jun 1998 10:53:42 -0400 (EDT) X-Envelope-To: From: "Matt Behrens" To: Subject: RE: adduser chmod permissions Date: Wed, 24 Jun 1998 10:52:05 -0400 Message-ID: <000701bd9f7f$a86c6160$302f72ce@wibble.iserv.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199806240253.MAA17918@gsms01.alcatel.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy said: : - /etc/group is limited to 1024 char lines and no more than 200 users : per group. Unfortunately, these particular arbitrary limits appear : to be spread around in a variety of places (I've found 4 different : places where the 200 users per group limit is defined, and there may : be others. I haven't even looked for the 1024-char line limit). Can't we expand these numbers? Seems a bit restrictive to me, and expanding can't break anything, will it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 08:01:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA17706 for freebsd-security-outgoing; Wed, 24 Jun 1998 08:01:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ccssu.crimea.ua (root@mordor.ccssu.crimea.ua [62.244.11.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA17675 for ; Wed, 24 Jun 1998 08:01:00 -0700 (PDT) (envelope-from stas@ssu.ccssu.crimea.ua) Received: from ssu.ccssu.crimea.ua (ssu.ccssu.crimea.ua [195.5.61.131] (may be forged)) by ccssu.crimea.ua (8.8.8/8.8.5) with ESMTP id RAA20379; Wed, 24 Jun 1998 17:59:37 +0400 Received: (from stas@localhost) by ssu.ccssu.crimea.ua (8.8.5/8.8.5) id SAA11520; Wed, 24 Jun 1998 18:02:19 +0400 (MSD) Date: Wed, 24 Jun 1998 18:02:19 +0400 (MSD) From: Stas Kisel Message-Id: <199806241402.SAA11520@ssu.ccssu.crimea.ua> To: ncb05@uow.edu.au, njs3@doc.ic.ac.uk, security@FreeBSD.ORG Subject: Re: non-executable stack? Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: njs3@doc.ic.ac.uk (Niall Smart) > Date: Wed, 24 Jun 1998 15:09:30 +0100 > It would be nice to have a filesystem non-executable-stack flag so that > it could be enabled/disabled on a per file basis. Another option would > be to only turn it on for set[ug]id executables. There are a number This option seems not so useful - many buffer overruns are(and will be) written for exploiting via network non-suid daemons, run as root or ever as nobody. E.g. overruns in CGI-scripts. > of other "features" like this that would be useful, for example the > ability to specify that only printable ascii characters can appear in > the arguments or environment of a process before it can exec another. > I haven't checked if its possible to write shellcode using just plain > ascii characters, if you can then this is obviously worthless, but I'd > be surprised if it's possible. \bye Stas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 08:53:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26345 for freebsd-security-outgoing; Wed, 24 Jun 1998 08:53:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26244 for ; Wed, 24 Jun 1998 08:52:16 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id LAA18209; Wed, 24 Jun 1998 11:51:56 -0400 (EDT) Date: Wed, 24 Jun 1998 11:51:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Niall Smart cc: Nicholas Charles Brawn , security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Jun 1998, Niall Smart wrote: > It would be nice to have a filesystem non-executable-stack flag so that > it could be enabled/disabled on a per file basis. Another option would > be to only turn it on for set[ug]id executables. There are a number > of other "features" like this that would be useful, for example the > ability to specify that only printable ascii characters can appear in > the arguments or environment of a process before it can exec another. > I haven't checked if its possible to write shellcode using just plain > ascii characters, if you can then this is obviously worthless, but I'd > be surprised if it's possible. I don't know if the "for setuidgid" only flag would be useful -- many daemons don't run setuid/setgid, but are still sources of vulnerability. What I'd like to see is a chflags flag PROTPROC that would have the features some were trying to associate with SCHG -- that is, this flag would provide extra protection for processes derived from an exec of the file in question. In a high secure level, PROTPROC would prevent ptrace,ktrace from attaching to the process, and might also prevent signal delivery from processes with the same uid that might result in termination (for example). To prevent some unfortunate other effects, I would be tempted to make the flag removable and settable only when securelevel > 0. This would allow syslogd to be protected from signals, debugging, append to an append-only file, and have its binary be immutable. This would also allow for things such as an audit lkm hooking into an audit daemon. I'm starting to put together such a beast, and have a brief description at http://www.watson.org/fbsd-hardening/audittool.html. My current project is lkm token extensions for authorization/authentication (almost completed an initial implementation), which may be useful for distributed file systems (such as AFS, Coda, etc), and could be used to store IPsec keying material and so on. I hope to have a test run of the lkm available for download by the end of this upcoming weekend, along with modifications to the kerberos library to use it next week. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 10:01:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10980 for freebsd-security-outgoing; Wed, 24 Jun 1998 10:01:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10898 for ; Wed, 24 Jun 1998 10:00:45 -0700 (PDT) (envelope-from opsys@mail.webspan.net) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with SMTP id MAA20752; Wed, 24 Jun 1998 12:54:26 -0400 (EDT) Date: Wed, 24 Jun 1998 13:00:31 -0400 (EDT) From: Open Systems Networking X-Sender: opsys@orion.webspan.net To: Scott Mitchell cc: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions In-Reply-To: <199806241010.LAA18738@hotpoint.dcs.qmw.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Jun 1998, Scott Mitchell wrote: > Maybe this could be an option in adduser -- home directory world-readable > (y/n)? I thing the default .profile, etc set the umask to 002 anyway, so > you would have to change that as well if you were really concerned about > this. I would agree to that. I just think for those who want it it should be an option. If I wanted users to share dir's id put them in the same group :-) Chris -- "Linux... The choice of a GNUtered generation." ===================================| Open Systems Networking And Consulting. FreeBSD 2.2.6 is available now! | Phone: 316-326-6800 -----------------------------------| 1402 N. Washington, Wellington, KS-67152 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting-Network Engineering-Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 10:10:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12677 for freebsd-security-outgoing; Wed, 24 Jun 1998 10:10:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from j51.com (aaronb@gorplex.j51.com [209.94.121.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12537 for ; Wed, 24 Jun 1998 10:10:15 -0700 (PDT) (envelope-from aaronb@j51.com) Received: from localhost (aaronb@localhost) by j51.com (8.8.8/8.8.5) with SMTP id NAA09252; Wed, 24 Jun 1998 13:11:57 -0400 (EDT) Date: Wed, 24 Jun 1998 13:11:57 -0400 (EDT) From: Aaron Bornstein To: Matt Behrens cc: freebsd-security@FreeBSD.ORG Subject: RE: adduser chmod permissions In-Reply-To: <000701bd9f7f$a86c6160$302f72ce@wibble.iserv.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Jun 1998, Matt Behrens wrote: > Can't we expand these numbers? Seems a bit restrictive to me, and expanding > can't break anything, will it? > Taking a good thing one step further, why have hard limits at all? I'm sure we could muck around with the implementation enough without changing the interface. As long as we leave the power to create new groups a superuser privelege, I see no problem with this approach. -- Aaron Bornstein : aaronb at j51 dot com : http://www.j51.com/~aaronb Fiat Justitia Ruat Caelum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 11:48:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03598 for freebsd-security-outgoing; Wed, 24 Jun 1998 11:48:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03500 for ; Wed, 24 Jun 1998 11:48:21 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id LAA01163; Wed, 24 Jun 1998 11:47:52 -0700 (PDT) Message-Id: <199806241847.LAA01163@implode.root.com> To: tqbf@pobox.com cc: easmith@beatrice.rutgers.edu (Allen Smith), njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com Subject: Re: bsd securelevel patch question In-reply-to: Your message of "Fri, 19 Jun 1998 22:38:09 CDT." <19980620033809.4255.qmail@joshua.enteract.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 24 Jun 1998 11:47:52 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Why are you wanting to do it via login.conf, instead of via multiple >> groups? I'm asking because I'm looking at doing this for ICMP sockets > >I don't see how you'd use login.conf to handle restricted system >capabilities (such as network access); these are privileges extended to >users by the kernel, not by other processes on the system who can use a >login.conf API to access information in that file. login/login.conf would be extended so that it did a 'setpriv()' as part of the login procedure. The privilege set would be associated with the process and its children. I'm not happy with login.conf for this either, but the only alternative would be to either extend the exiting passwd files to hold privilege info, or create an entirely new file to contain it. >This solution has very real security benefits, but I find administrating >them from login.conf to be clumsy. In terms of transitioning away from >binary "superuser" privilege, I think normal Unix filesystem security >semantics (owner, group, and SET[UG]ID) are expressive enough. I don't think this scales very well. Assigning specific gids as privileges is also rather messy inside the kernel and makes probably wrong assumptions about a machine's external /etc/group layout. One could mitigate this a bit by exporting the assignment of these via individual sysctl() variables. I also think the issue of handling setuid/setgid binaries is independant of a fine grained privilege mechanism. Even in your scheme, if I understand it completely, you'd only be able to have one capability enabled via setgid, so you'd be out of luck if you needed two since you can't specify a list of groups. I agree that setuid root has always been an inadequate sledgehammer for granting access to privileged resources and capabilities. I think the best way to handle this, however, is with a file ACL mechanism that allows for the specification of privileges as and extension of the access control information. On the other hand, in VMS, special privileges can be granted to a binary only if it is "installed" first - i.e. made known to the system as a special executable, usually at system startup time. This has the advantage of specifying all binaries that have elevated privilege(s) in one place and keeping privileged binaries open (making media changes difficult or impossible), but has the disadvantage of violating POLA. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 13:21:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19914 for freebsd-security-outgoing; Wed, 24 Jun 1998 13:21:27 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (jYlWUNIt8nINvxRKdVNokJQhhQ6heUs2@heron.doc.ic.ac.uk [146.169.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA19865 for ; Wed, 24 Jun 1998 13:21:10 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([CGRB3r+s+pXyR5Ntl2evJ+2ZG1rfBpCo]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0yow24-0002Yu-00; Wed, 24 Jun 1998 21:20:40 +0100 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0yow23-00039B-00; Wed, 24 Jun 1998 21:20:39 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Wed, 24 Jun 1998 21:20:39 +0100 In-Reply-To: David Greenman "Re: bsd securelevel patch question" (Jun 24, 11:47am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: dg@root.com, tqbf@pobox.com Subject: Re: bsd securelevel patch question Cc: easmith@beatrice.rutgers.edu (Allen Smith), njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > for granting access to privileged resources and capabilities. I think the > best way to handle this, however, is with a file ACL mechanism that allows > for the specification of privileges as and extension of the access control > information. On the other hand, in VMS, special privileges can be granted to Of course, this implies that all permissions can be represented in the filesystem. I can imagine a /dev/socket/inet/xyz mechanism which allows a process to bind to a specific port or /dev/raw which allows them to create a raw socket etc etc. This gets somewhat messy for the above example since it is difficult to administer things like ranges (eg ports 0 to 1024) using a single device file for each element in that range, and any other approach (e.g. /dev/socket/inet/0-1024) seems to lose the cleanliness offered by the "single file for everything" approach. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 15:37:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18129 for freebsd-security-outgoing; Wed, 24 Jun 1998 15:37:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18074 for ; Wed, 24 Jun 1998 15:37:32 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id PAA19784; Wed, 24 Jun 1998 15:37:28 -0700 (PDT) (envelope-from sef) Date: Wed, 24 Jun 1998 15:37:28 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199806242237.PAA19784@kithrup.com> To: security@FreeBSD.ORG Reply-To: security@FreeBSD.ORG Subject: Re: bsd securelevel patch question In-Reply-To: References: David Greenman "Re: bsd securelevel patch question" (Jun 24, 11:47am) Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >> I think the >> best way to handle this, however, is with a file ACL mechanism that allows >> for the specification of privileges as and extension of the access control >> information. >Of course, this implies that all permissions can be represented in >the filesystem. I can imagine a /dev/socket/inet/xyz mechanism which >allows a process to bind to a specific port or /dev/raw which allows >them to create a raw socket etc etc. I think David was talking about using traditional ACL's on files. He wasn't terribly clear, however; he also could have meant something like /dev/io (which, when you open it, allows you to execute in/out instructions). I have asked him what kind of priv's he's talking about in general; there are some rather obvious ones (PRIV_CHUID, PRIV_IO, etc.), but I suspect he has more in mind. I think going to capabilities is a good idea, but it is definitely far more complex, and is likely to be considerably buggier. And will probably break things, at least at first. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 15:38:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18270 for freebsd-security-outgoing; Wed, 24 Jun 1998 15:38:37 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18170 for ; Wed, 24 Jun 1998 15:38:09 -0700 (PDT) (envelope-from bsd@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id AAA14474; Thu, 25 Jun 1998 00:36:24 +0200 (CEST) (envelope-from bsd@panke.de.freebsd.org) Received: (from bsd@localhost) by campa.panke.de (8.8.8/8.8.8) id AAA01480; Thu, 25 Jun 1998 00:31:55 +0200 (MET DST) (envelope-from bsd) Message-ID: <19980625003154.09187@panke.de> Date: Thu, 25 Jun 1998 00:31:54 +0200 From: Wolfram Schneider To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions Reply-To: wosch@FreeBSD.ORG References: <199806240253.MAA17918@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199806240253.MAA17918@gsms01.alcatel.com.au>; from Peter Jeremy on Wed, Jun 24, 1998 at 12:53:31PM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1998-06-24 12:53:31 +1000, Peter Jeremy wrote: > - /etc/group is limited to 1024 char lines and no more than 200 users > per group. Unfortunately, these particular arbitrary limits appear > to be spread around in a variety of places (I've found 4 different > places where the 200 users per group limit is defined, and there may > be others. I haven't even looked for the 1024-char line limit). This was fixed 18 months ago in src/lib/libc/gen/getgrent.c rev 1.14 Wolfram To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 18:26:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15256 for freebsd-security-outgoing; Wed, 24 Jun 1998 18:26:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.alcatel.com.au (gatekeeper.alcatel.com.au [203.17.66.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15137 for ; Wed, 24 Jun 1998 18:25:26 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from mfg1.cim.alcatel.com.au ("port 1712"@[139.188.23.1]) by gatekeeper.alcatel.com.au (PMDF V5.1-7 #U2695) with ESMTP id <01IYNG6NAKEO000EMO@gatekeeper.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 25 Jun 1998 10:59:12 +1000 Received: from gsms01.alcatel.com.au by cim.alcatel.com.au (PMDF V5.1-10 #U2695) with ESMTP id <01IYNG6L60J48WX2NA@cim.alcatel.com.au> for freebsd-security@FreeBSD.ORG; Thu, 25 Jun 1998 10:59:09 +1000 Received: (from jeremyp@localhost) by gsms01.alcatel.com.au (8.8.8/8.7.3) id KAA02884 for freebsd-security@FreeBSD.ORG; Thu, 25 Jun 1998 10:59:08 +1000 (EST) Date: Thu, 25 Jun 1998 10:59:08 +1000 (EST) From: Peter Jeremy Subject: Re: adduser chmod permissions To: freebsd-security@FreeBSD.ORG Message-id: <199806250059.KAA02884@gsms01.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Jun 1998 00:31:54 +0200, Wolfram Schneider wrote: >On 1998-06-24 12:53:31 +1000, Peter Jeremy wrote: >> - /etc/group is limited to 1024 char lines and no more than 200 users >> per group. >This was fixed 18 months ago in >src/lib/libc/gen/getgrent.c rev 1.14 Looking through CVSROOT/src/lib/libc/gen/getgrent.c,v the CVS log does say that. It also says `Not a 2.2 candidate' and the relevant code does not appear to be in the 2.2.6-RELEASE version of src/lib/libc/gen/getgrent.c :-(. FWIW, the other places I found that appear to impose these limits (at least in 2.2.6-RELEASE) are src/libexec/mknetid/parse_group.c, src/usr.sbin/pw/pw.h and src/usr.sbin/pw/pwupd.h. Why 18-month old code hasn't been moved from -current into -stable, I can't say... Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 20:07:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00747 for freebsd-security-outgoing; Wed, 24 Jun 1998 20:07:53 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00736 for ; Wed, 24 Jun 1998 20:07:49 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id XAA04254; Wed, 24 Jun 1998 23:05:25 -0400 (EDT) From: "Allen Smith" Message-Id: <9806242305.ZM4253@beatrice.rutgers.edu> Date: Wed, 24 Jun 1998 23:05:25 -0400 In-Reply-To: David Greenman "Re: bsd securelevel patch question" (Jun 24, 11:47am) References: <199806241847.LAA01163@implode.root.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: dg@root.com, tqbf@pobox.com Subject: Re: bsd securelevel patch question Cc: njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com, easmith@beatrice.rutgers.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 24, 11:47am, David Greenman (possibly) wrote: > >This solution has very real security benefits, but I find administrating > >them from login.conf to be clumsy. In terms of transitioning away from > >binary "superuser" privilege, I think normal Unix filesystem security > >semantics (owner, group, and SET[UG]ID) are expressive enough. > > I don't think this scales very well. Assigning specific gids as > privileges is also rather messy inside the kernel and makes > probably wrong assumptions about a machine's external /etc/group > layout. One could mitigate this a bit by exporting the assignment > of these via individual sysctl() variables. As it happens, that's how I've done it - via a quad sysctl variable - although that has the admitted problem that, given how quad variables work in gcc, it's difficult to specify a constant for them, so no redefining via the config file except in a rather crude way (on/off - off being a value below 0 or above the maximum for gid_t (currently a u_int32_t). OTOH, given that various files will need to be installed set to a particular gid (e.g., ping), having this be very variable (no pun intended) between installations would cause problems in any event. (Admittedly, I haven't looked yet at how to handle the on/off mechanism with file installation - at first it'd need to be manual.) > I also think the issue of handling setuid/setgid binaries is > independant of a fine grained privilege mechanism. Even in your > scheme, if I understand it completely, you'd only be able to have > one capability enabled via setgid, so you'd be out of luck if you > needed two since you can't specify a list of groups. This is a general problem with the current implementation of setuid/gid files and multiple groups, yes. What is needed is a way for some setuid binaries to be initialized with the group set of the uid they're set to. This will also cure some existing problems with the setuid/gid system, among which are: A. you can't have a setgid program with execution of it limited to a particular group. (If you're writing the program, this is no problem... but if it's one you're porting in, this can be a problem - see below.) Various schemes with wrappers are admittedly possible but clunky. B. files that should be accessible to a limited group of programs can't have a subset of those programs also being able to access some other group-limited group of files. In other words, I'm suggesting the solution to the problem is to fix this - not to set up a new system, orthogontal to this, that is fixed already. The mechanism of doing so necessitates that setuid programs be able - preferably selectively - to access the set of group permissions that the user they're setuid to would normally have. In order to do this, the kernel needs to know the groups associated with each uid. I would suggest loading them in with a system call usable only by process 1, similarly to securelevel downward setting - init would do this on startup and on a HUP, as per rereading the /etc/ttys file - to protect those of us (like me once another Seagate SCSI drive gets installed) with an /etc/group file on a read-only filesystem. There is then the problem of telling which setuid files should have their group list initialized. The best way to tell this would appear to be the currently unused sticky bit (unused for executables, at least). When a setuid file with the sticky bit was executed: A. kern_exec would check for the new uid's listing in the data set created by the above system call B. if the uid was found, the groups would be initialized to the groups of the new uid, except that the 0th gid would be left unchanged unless the executable was also setgid; the 1st gid would, as usual, contain the 'password gid' of the new uid C. a flag would be set in the process in question indicating that this had been done Whenever another process was executed by a process with the flag set, so long as that process was not setuid with the sticky bit set: A. the groups list, other than the 0th gid (left the same as before), would be reinitialized to that of the real uid (possibly unless the result was the same group list, in which case the saved uid would be used instead) B. the flag would be unset Whenever the uid or euid of a process with the flag set was changed: A. the groups list, other than the 0th gid (left the same as before), would be reinitialized to that of the new uid B. if the real, effective, and saved uids were all the same, the flag would be unset > I agree that setuid root has always been an inadequate sledgehammer > for granting access to privileged resources and capabilities. I think the > best way to handle this, however, is with a file ACL mechanism that allows > for the specification of privileges as and extension of the access control > information. On the other hand, in VMS, special privileges can be granted to > a binary only if it is "installed" first - i.e. made known to the system as > a special executable, usually at system startup time. This has the advantage > of specifying all binaries that have elevated privilege(s) in one place and > keeping privileged binaries open (making media changes difficult or > impossible), but has the disadvantage of violating POLA. This has definite possibilities, but I'd point out the problem of porting. This is accentuated by that the most critical system binaries are the ones which would be given privileges (currently setuid root), and these are ones that you want to be able to quickly fix security holes in - which is not helped if it's hard to port in an improved version, patches, etcetera from another system. Typically, various binaries are already set up to gain and relinquish privileges at particular points; having those privileges be independent from the mechanism they're expecting to use (uids and groups) is going to open up potential security holes. In either case, I'd be willing to help with programming on this this summer, although my speed of doing so will be slow - I'm not a very good C programmer, and have other things to do (I'm a graduate student, and _not_ in computer programming). I really don't want to do so and see my work go to waste by a different method being decided on, however. -Allen P.S. Here's a brief list of the sort of groups/privileges I'm thinking about: 1. Ability to do ICMP, with limitations (no spoofing, no multicast/broadcast, limited or no socket option setting); partially implemented (as in coded (except for some stuff regarding socket options) but not fully debugged). Useful for ping, pinger, etcetera. Admitted potential vulnerabilities are mostly DOS (as is already the case with ping), but redirect messages concern me. 2. Ability to send/receive from a _particular_ UDP port below 1024. Useful for ntpd, etcetera. 3. Ability to accept connections to, but not connect out from, a _particular_ TCP port below 1024. Useful for http, anonymous ftp, etcetera. The 'accept connections to' is to prevent spoofing of rsh, ssh in some modes, etcetera. 4. Ability to set the time, perhaps with limits in setting it back via means other than adjtime and similar drift (non-jump) programs. Again, useful for ntpd, etcetera. 5. Ability to set that process's own priority, including to real-time IO values. Again, useful for ntpd, etcetera. I'm perfectly willing to work on others, but these are the ones that I can most justify putting my time into, given my responsibilities here. If somebody can suggest other ones of use in running a firewall machine (with squid, ntpd, etcetera as proxys, essentially), I'd be interested in working on those. -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 20:49:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA06918 for freebsd-security-outgoing; Wed, 24 Jun 1998 20:49:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA06893 for ; Wed, 24 Jun 1998 20:48:52 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id UAA08929 for ; Wed, 24 Jun 1998 20:49:19 -0700 (PDT) Message-Id: <199806250349.UAA08929@implode.root.com> To: security@FreeBSD.ORG Subject: Re: bsd securelevel patch question In-reply-to: Your message of "Wed, 24 Jun 1998 15:37:28 PDT." <199806242237.PAA19784@kithrup.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 24 Jun 1998 20:49:19 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I think David was talking about using traditional ACL's on files. He wasn't >terribly clear, however; he also could have meant something like /dev/io >(which, when you open it, allows you to execute in/out instructions). > >I have asked him what kind of priv's he's talking about in general; there are >some rather obvious ones (PRIV_CHUID, PRIV_IO, etc.), but I suspect he has >more in mind. I can imagine that the list could be on the order of 32 large. This is one of the reasons why I don't think that a gid based scheme scales very well. You'd have to do a search through the fairly large group set each time you wanted to check for the capability. Even if we did implement the gid method externally, I still think that the kernel internal representation would be best handled by a privilege mask. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Jun 24 22:42:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24265 for freebsd-security-outgoing; Wed, 24 Jun 1998 22:42:50 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.143]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24201 for ; Wed, 24 Jun 1998 22:42:26 -0700 (PDT) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id BAA04805; Thu, 25 Jun 1998 01:40:31 -0400 (EDT) From: "Allen Smith" Message-Id: <9806250140.ZM4804@beatrice.rutgers.edu> Date: Thu, 25 Jun 1998 01:40:30 -0400 In-Reply-To: "Allen Smith" "Re: bsd securelevel patch question" (Jun 24, 11:05pm) References: <199806241847.LAA01163@implode.root.com> <9806242305.ZM4253@beatrice.rutgers.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: dg@root.com, tqbf@pobox.com Subject: Re: bsd securelevel patch question Cc: njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com, easmith@beatrice.rutgers.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for replying to my own mailing, but I wrote it rather too hastily and have realized a few errors. On Jun 24, 11:05pm, Allen Smith wrote: > There is then the problem of telling which setuid files should have > their group list initialized. The best way to tell this would appear > to be the currently unused sticky bit (unused for executables, at > least). When a setuid file with the sticky bit was executed: > A. kern_exec would check for the new uid's listing in the data > set created by the above system call > B. if the uid was found, the groups would be initialized to > the groups of the new uid, except that the 0th gid would be > left unchanged unless the executable was also setgid; the > 1st gid would, as usual, contain the 'password gid' of the > new uid > C. a flag would be set in the process in question indicating > that this had been done D. optionally, the original group list would be saved, minus the 0th gid > Whenever another process was executed by a process with the flag set, > so long as that process was not setuid with the sticky bit set: Correction: whenever another process was executed that did _not_ have the sticky bit set in its file. > A. the groups list, other than the 0th gid (left the same as > before), would be reinitialized to that of the real uid > (possibly unless the result was the same group list, in > which case the saved uid would be used instead) Alternatively (and possibly preferably), use the original group list (except for the 0th gid). > B. the flag would be unset > Whenever the uid or euid of a process with the flag set was changed: > A. the groups list, other than the 0th gid (left the same as > before), would be reinitialized to that of the new uid > B. if the real, effective, and saved uids were all the same, > the flag would be unset Correction: Whenever the euid of a process with the flag set was changed, the groups list (other than the 0th gid - left the same as before) would be reinitialized to that of the new uid. Whenever the euid, real uid, or saved uid was changed, on a process with the flag set, if they were now all the same, the flag would be unset. Some further notes: Scripts under this would be done either via wrappers or via curing the problems with setuid/setgid scripts in the first place; sperl and relatives would not work right, unfortunately... but this would be true with a privileges setup also, so far as I can tell. If it's not clear, the above mechanism is designed to give a binary the ability to be non-root but still setuid, with the necessary privileges being available, and for the normal current (namely the saved uid and uid switching) mechanisms to be used for turning the extra abilities. Note on this that the nosuid switch should probably also turn off recognition of above-65535 (or whatever - should be configurable) gids over NFS, or of uids having such by default. This is admittedly a problem as compared to the non-group privileges setup, although I'm not sure how many filesystem operations should have the necessary privileges modified in any event. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 01:29:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20422 for freebsd-security-outgoing; Thu, 25 Jun 1998 01:29:18 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from iq.org (proff@polysynaptic.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA20411 for ; Thu, 25 Jun 1998 01:28:56 -0700 (PDT) (envelope-from proff@iq.org) Received: (qmail 14083 invoked by uid 110); 25 Jun 1998 08:28:30 -0000 To: sthaug@nethelp.no Cc: chuck+ipfilter@snew.com, 7gprn@qlink.queensu.ca, ipfilter@postbox.anu.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: Firewall requirements References: <19980624104152.63811@yerkes.com> <28166.898701790@verdi.nethelp.no> From: Julian Assange Date: 25 Jun 1998 18:28:30 +1000 In-Reply-To: sthaug@nethelp.no's message of "Wed, 24 Jun 1998 17:23:10 +0200" Message-ID: Lines: 39 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no writes: > > You will not likely get 100Meg through a PC. I presume you will > > actually have multiple 100Meg cards? > > > > Now the processors are fast, but the caches are small and the bus > > speed aren't great. I haven't played with the 100MHz Motherboards > > yet, but I've not gotten close to that throughput on a consumer PC. > > I may be wrong; I last looked when Pentiums were reaching for 200MHz > > and they couldn't come close. > > I have no experience using ipfilter on a saturated 100 Mbps Ethernet > segment. But I can tell you that PCs have been able to send and receive > a full 100 Mbps data stream (no ipfilter) for quite a while. I measured > 95 Mbps (effective, application to application) on a lowly P-133 running > FreeBSD more than a year ago, using either ttcp or NetPerf. Network cards > were either DEC based or Intel Pro 100/B. > > A 400 MHz PII with BX chipset and 100 MHz bus should do considerably > better. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no 100Mb for ipfilter on a decent platform should be no problem. I haven't extensively tested ipfilter for speed, but I _have_ written a BSD packet "laundering" device (/dev/launder), which can steal a load of (;) of packets from the network, pass it through userland, wash it, and hang it out to dry on the network stack at over 100Mbps on a measly p100. Ipfilter has a lot less over-head and memory movement than this, and provided the mtu is large and the ruleset isn't hundreds of entries long, should be able to keep up with 100mps traffic quite easily. On an interesting side-note, I found routing packets through /dev/launder from a 10mps link actually improved tcp performance by 5%. Quite strange that. Cheers, Julian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 04:20:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA17604 for freebsd-security-outgoing; Thu, 25 Jun 1998 04:20:15 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from lohi.clinet.fi (root@lohi.clinet.fi [194.100.0.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA17501 for ; Thu, 25 Jun 1998 04:20:03 -0700 (PDT) (envelope-from hsu@mail.clinet.fi) Received: from katiska.clinet.fi (katiska.clinet.fi [194.100.0.4]) by lohi.clinet.fi (8.9.0/8.9.0) with ESMTP id OAA25941; Thu, 25 Jun 1998 14:21:09 +0300 (EEST) Received: (from hsu@localhost) by katiska.clinet.fi (8.9.0/8.9.0) id OAA14228; Thu, 25 Jun 1998 14:19:14 +0300 (EEST) From: Heikki Suonsivu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13714.12849.443301.474422@katiska.clinet.fi> Date: Thu, 25 Jun 1998 14:19:13 +0300 (EEST) To: Julian Assange Cc: sthaug@nethelp.no, chuck+ipfilter@snew.com, 7gprn@qlink.queensu.ca, ipfilter@postbox.anu.edu.au, freebsd-security@FreeBSD.ORG Subject: Re: Firewall requirements In-Reply-To: References: <19980624104152.63811@yerkes.com> <28166.898701790@verdi.nethelp.no> X-Mailer: VM 6.47 under Emacs 19.34.1 Organization: Clinet Ltd, Espoo, Finland Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Assange writes: > measly p100. Ipfilter has a lot less over-head and memory movement > than this, and provided the mtu is large and the ruleset isn't > hundreds of entries long, should be able to keep up with 100mps > traffic quite easily. The problem is that the ruleset is usually long if we are talking about multiport routers built on top of FreeBSD, because there are number of rules for each port. On ciscos access lists are port-specific, which reduces linear accesses quite a bit. It would be better to have O(log n) algorithm for address matching, like radix tree a'la routing table. P90 does not seem to keep up with 100 Mbps even when large packets are transferred with 50 rules (cpu goes 100% before reaching 100 Mbps). I haven't really tried faster routers. I think this kind of performance tests should be done with smaller average packet size to get better estimates, or compare pps values instead of bps values like router manufacturers do. > On an interesting side-note, I found routing packets through > /dev/launder from a 10mps link actually improved tcp performance > by 5%. Quite strange that. > > Cheers, > Julian. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-9-43542270 fax -4555276 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 04:36:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19565 for freebsd-security-outgoing; Thu, 25 Jun 1998 04:36:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA19553 for ; Thu, 25 Jun 1998 04:36:25 -0700 (PDT) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199806251136.EAA19553@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA120274511; Thu, 25 Jun 1998 21:35:11 +1000 From: Darren Reed Subject: Re: bsd securelevel patch question To: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 25 Jun 1998 21:35:11 +1000 (EST) Cc: dg@root.com, tqbf@pobox.com, easmith@beatrice.rutgers.edu, njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com In-Reply-To: from "Niall Smart" at Jun 24, 98 09:20:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Niall Smart, sie said: > > > for granting access to privileged resources and capabilities. I think the > > best way to handle this, however, is with a file ACL mechanism that allows > > for the specification of privileges as and extension of the access control > > information. On the other hand, in VMS, special privileges can be granted to > > Of course, this implies that all permissions can be represented in > the filesystem. I can imagine a /dev/socket/inet/xyz mechanism which > allows a process to bind to a specific port or /dev/raw which allows > them to create a raw socket etc etc. This gets somewhat messy for the > above example since it is difficult to administer things like ranges > (eg ports 0 to 1024) using a single device file for each element in that > range, and any other approach (e.g. /dev/socket/inet/0-1024) seems to > lose the cleanliness offered by the "single file for everything" approach. sockets can easily be done with portals, for which it is easy to do the above (been there, done that for a small trial). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 12:26:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09719 for freebsd-security-outgoing; Thu, 25 Jun 1998 12:26:47 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from chipweb.ml.org (qmailr@c1003518-a.plstn1.sfba.home.com [24.1.82.47]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA09497 for ; Thu, 25 Jun 1998 12:25:59 -0700 (PDT) (envelope-from ludwigp@bigfoot.com) Received: (qmail 14071 invoked by uid 666); 25 Jun 1998 19:25:43 -0000 Received: from speedy.chipweb.ml.org (172.16.1.1) by inet.chipweb.ml.org with SMTP; 25 Jun 1998 19:25:43 -0000 Message-Id: <3.0.3.32.19980625122541.006988b8@mail.plstn1.sfba.home.com> X-Sender: ludwigp@mail.plstn1.sfba.home.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 25 Jun 1998 12:25:41 -0700 To: security@FreeBSD.ORG From: Ludwig Pummer Subject: kerberos su problems betw 2 machines Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've finally gotten Kerberos (as part of the des distribution) installed on my 2.2.6-R machine (called fortress, with a DNS cname called kerberos) and my 2.2.5-R machine (called inet). my krb.conf: CHIPWEB.ML.ORG CHIPWEB.ML.ORG fortress.chipweb.ml.org admin server CHIPWEB.ML.ORG kerberos.chipweb.ml.org my krb.realms: fortress.chipwb.ml.org CHIPWEB.ML.ORG .chipweb.ml.org CHIPWEB.ML.ORG fortress is also running my own DNS server, which is why *.chipweb.ml.org appears as 24.1.82.47 to the outside world, but internally I have 6-7 machines in the domain chipweb.ml.org (using the 172.16.0.0/16 IP range). I set up kerberos on fortress according to the handbook, creating passwd.fortress, rcmd.fortress, passwd.inet, rcmd.inet, fortress's srvtab, and inet's srvtab. I also created ludwigp and ludwigp.root (for testing the SU acl). On fortress, logging in as ludwigp gives me my ticket. I can kinit to ludwigp.root and also su to root (i've set up the .klogin for root to be "ludwigp.root@CHIPWEB.ML.ORG"). On inet, logging in as ludwigp gives me my ticket. I can kinit to ludwigp.root and get my ticket, but trying to do su gives me "su: kerberos: unable to verify rcmd ticket: Incorrect network address (krb_rd_req)". Another thing which bothered me: I downloaded the kerberized telnet from ftp://ftp.pdc.kth.se/pub/krb/binaries/i386-unknown-winnt4.0/ and it telnets into fortress with encryption, giving me my proper tickets (the telnet program has its own ticket lister). Trying to do the same with inet doesn't work; i get a normal telnet connection, without encryption or tickets. Both systems have the r* services disabled in inetd, but the Kerberos authenticated serverices (r* -k) are enabled. The server is also running the additional registerd and kpasswdd services. Any reason why 2.2.5-R's kerberos behaves differently and can't communicate the same as 2.2.6-R's kerberos? Another question: If I want kerberos to be the only place the passwords are stored (since my master.passwd isn't being changed when passwd is used to change the kerberos password), how would I go about doing that? --Ludwig Pummer ludwigp@bigfoot.com ICQ UIN: 692441 http://chipweb.home.ml.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 20:23:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA23668 for freebsd-security-outgoing; Thu, 25 Jun 1998 20:23:58 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from blubb.pdc.kth.se ([18.70.0.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA23654 for ; Thu, 25 Jun 1998 20:23:48 -0700 (PDT) (envelope-from joda@pdc.kth.se) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 0ypP6z-00007r-00; Thu, 25 Jun 1998 23:23:41 -0400 To: Ludwig Pummer Cc: security@FreeBSD.ORG Subject: Re: kerberos su problems betw 2 machines References: <3.0.3.32.19980625122541.006988b8@mail.plstn1.sfba.home.com> X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 25 Jun 1998 23:23:38 -0400 In-Reply-To: Ludwig Pummer's message of "Thu, 25 Jun 1998 12:25:41 -0700" Message-ID: Lines: 56 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ludwig Pummer writes: > On inet, logging in as ludwigp gives me my ticket. I can kinit to > ludwigp.root and get my ticket, but trying to do su gives me "su: > kerberos: unable to verify rcmd ticket: Incorrect network address > (krb_rd_req)". This is most likely (but not necessarily) due to some hostname/address mismatch. If your machines ip-address doesn't match the A record in DNS, you get these problems. Likewise if you have more than one interface and your hostname doesn't point to the one that you use to talk to your KDC. Check what IP address the KDC thinks you are using by looking at the log. If you run multi-homed, you might also want to check the krb.equiv(5) man-page (this is not turned off in the FreeBSD dist, right?) If you successfully used a kerberized login, this is probably not your problem (depending on how paranoid your login is). Were you actually using a kerberized login, or did you login via normal password + kinit? > Another thing which bothered me: I downloaded the kerberized telnet > from ftp://ftp.pdc.kth.se/pub/krb/binaries/i386-unknown-winnt4.0/ > and it telnets into fortress with encryption, giving me my proper > tickets (the telnet program has its own ticket lister). Trying to do > the same with inet doesn't work; i get a normal telnet connection, > without encryption or tickets. Something in your setup is screwed. The voodoo telnet doesn't, unfortunately, have any fancy debugging options. What you can do is to turn on some debugging on the server side (with `telnetd -D options'). Do you get a ticket for `inet'? > Both systems have the r* services disabled in inetd, but the > Kerberos authenticated serverices (r* -k) are enabled. The server is > also running the additional registerd and kpasswdd services. Telnet uses telnet :-), so the r* aren't used. > Any reason why 2.2.5-R's kerberos behaves differently and can't > communicate the same as 2.2.6-R's kerberos? I don't know much about the FreeBSD packaging, so someone else has to answer this. > Another question: If I want kerberos to be the only place the > passwords are stored (since my master.passwd isn't being changed > when passwd is used to change the kerberos password), how would I go > about doing that? Just remove all password information from the passwd file (replacing with `*'). You will have to replace all programs that might use the password information (like login, ftpd, popper, xnlock, su...). Root is the only user that need to have a normal unix password. /Johan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Jun 25 23:46:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18622 for freebsd-security-outgoing; Thu, 25 Jun 1998 23:46:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18605 for ; Thu, 25 Jun 1998 23:46:19 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id JAA05542; Fri, 26 Jun 1998 09:46:02 +0300 (EEST) Date: Fri, 26 Jun 1998 09:46:02 +0300 (EEST) From: Narvi To: Ludwig Pummer cc: security@FreeBSD.ORG Subject: Re: kerberos su problems betw 2 machines In-Reply-To: <3.0.3.32.19980625122541.006988b8@mail.plstn1.sfba.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Jun 1998, Ludwig Pummer wrote: > I've finally gotten Kerberos (as part of the des distribution) installed on > my 2.2.6-R machine (called fortress, with a DNS cname called kerberos) and > my 2.2.5-R machine (called inet). > my krb.conf: > CHIPWEB.ML.ORG > CHIPWEB.ML.ORG fortress.chipweb.ml.org admin server > CHIPWEB.ML.ORG kerberos.chipweb.ml.org > my krb.realms: > fortress.chipwb.ml.org CHIPWEB.ML.ORG > .chipweb.ml.org CHIPWEB.ML.ORG > > fortress is also running my own DNS server, which is why *.chipweb.ml.org > appears as 24.1.82.47 to the outside world, but internally I have 6-7 > machines in the domain chipweb.ml.org (using the 172.16.0.0/16 IP range). > > I set up kerberos on fortress according to the handbook, creating > passwd.fortress, rcmd.fortress, passwd.inet, rcmd.inet, fortress's srvtab, > and inet's srvtab. > I also created ludwigp and ludwigp.root (for testing the SU acl). > > On fortress, logging in as ludwigp gives me my ticket. I can kinit to > ludwigp.root and also su to root (i've set up the .klogin for root to be > "ludwigp.root@CHIPWEB.ML.ORG"). > > On inet, logging in as ludwigp gives me my ticket. I can kinit to > ludwigp.root and get my ticket, but trying to do su gives me "su: kerberos: > unable to verify rcmd ticket: Incorrect network address (krb_rd_req)". I have seen this aswell. It comes from the fact that you kerberos server is known by more than one name/ip-adress combination. A workaround is to list the kerberos server in krb.conf by ip adress instead of name. > > Another thing which bothered me: I downloaded the kerberized telnet from > ftp://ftp.pdc.kth.se/pub/krb/binaries/i386-unknown-winnt4.0/ and it telnets > into fortress with encryption, giving me my proper tickets (the telnet > program has its own ticket lister). Trying to do the same with inet doesn't > work; i get a normal telnet connection, without encryption or tickets. > You have to give the standard telnet an extra parameter to get it to use encryption. Tickets should be issued if you log in with you kerberos (as opposed to normal) password. > Both systems have the r* services disabled in inetd, but the Kerberos > authenticated serverices (r* -k) are enabled. The server is also running > the additional registerd and kpasswdd services. > Telnet doesn't use these, it uses telnetd > Any reason why 2.2.5-R's kerberos behaves differently and can't communicate > the same as 2.2.6-R's kerberos? > It can - see above. > Another question: If I want kerberos to be the only place the passwords are > stored (since my master.passwd isn't being changed when passwd is used to > change the kerberos password), how would I go about doing that? > 1) Gice all users kerberos passwords 2) Change the passwords in the master.passwd file to * Oh - and do leave a local password for root - it may save you a reboot to single mode in some cases. And enables you to boot to single-user if the console is marked "unsecure". Sander > --Ludwig Pummer > ludwigp@bigfoot.com > ICQ UIN: 692441 http://chipweb.home.ml.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 05:32:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA28842 for freebsd-security-outgoing; Fri, 26 Jun 1998 05:32:58 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA28820 for ; Fri, 26 Jun 1998 05:32:44 -0700 (PDT) (envelope-from wosch@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id OAA06569; Fri, 26 Jun 1998 14:30:58 +0200 (CEST) (envelope-from wosch@panke.de.freebsd.org) Received: (from wosch@localhost) by campa.panke.de (8.8.8/8.8.8) id OAA01431; Fri, 26 Jun 1998 14:23:08 +0200 (MET DST) (envelope-from wosch) Message-ID: <19980626142307.02422@panke.de> Date: Fri, 26 Jun 1998 14:23:07 +0200 From: Wolfram Schneider To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: adduser chmod permissions References: <199806250059.KAA02884@gsms01.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199806250059.KAA02884@gsms01.alcatel.com.au>; from Peter Jeremy on Thu, Jun 25, 1998 at 10:59:08AM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1998-06-25 10:59:08 +1000, Peter Jeremy wrote: > >> - /etc/group is limited to 1024 char lines and no more than 200 users > >> per group. > >This was fixed 18 months ago in > >src/lib/libc/gen/getgrent.c rev 1.14 > > Looking through CVSROOT/src/lib/libc/gen/getgrent.c,v the CVS log does > say that. It also says `Not a 2.2 candidate' and the relevant code > does not appear to be in the 2.2.6-RELEASE version of > src/lib/libc/gen/getgrent.c :-(. > > FWIW, the other places I found that appear to impose these limits (at > least in 2.2.6-RELEASE) are src/libexec/mknetid/parse_group.c, > src/usr.sbin/pw/pw.h and src/usr.sbin/pw/pwupd.h. > > Why 18-month old code hasn't been moved from -current into -stable, I > can't say... Because it is a new feature and -stable is only for bugfixes. IMHO. A merge from current requires a lot of testing - the group database is a critical part of the OS. I don't have the time and the resources to do that. -- Wolfram Schneider http://www.freebsd.org/~w/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 08:34:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25582 for freebsd-security-outgoing; Fri, 26 Jun 1998 08:34:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns2.sminter.com.ar (ns2.sminter.com.ar [200.10.100.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25518 for ; Fri, 26 Jun 1998 08:33:35 -0700 (PDT) (envelope-from Recabarren!fpscha@ns2.sminter.com.ar) Received: (from uucp@localhost) by ns2.sminter.com.ar (8.8.5/8.8.4) id MAA19976 for freebsd.org!security; Fri, 26 Jun 1998 12:31:37 -0300 (GMT) >Received: (from fpscha@localhost) by localhost.schapachnik.com.ar (8.8.5/8.8.5) id OAA00260; Thu, 25 Jun 1998 14:23:27 -0300 (ARST) From: "Fernando P. Schapachnik" Message-Id: <199806251723.OAA00260@localhost.schapachnik.com.ar> Subject: Re: adduser chmod... To: security@FreeBSD.ORG Date: Thu, 25 Jun 1998 14:23:26 -0300 (ARST) Reply-To: fpscha@schapachnik.com.ar X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that BSD semantics for groups are fine but not perfect. For example: what happens is userA has some he whishes to share with userB and userC but not userD, and some others he whishes to share just with userD and userE? He has to ask sysadmin to make to groups just for him! An interesting approach would be having /etc/group and $HOME/.group. In that context a file owned by userA:group1 would mean "The owner of this file is userA, and the group is group1, whose members are those specified in /etc/group is group1 exists in that file, or the ones specified in ~userA/.group in another case". This schema will let users have as many groups as they wish and administer them without setuid programs. Another very interesting feature would be the possibility to have in $HOME/.group something like: my_family:*:~daddy meaning that the users who belong to this group are listed in daddy's group my_family. The purpose of this is to allow a group of user to stablish a "workgroup" and let just one of them be the maintainer. Two problems arise: 1) How to guarantee unicity between users' groups and -let's call them this way- /etc groups? A simple approach would be that a user group is considered invalid if it has the same name that a system group. In this case the groups behavior is like the empty group (ie, no user belogs to that group). When a user wants to stablish a new groups he just must check against /etc/group (a script can do this for him). What happens when root adds a new group, said group1. Well, existing users will have their own group1 behave like the empty group. But this shouldn't be a problem because we can have a daily scripts that whenevers finds /etc/group has been modified compares system groups against user groups and mails the affected users. An userland script could be provided to simplify "change all my the files that belong to group oldgroup to newgroup". 2) How to guarantee gid's unicity? This is the hardest part. Perhaps changid gid_t to long it and allowing a fixed number of groups per user? Something like it would mean that although saying "file A group is group1" is ambiguous, the ambiguity disappears once you get the gid, that's still unique. Most programs shouldn't note the change. Another posibility is that gid only makes sense knowing the uid. I particulary don't like it because means breaking a lot of software. Just an opinion ;-) Regards! Fernando P. Schapachnik fpscha@schapachnik.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 08:34:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25597 for freebsd-security-outgoing; Fri, 26 Jun 1998 08:34:21 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns2.sminter.com.ar (ns2.sminter.com.ar [200.10.100.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25525 for ; Fri, 26 Jun 1998 08:33:38 -0700 (PDT) (envelope-from Recabarren!fpscha@ns2.sminter.com.ar) Received: (from uucp@localhost) by ns2.sminter.com.ar (8.8.5/8.8.4) id MAA19971 for FreeBSD.ORG!security; Fri, 26 Jun 1998 12:31:36 -0300 (GMT) >Received: (from fpscha@localhost) by localhost.schapachnik.com.ar (8.8.5/8.8.5) id NAA00182; Thu, 25 Jun 1998 13:53:36 -0300 (ARST) From: "Fernando P. Schapachnik" Message-Id: <199806251653.NAA00182@localhost.schapachnik.com.ar> Subject: Re: non-executable stack? To: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 25 Jun 1998 13:53:35 -0300 (ARST) Cc: ncb05@uow.edu.au, security@FreeBSD.ORG In-Reply-To: from Niall Smart at "Jun 24, 98 03:09:30 pm" Reply-To: fpscha@schapachnik.com.ar X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior Niall Smart escribi¢: > be to only turn it on for set[ug]id executables. There are a number > of other "features" like this that would be useful, for example the > ability to specify that only printable ascii characters can appear in > the arguments or environment of a process before it can exec another. Don't forget about "international" users. We consider strings like "compa¤¡a" perfectly valid ;-) Regards! Fernando P. Schapachnik fpscha@schapachnik.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 09:38:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07184 for freebsd-security-outgoing; Fri, 26 Jun 1998 09:38:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hood.1lo.lublin.pl (sopel@hood.1lo.lublin.pl [193.59.31.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07148 for ; Fri, 26 Jun 1998 09:37:53 -0700 (PDT) (envelope-from sopel@hood.1lo.lublin.pl) Received: from localhost (sopel@localhost) by hood.1lo.lublin.pl (8.9.0/8.8.8) with SMTP id RAA18715; Fri, 26 Jun 1998 17:39:44 GMT (envelope-from sopel@hood.1lo.lublin.pl) Date: Fri, 26 Jun 1998 17:39:44 +0000 (GMT) From: Wojciech Sobczuk To: fpscha@schapachnik.com.ar cc: Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: <199806251653.NAA00182@localhost.schapachnik.com.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id JAA07175 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Jun 1998, Fernando P. Schapachnik wrote: > En un mensaje anterior Niall Smart escribi¢: > > be to only turn it on for set[ug]id executables. There are a number > > of other "features" like this that would be useful, for example the > > ability to specify that only printable ascii characters can appear in > > the arguments or environment of a process before it can exec another. > > Don't forget about "international" users. We consider strings like > "compa¤¡a" perfectly valid ;-) > > Regards! > > Fernando P. Schapachnik > fpscha@schapachnik.com.ar > hmm.. i always thought that '$' and '!' ARE printable characters.. check out `man 3 isprint` wojtek - Wojtek Sobczuk aka sopel (a franc-tireur) - - sopel@hood.1lo.lublin.pl || wojtek@gaja.ipan.lublin.pl - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 10:18:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14812 for freebsd-security-outgoing; Fri, 26 Jun 1998 10:18:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from pubnix.org (www.pubnix.org [155.229.39.88]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14689 for ; Fri, 26 Jun 1998 10:18:26 -0700 (PDT) (envelope-from jtb@pubnix.org) Received: from localhost (jtb@localhost) by pubnix.org (8.8.8/NooWop) with SMTP id NAA01425; Fri, 26 Jun 1998 13:16:26 -0400 (EDT) Date: Fri, 26 Jun 1998 13:16:24 -0400 (EDT) From: jtb To: Wojciech Sobczuk cc: fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id KAA14707 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, Brian Matthews brought this idea up to me last fall, and the more I've been thinking about it lately, why not just deny a handful of ctrl-char's that a buffer overflow needs, i.e. 0x90, 0xff, etc. I'd have to say there is a minimal number of ctrl-char's we can disallow to stop your average script kiddie from sending shellcode into a process via cmdline or environment arguments. This method won't really protect against attacks involving sscanf()'ing data from files ala the Vixie Cron bug for RH 4.x, but security will definitely be improved with minimal loses funcionality-wise. Let me know what you guys think. All replies are welcomed, critical or not. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jonathan T. Bowie ADM w00w00 WSD jobe@sekurity.org jtb@pubnix.org jobe@dataforce.net Independant Security Developer Home: (603)436-5698 "I'd hate to advocate drugs, sex, alcohol, or Cell: (603)553-6697 violence... to any one, but they've worked for me." -- Hunter S. Thompson =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= On Fri, 26 Jun 1998, Wojciech Sobczuk wrote: > On Thu, 25 Jun 1998, Fernando P. Schapachnik wrote: > > > En un mensaje anterior Niall Smart escribi¢: > > > be to only turn it on for set[ug]id executables. There are a number > > > of other "features" like this that would be useful, for example the > > > ability to specify that only printable ascii characters can appear in > > > the arguments or environment of a process before it can exec another. > > > > Don't forget about "international" users. We consider strings like > > "compa¤¡a" perfectly valid ;-) > > > > Regards! > > > > Fernando P. Schapachnik > > fpscha@schapachnik.com.ar > > > hmm.. i always thought that '$' and '!' ARE printable characters.. > check out `man 3 isprint` > > wojtek > > - Wojtek Sobczuk aka sopel (a franc-tireur) - > - sopel@hood.1lo.lublin.pl || wojtek@gaja.ipan.lublin.pl - > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 14:17:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04530 for freebsd-security-outgoing; Fri, 26 Jun 1998 14:17:56 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04285; Fri, 26 Jun 1998 14:16:44 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA00787; Fri, 26 Jun 1998 17:16:40 -0400 (EDT) Date: Fri, 26 Jun 1998 17:16:40 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: Announcement: Experimental Authentication and Authorization Token Management Extensions in the FreeBSD Kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Experimental Authentication and Authorization Token Management Extensions in the FreeBSD Kernel Robert Watson Abstract FreeBSD, a derivative of the 4.4BSDlite research operating system developed at the University of California at Berkeley, is used in a variety of networked and stand-alone computing environments. FreeBSD makes use of a simple yet flexible user-based authorization model following the UNIX example. However, this model is not scalable across large computing infrastructures with multiple administrative domains, and the model does not interact well with the differing paradigms supported by a variety of network operating systems. This document proposes a set of extensions to the FreeBSD kernel providing both authentication and authorization "tokens", allowing greater flexibility in supporting a variety of authentication and authorization models. Tokens are the kernel's representation of a fragment of data relating to the capabilities and keying material associated with a set of processes, or Process Authentication Group (PAG). A sample implementation of a subset of the described token behavior via a loadable kernel module available for download, along with a set of utilities for experimenting with the token behavior. Expansion on the implementation to provide additional features and sample uses will be forthcoming. URL: http://www.watson.org/fbsd-hardening/tokens/ Email: robert+sec.ktokens@cyrus.watson.org The freebsd-security@freebsd.org mailing list is also an appropriate place to discuss the issues involved. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Jun 26 21:11:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07248 for freebsd-security-outgoing; Fri, 26 Jun 1998 21:11:11 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from brooklyn.slack.net (root@brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07239 for ; Fri, 26 Jun 1998 21:11:07 -0700 (PDT) (envelope-from pfm@brooklyn.slack.net) Received: from localhost (pfm@localhost) by brooklyn.slack.net (8.8.7/8.8.7) with SMTP id AAA06975; Sat, 27 Jun 1998 00:13:43 -0400 (EDT) Date: Sat, 27 Jun 1998 00:13:42 -0400 (EDT) From: Patrick McAndrew To: jtb cc: Wojciech Sobczuk , fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 26 Jun 1998, jtb wrote: > Actually, Brian Matthews brought this idea up to me last fall, and the > more I've been thinking about it lately, why not just deny a handful of > ctrl-char's that a buffer overflow needs, i.e. 0x90, 0xff, etc. I'd have > to say there is a minimal number of ctrl-char's we can disallow to stop > your average script kiddie from sending shellcode into a process via > cmdline or environment arguments. This method won't really protect > against attacks involving sscanf()'ing data from files ala the Vixie Cron > bug for RH 4.x, but security will definitely be improved with minimal > loses funcionality-wise. Let me know what you guys think. All replies > are welcomed, critical or not. Why bother? Just practice good security programming and check bounds. It would be much easier to fix a getc() call than to write an entire function that checks for certain control characters that were passed.. Rember, "keep it simpe stupid" :) Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 01:18:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA06154 for freebsd-security-outgoing; Sat, 27 Jun 1998 01:18:08 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06110 for ; Sat, 27 Jun 1998 01:18:05 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id DAA19951 for freebsd-security@freebsd.org; Sat, 27 Jun 1998 03:18:04 -0500 (CDT) Date: Sat, 27 Jun 1998 03:18:04 -0500 (CDT) From: Igor Roshchin Message-Id: <199806270818.DAA19951@alecto.physics.uiuc.edu> To: freebsd-security@FreeBSD.ORG Subject: (FWD) QPOPPER REMOTE ROOT EXPLOIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This dumps core on a 2.2.5-RELEASE box. After sending over 40 thousand of symbols I just kill -HUP the connection to the popper, and it dumps the core. I don't know how exploitable it though. Anybody can come up with a quick patch ? Thanks, IgoR >From owner-bugtraq@NETSPACE.ORG Sat Jun 27 01:32:44 1998 Return-Path: Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by alecto.physics.uiuc.edu (8.9.0/8.9.0) with ESMTP id BAA09012 for ; Sat, 27 Jun 1998 01:32:43 -0500 (CDT) Received: from unknown@netspace.org (port 24361 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96303-23463>; Sat, 27 Jun 1998 02:33:46 -0400 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1429436 for BUGTRAQ@NETSPACE.ORG; Sat, 27 Jun 1998 02:31:20 -0400 Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by netspace.org (8.8.7/8.8.7) with ESMTP id CAA06737 for ; Sat, 27 Jun 1998 02:30:07 -0400 Received: from unknown@netspace.org (port 24361 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80634-23467>; Sat, 27 Jun 1998 02:32:05 -0400 Approved-By: aleph1@DFW.NET Received: from musket.eliwhitney.org ([209.182.72.70]) by netspace.org (8.8.7/8.8.7) with ESMTP id BAA28453 for ; Sat, 27 Jun 1998 01:02:39 -0400 Received: from dell166 ([199.174.185.18]) by musket.eliwhitney.org (Netscape Messaging Server 3.5) with SMTP id 373 for ; Sat, 27 Jun 1998 01:04:21 -0400 X-Sender: X-Mailer: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <19980627050419750.AAA323.373@dell166> Date: Sat, 27 Jun 1998 00:58:24 -0400 Reply-To: Seth McGann Sender: Bugtraq List From: Seth McGann Subject: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT To: BUGTRAQ@NETSPACE.ORG Status: RO Its come to my attention that systems around the internet are being exploited using a new remote overflow in Qualcomm's Popper server. Well, lets clear a few things up: 1. The working exploit was stolen from my development account, subsequently MANY sites were cracked in short order. Much of Efnet was compromised as power crazed script kiddies gained root access on IRCOP boxes, giving themselves O-lines. 2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far. Other systems are most certainly vulnerable. Linux does not appear vulnerable. To test, simply send the sever several thousand characters and see if it crashed. Check the return address to see if it matches. 3. Due to massive exploitation the proper authorities have most likely been notified already. This is a bit of an emergency. 4. You will NOT get the "exploit" from me, don't ask. If you think your "eleet" enough, do it yourself. I admit I had some help, but it took a while to figure out. 5. The most obvious offender is the vsprintf() on line 66 of pop_msg.c. 6. If you have a problem with my style, I'm sorry. I'm angry at both myself and the members of #conflict who I hold directly responsible for this breach. I will not name names, the offenders know who they are. 7. When I have my head together I will post a patch tomorrow if one is not available by then. 8. For now, disable qpopper or choose another solution till qpopper is secured. Thank you. Seth M. McGann / smm@wpi.edu "Security is making it http://www.wpi.edu/~smm to the bathroom in time." KeyID: 2048/1024/E2501C80 Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 02:20:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14148 for freebsd-security-outgoing; Sat, 27 Jun 1998 02:20:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bow.net (root@bow.net [204.216.183.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14105 for ; Sat, 27 Jun 1998 02:20:26 -0700 (PDT) (envelope-from bow@bow.net) Received: from [204.210.38.36] (dt063n24.san.rr.com [204.210.38.36]) by bow.net (8.9.0/8.9.0) with ESMTP id CAA19778; Sat, 27 Jun 1998 02:21:02 -0700 (PDT) Date: Sat, 27 Jun 1998 02:21:02 -0700 (PDT) Message-Id: In-Reply-To: <199806270818.DAA19951@alecto.physics.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Igor Roshchin From: bow Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a realllly quick fix. There is probably 100 ways to do it better, but this is better then turning qpopper off. -bow *** qpopper2.41beta1-qfix/pop_msg.c Wed Nov 19 13:20:38 1997 --- qpopper2.41beta1/pop_msg.c Sat Jun 27 02:15:59 1998 *************** *** 63,74 **** /* Append the message (formatted, if necessary) */ if (format) #ifdef HAVE_VPRINTF ! vsprintf(mp,format,ap); #else # ifdef PYRAMID ! (void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6); # else ! (void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2], ((int *)ap)[3],((int *)ap)[4]); # endif #endif --- 63,74 ---- /* Append the message (formatted, if necessary) */ if (format) #ifdef HAVE_VPRINTF ! vsnprintf(mp,MAXLINELEN-8,format,ap); #else # ifdef PYRAMID ! (void)snprintf(mp,MAXLINELEN-8,format, arg1, arg2, arg3, arg4, arg5, arg6); # else ! (void)snprintf(mp,MAXLINELEN-8,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2], ((int *)ap)[3],((int *)ap)[4]); # endif #endif >This dumps core on a 2.2.5-RELEASE box. >After sending over 40 thousand of symbols I just kill -HUP the >connection to the popper, and it dumps the core. >I don't know how exploitable it though. > >Anybody can come up with a quick patch ? > > >Thanks, >IgoR > > >>From owner-bugtraq@NETSPACE.ORG Sat Jun 27 01:32:44 1998 >Return-Path: >Received: from brimstone.netspace.org (brimstone.netspace.org >[128.148.157.143]) > by alecto.physics.uiuc.edu (8.9.0/8.9.0) with ESMTP id BAA09012 > for ; Sat, 27 Jun 1998 01:32:43 -0500 >(CDT) >Received: from unknown@netspace.org (port 24361 [128.148.157.6]) by >brimstone.netspace.org with ESMTP id <96303-23463>; Sat, 27 Jun 1998 >02:33:46 -0400 >Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) >with > spool id 1429436 for BUGTRAQ@NETSPACE.ORG; Sat, 27 Jun 1998 02:31:20 > -0400 >Received: from brimstone.netspace.org (brimstone.netspace.org > [128.148.157.143]) by netspace.org (8.8.7/8.8.7) with ESMTP id > CAA06737 for ; Sat, 27 Jun 1998 02:30:07 -0400 >Received: from unknown@netspace.org (port 24361 [128.148.157.6]) by > brimstone.netspace.org with ESMTP id <80634-23467>; Sat, 27 Jun 1998 > 02:32:05 -0400 >Approved-By: aleph1@DFW.NET >Received: from musket.eliwhitney.org ([209.182.72.70]) by netspace.org > (8.8.7/8.8.7) with ESMTP id BAA28453 for ; >Sat, > 27 Jun 1998 01:02:39 -0400 >Received: from dell166 ([199.174.185.18]) by musket.eliwhitney.org (Netscape > Messaging Server 3.5) with SMTP id 373 for ; > Sat, 27 Jun 1998 01:04:21 -0400 >X-Sender: X-Mailer: >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Message-ID: <19980627050419750.AAA323.373@dell166> >Date: Sat, 27 Jun 1998 00:58:24 -0400 >Reply-To: Seth McGann >Sender: Bugtraq List >From: Seth McGann >Subject: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT >To: BUGTRAQ@NETSPACE.ORG >Status: RO > >Its come to my attention that systems around the internet are being >exploited using a new remote overflow in Qualcomm's Popper server. Well, >lets clear a few things up: > >1. The working exploit was stolen from my development account, >subsequently MANY sites were cracked in short order. Much of Efnet was >compromised as power crazed script kiddies gained root access on IRCOP >boxes, giving themselves O-lines. > >2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far. >Other systems are most certainly vulnerable. Linux does not appear >vulnerable. To test, simply send the sever several thousand characters and >see if it crashed. Check the return address to see if it matches. > >3. Due to massive exploitation the proper authorities have most likely >been notified already. This is a bit of an emergency. > >4. You will NOT get the "exploit" from me, don't ask. If you think your >"eleet" enough, do it yourself. I admit I had some help, but it took a >while to figure out. > >5. The most obvious offender is the vsprintf() on line 66 of pop_msg.c. > >6. If you have a problem with my style, I'm sorry. I'm angry at both >myself and the members of #conflict who I hold directly responsible for >this breach. I will not name names, the offenders know who they are. > >7. When I have my head together I will post a patch tomorrow if one is not >available by then. > >8. For now, disable qpopper or choose another solution till qpopper is >secured. > >Thank you. > > > >Seth M. McGann / smm@wpi.edu "Security is making it >http://www.wpi.edu/~smm to the bathroom in time." >KeyID: 2048/1024/E2501C80 >Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80 > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 03:07:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA21614 for freebsd-security-outgoing; Sat, 27 Jun 1998 03:07:57 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (9df69Gvr/jlafjFbVbkFgWsChIjmYN4P@heron.doc.ic.ac.uk [146.169.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA21601 for ; Sat, 27 Jun 1998 03:07:47 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([KTN53/4oxxsJ2KaQYV3lXopB7BF39KHT]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0yprtD-0002VF-00; Sat, 27 Jun 1998 11:07:23 +0100 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0yprtC-0006B4-00; Sat, 27 Jun 1998 11:07:22 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Sat, 27 Jun 1998 11:07:22 +0100 In-Reply-To: Patrick McAndrew "Re: non-executable stack?" (Jun 27, 12:13am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Patrick McAndrew , jtb Subject: Re: non-executable stack? Cc: Wojciech Sobczuk , fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jun 27, 12:13am, Patrick McAndrew wrote: } Subject: Re: non-executable stack? > > > On Fri, 26 Jun 1998, jtb wrote: > > > Actually, Brian Matthews brought this idea up to me last fall, and the > > more I've been thinking about it lately, why not just deny a handful of > > ctrl-char's that a buffer overflow needs, i.e. 0x90, 0xff, etc. I'd have > > to say there is a minimal number of ctrl-char's we can disallow to stop > > your average script kiddie from sending shellcode into a process via > > cmdline or environment arguments. This method won't really protect > > against attacks involving sscanf()'ing data from files ala the Vixie Cron > > bug for RH 4.x, but security will definitely be improved with minimal > > loses funcionality-wise. Let me know what you guys think. All replies > > are welcomed, critical or not. > > Why bother? Just practice good security programming and check bounds. It > would be much easier to fix a getc() call than to write an entire function > that checks for certain control characters that were passed.. Rember, > "keep it simpe stupid" :) You misunderstand. My proposal, seemingly seconded by jtb, was to allow the administrator to disallow the presence of non-printable ascii characters in the environment or command line arguments at the time of execve of certain processes. We still don't know if this will have any effect on security though, since no-one has checked to see if its possible to write shellcode using just printable ASCII. It would certainly make life difficult for the attacker, since it would be impossible to overwrite the saved eip with an address on the stack since the stack is at the top of the address space around 0xFFxxxxxx or 0xEFxxxxxx. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 03:26:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA23496 for freebsd-security-outgoing; Sat, 27 Jun 1998 03:26:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23488 for ; Sat, 27 Jun 1998 03:26:21 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id DAA28464; Sat, 27 Jun 1998 03:26:51 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: bow cc: Igor Roshchin , freebsd-security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-reply-to: Your message of "Sat, 27 Jun 1998 02:21:02 PDT." Date: Sat, 27 Jun 1998 03:26:51 -0700 Message-ID: <28461.898943211@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This is a realllly quick fix. > There is probably 100 ways to do it better, but this is better then turning > qpopper off. I've already committed a slightly more intelligent fix to this problem. Thanks! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 08:41:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA24222 for freebsd-security-outgoing; Sat, 27 Jun 1998 08:41:59 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from piggy.kharkiv.net (piggy.kharkiv.net [194.44.156.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA24137 for ; Sat, 27 Jun 1998 08:41:26 -0700 (PDT) (envelope-from news@piggy.kharkiv.net) Received: (from news@localhost) by piggy.kharkiv.net (8.8.8-MVC/8.8.8/piggy) id SAA10247; Sat, 27 Jun 1998 18:40:37 +0300 (EEST) (envelope-from news) To: freebsd-security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT Date: Sat, 27 Jun 1998 18:40:35 +0300 Message-ID: <35951273.6488@kharkiv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; AIX 2) X-Via: News-To-Mail v1.0 From: "Vadim V. Chepkov" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard wrote: > > > I've already committed a slightly more intelligent fix to this > problem. Thanks! > But it doesn't work -r-xr-xr-x 1 bin bin 45056 Jun 27 18:26 /usr/local/libexec/popper Jun 27 18:28:33 host popper[9784]: @host.foo.bar: -ERR Unknown command: "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee Jun 27 18:28:33 host /kernel: pid 9784 (popper), uid 0: exited on signal 11 -- Kind regards, Vadim V. Chepkov Kharkiv Online ISP ------------------------------------------------------ Vadim V. Chepkov, Kharkiv State Polytechnic University 21 Frunze Str., Kharkiv, Ukraine, 310002 Tel: +380 572 400279 Fax: +380 572 400592 e-mail: vvc@kharkiv.net http://www.kharkiv.net/~vvc ------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 10:08:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03565 for freebsd-security-outgoing; Sat, 27 Jun 1998 10:08:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03547 for ; Sat, 27 Jun 1998 10:08:34 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id KAA02903; Sat, 27 Jun 1998 10:07:29 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Vadim V. Chepkov" cc: freebsd-security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-reply-to: Your message of "Sat, 27 Jun 1998 18:40:35 +0300." <35951273.6488@kharkiv.net> Date: Sat, 27 Jun 1998 10:07:29 -0700 Message-ID: <2899.898967249@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Jordan K. Hubbard wrote: > > > > > > I've already committed a slightly more intelligent fix to this > > problem. Thanks! > > > > But it doesn't work Then there is more than one overflow, unless you can show me precisely why the change I've already made "doesn't work?" - what you've shown me so far could come from any number of other places in the code and I never claimed to fix *all* potential overflows, just that one. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 11:36:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12025 for freebsd-security-outgoing; Sat, 27 Jun 1998 11:36:23 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12010 for ; Sat, 27 Jun 1998 11:36:18 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id NAA24833; Sat, 27 Jun 1998 13:36:15 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id NAA00629; Sat, 27 Jun 1998 13:36:14 -0500 (CDT) Message-ID: <19980627133614.42227@mcs.net> Date: Sat, 27 Jun 1998 13:36:14 -0500 From: Karl Denninger To: "Vadim V. Chepkov" Cc: freebsd-security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT References: <35951273.6488@kharkiv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <35951273.6488@kharkiv.net>; from Vadim V. Chepkov on Sat, Jun 27, 1998 at 06:40:35PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Declare the variable static, among other things. Now if you overrun it you cannot corrupt the return stack, as the variable is allocated out of bss at program init, not off the stack as an automatic variable. That's a valid (if messy) "quick fix" for these kinds of problems. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Sat, Jun 27, 1998 at 06:40:35PM +0300, Vadim V. Chepkov wrote: > Jordan K. Hubbard wrote: > > > > > > I've already committed a slightly more intelligent fix to this > > problem. Thanks! > > > > But it doesn't work > > -r-xr-xr-x 1 bin bin 45056 Jun 27 18:26 /usr/local/libexec/popper > > Jun 27 18:28:33 host popper[9784]: @host.foo.bar: -ERR Unknown command: > "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee > Jun 27 18:28:33 host /kernel: pid 9784 (popper), uid 0: exited on signal > 11 > > -- > > Kind regards, > Vadim V. Chepkov > Kharkiv Online ISP > ------------------------------------------------------ > Vadim V. Chepkov, Kharkiv State Polytechnic University > 21 Frunze Str., Kharkiv, Ukraine, 310002 > Tel: +380 572 400279 Fax: +380 572 400592 > e-mail: vvc@kharkiv.net http://www.kharkiv.net/~vvc > ------------------------------------------------------ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 12:04:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14735 for freebsd-security-outgoing; Sat, 27 Jun 1998 12:04:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from infowest.com (infowest.com [204.17.177.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14730 for ; Sat, 27 Jun 1998 12:04:43 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from infowest.com (liberty.infowest.com [207.49.60.254]) by infowest.com (8.8.8/8.8.8) with ESMTP id NAA23938 for ; Sat, 27 Jun 1998 13:04:12 -0600 (MDT) Message-ID: <35954222.F20D2144@infowest.com> Date: Sat, 27 Jun 1998 13:04:02 -0600 From: "Aaron D. Gifford" X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT References: <35951273.6488@kharkiv.net> <19980627133614.42227@mcs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sat, Jun 27, 1998 at 06:40:35PM +0300, Vadim V. Chepkov wrote: > > Jordan K. Hubbard wrote: > > > > > > > > > I've already committed a slightly more intelligent fix to this > > > problem. Thanks! > > > > > > > But it doesn't work > > <> Does the patch to pop_msg.c take into account that a "(void)strcat(message, "\r\n"); call appears later on and adds 2 more chars to the message buffer? I haven't seen JKH's patch yet, but I noticed that some of the patches posted to BUGTRAQ miss this. The result is that the perl trick still crashes popper, but the crash occurs on the strcat() call and not where the old vsprintf() call was. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 12:28:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17238 for freebsd-security-outgoing; Sat, 27 Jun 1998 12:28:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17229 for ; Sat, 27 Jun 1998 12:28:52 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id OAA00340; Sat, 27 Jun 1998 14:28:52 -0500 (CDT) Date: Sat, 27 Jun 1998 14:28:52 -0500 (CDT) From: Igor Roshchin Message-Id: <199806271928.OAA00340@alecto.physics.uiuc.edu> To: "Jordan K. Hubbard" Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: "Jordan K. Hubbard" > > Jordan K. Hubbard wrote: > > > > > > > > > I've already committed a slightly more intelligent fix to this > > > problem. Thanks! > > > > > > > But it doesn't work > Then there is more than one overflow, unless you can show me precisely > why the change I've already made "doesn't work?" - what you've shown > me so far could come from any number of other places in the code and > I never claimed to fix *all* potential overflows, just that one. > - Jordan THere seems to be yet another similar buffer overflow in pop_log.c (Credit to Tom Brown , Roy Hooper , and Miquel van Smoorenburg who posted it to BUGTRAQ) #ifdef HAVE_VPRINTF vsprintf(msgbuf,format,ap); #else M.v.S also noticed yet another overflow. His message is below. IgoR PS. Sorry for duplicating BUGTRAQ messages, especially, if Jordan and others are already working on this fix, having read those BUGTRAQ postings. ================ 8< ======================= >From owner-bugtraq@NETSPACE.ORG Sat Jun 27 11:11:32 1998 References: <19980627050419750.AAA323.373@dell166> Message-ID: <6n2t2q$398$1@Q.cistron.nl> Date: Sat, 27 Jun 1998 15:46:02 +0200 Reply-To: Miquel van Smoorenburg Sender: Bugtraq List From: Miquel van Smoorenburg Organization: Cistron Internet ervices B.V. Subject: Re: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT To: BUGTRAQ@NETSPACE.ORG In article <19980627050419750.AAA323.373@dell166>, Seth McGann wrote: >Its come to my attention that systems around the internet are being >exploited using a new remote overflow in Qualcomm's Popper server. Well, Oops! Here's a fix, that also fixes another thing I noted: buffer overflow in X-UIDL processing (compromise an account by sending mail to it ..) You need to put "HAVE_VSNPRINTF" in popper.h yourself if your O/S is not Linux and it supports vsnprintf() Patch relative to qpopper-2.3, the latest free version: diff -ruN qpopper-2.3.orig/pop_dropcopy.c qpopper-2.3/pop_dropcopy.c --- qpopper-2.3.orig/pop_dropcopy.c Sat Mar 29 05:30:36 1997 +++ qpopper-2.3/pop_dropcopy.c Sat Jun 27 15:33:07 1998 @@ -462,6 +462,9 @@ } else cp = ""; + /* Make UIDL not longer then 128 chars, we use it + in sprintf() later on */ + if (strlen(cp) >= 128) cp[127] = 0; mp->uidl_str = (char *)strdup(cp); mp->length += nchar + 1; p->drop_size += nchar + 1; diff -ruN qpopper-2.3.orig/pop_log.c qpopper-2.3/pop_log.c --- qpopper-2.3.orig/pop_log.c Sat Mar 29 05:30:36 1997 +++ qpopper-2.3/pop_log.c Sat Jun 27 15:33:07 1998 @@ -18,7 +18,11 @@ * log: Make a log entry */ +#ifdef HAVE_VSNPRINTF static char msgbuf[MAXLINELEN]; +#else +static char msgbuf[MAXLINELEN*4]; +#endif pop_log(va_alist) va_dcl @@ -46,6 +50,9 @@ arg6 = va_arg(ap, char *); #endif +#ifdef HAVE_VSNPRINTF + vsnprintf(msgbuf,sizeof(msgbuf),format,ap); +#else #ifdef HAVE_VSPRINTF vsprintf(msgbuf,format,ap); #else @@ -57,6 +64,7 @@ # endif va_end(ap); #endif +#endif if (p->debug && p->trace) { clock = time(0); @@ -67,6 +75,8 @@ (void)fflush(p->trace); } else { + /* Protect syslog from too long messages */ + if (strlen(msgbuf) >= 512) msgbuf[511] = 0; syslog (stat,"%s",msgbuf); } diff -ruN qpopper-2.3.orig/pop_msg.c qpopper-2.3/pop_msg.c --- qpopper-2.3.orig/pop_msg.c Sat Mar 29 05:30:36 1997 +++ qpopper-2.3/pop_msg.c Sat Jun 27 15:33:07 1998 @@ -34,7 +34,11 @@ #ifdef PYRAMID char * arg1, *arg2, *arg3, *arg4, *arg5, *arg6; #endif +#ifdef HAVE_VSNPRINTF char message[MAXLINELEN]; +#else + char message[MAXLINELEN * 4]; +#endif va_start(ap); p = va_arg(ap, POP *); @@ -63,6 +67,9 @@ /* Append the message (formatted, if necessary) */ if (format) +#ifdef HAVE_VSNPRINTF + vsnprintf(mp,sizeof(message) - strlen(mp) - 1, format,ap); +#else #ifdef HAVE_VSPRINTF vsprintf(mp,format,ap); #else @@ -72,6 +79,7 @@ (void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2], ((int *)ap)[3],((int *)ap)[4]); # endif +#endif #endif va_end(ap); diff -ruN qpopper-2.3.orig/popper.h qpopper-2.3/popper.h --- qpopper-2.3.orig/popper.h Mon Mar 31 22:10:18 1997 +++ qpopper-2.3/popper.h Sat Jun 27 15:33:56 1998 @@ -128,6 +128,7 @@ #endif #ifdef LINUX +# define HAVE_VSNPRINTF # define POP_MAILDIR "/var/spool/mail" # define POP_DROP "/var/spool/mail/.%s.pop" # define POP_TMPDROP "/var/spool/mail/tmpXXXXXX" -- Miquel van Smoorenburg | Our vision is to speed up time, miquels@cistron.nl | eventually eliminating it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 14:37:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04621 for freebsd-security-outgoing; Sat, 27 Jun 1998 14:37:53 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04616 for ; Sat, 27 Jun 1998 14:37:51 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id OAA03735; Sat, 27 Jun 1998 14:38:17 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Aaron D. Gifford" cc: security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-reply-to: Your message of "Sat, 27 Jun 1998 13:04:02 MDT." <35954222.F20D2144@infowest.com> Date: Sat, 27 Jun 1998 14:38:15 -0700 Message-ID: <3731.898983495@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Does the patch to pop_msg.c take into account that a "(void)strcat(message, > "\r\n"); call appears later on and adds 2 more chars to the message buffer? Heh, no. I missed that. Here's a revised patch: --- pop_msg.c.orig Sat Jun 27 03:09:47 1998 +++ pop_msg.c Sat Jun 27 14:35:49 1998 @@ -27,6 +27,7 @@ { POP * p; int stat; /* POP status indicator */ + int l, len; /* remaining buffer length */ char * format; /* Format string for the message */ va_list ap; register char * mp; @@ -50,6 +51,7 @@ /* Point to the message buffer */ mp = message; + len = sizeof(message); /* Format the POP status code at the beginning of the message */ if (stat == POP_SUCCESS) @@ -58,17 +60,18 @@ (void)sprintf (mp,"%s ",POP_ERR); /* Point past the POP status indicator in the message message */ - mp += strlen(mp); + l = strlen(mp); + len -= l, mp += l; /* Append the message (formatted, if necessary) */ if (format) #ifdef HAVE_VPRINTF - vsprintf(mp,format,ap); + vsnprintf(mp,len,format,ap); #else # ifdef PYRAMID - (void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6); + (void)snprintf(mp,len,format, arg1, arg2, arg3, arg4, arg5, arg6); # else - (void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2], + (void)snprintf(mp,len,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2], ((int *)ap)[3],((int *)ap)[4]); # endif #endif @@ -87,7 +90,8 @@ (p->user ? p->user : "(null)"), p->client, message); /* Append the */ - (void)strcat(message, "\r\n"); + len -= strlen(message); + (void)strncat(message, len, "\r\n"); /* Send the message to the client */ (void)fputs(message,p->output); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 14:48:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05841 for freebsd-security-outgoing; Sat, 27 Jun 1998 14:48:52 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05834 for ; Sat, 27 Jun 1998 14:48:51 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id OAA06137; Sat, 27 Jun 1998 14:49:25 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Igor Roshchin cc: freebsd-security@FreeBSD.ORG Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-reply-to: Your message of "Sat, 27 Jun 1998 14:28:52 CDT." <199806271928.OAA00340@alecto.physics.uiuc.edu> Date: Sat, 27 Jun 1998 14:49:25 -0700 Message-ID: <6133.898984165@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > THere seems to be yet another similar buffer overflow > in pop_log.c Fixed. Please cvsup the latest ports collection and make sure that ports/mail/popper is updated - all the new patches are in ports/mail/popper/patches/patch-ag. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 15:27:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11756 for freebsd-security-outgoing; Sat, 27 Jun 1998 15:27:16 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from pubnix.org (www.pubnix.org [155.229.39.88]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11751 for ; Sat, 27 Jun 1998 15:27:12 -0700 (PDT) (envelope-from jtb@pubnix.org) Received: from localhost (jtb@localhost) by pubnix.org (8.8.8/NooWop) with SMTP id SAA10050; Sat, 27 Jun 1998 18:24:57 -0400 (EDT) Date: Sat, 27 Jun 1998 18:24:56 -0400 (EDT) From: jtb To: Patrick McAndrew cc: Wojciech Sobczuk , fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What do you mean, checking for this is very easy, just before something gets executed, you take argv and envp and loop through them looking for those certain ascii characters, it's like 10-15 lines of code, if that. I don't see why you'd think that would be cumbersome to the kernel. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jonathan T. Bowie ADM w00w00 WSD jobe@sekurity.org jtb@pubnix.org jobe@dataforce.net Independant Security Developer Home: (603)436-5698 "I'd hate to advocate drugs, sex, alcohol, or Cell: (603)553-6697 violence... to any one, but they've worked for me." -- Hunter S. Thompson =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= On Sat, 27 Jun 1998, Patrick McAndrew wrote: > > > On Fri, 26 Jun 1998, jtb wrote: > > > Actually, Brian Matthews brought this idea up to me last fall, and the > > more I've been thinking about it lately, why not just deny a handful of > > ctrl-char's that a buffer overflow needs, i.e. 0x90, 0xff, etc. I'd have > > to say there is a minimal number of ctrl-char's we can disallow to stop > > your average script kiddie from sending shellcode into a process via > > cmdline or environment arguments. This method won't really protect > > against attacks involving sscanf()'ing data from files ala the Vixie Cron > > bug for RH 4.x, but security will definitely be improved with minimal > > loses funcionality-wise. Let me know what you guys think. All replies > > are welcomed, critical or not. > > Why bother? Just practice good security programming and check bounds. It > would be much easier to fix a getc() call than to write an entire function > that checks for certain control characters that were passed.. Rember, > "keep it simpe stupid" :) > > Pat > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 17:23:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22393 for freebsd-security-outgoing; Sat, 27 Jun 1998 17:23:58 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22388 for ; Sat, 27 Jun 1998 17:23:56 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id TAA04462; Sat, 27 Jun 1998 19:23:54 -0500 (CDT) From: Igor Roshchin Message-Id: <199806280023.TAA04462@alecto.physics.uiuc.edu> Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-Reply-To: <6133.898984165@time.cdrom.com> from "Jordan K. Hubbard" at "Jun 27, 1998 2:49:25 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 27 Jun 1998 19:23:54 -0500 (CDT) Cc: freebsd-security@FreeBSD.ORG, igor@alecto.physics.uiuc.edu (Igor Roshchin) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > THere seems to be yet another similar buffer overflow > > in pop_log.c > > Fixed. Please cvsup the latest ports collection and make sure > that ports/mail/popper is updated - all the new patches are in > ports/mail/popper/patches/patch-ag. > > - Jordan > Jordan, I've just downloaded "popper" directory from ftp://ftp.freebsd.org/.25/FreeBSD/FreeBSD-current/ports/mail It is still missing patch for the "UIDL" problem (pop_dropcopy.c) Several people had suggestion looking like: if (strlen(cp) >= 128) cp[127] = 0; before the line 497 as it appears in that file after patch-ad is applied. (originally, I believe, before 459 ) May be I am missing something, but I don't think that patch-ad, which is so far the only patch realted to pop_dropcopy.c addressed this problem Regards, IgoR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 17:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26365 for freebsd-security-outgoing; Sat, 27 Jun 1998 17:51:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26337 for ; Sat, 27 Jun 1998 17:51:08 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id TAA04771 for freebsd-security@freebsd.org; Sat, 27 Jun 1998 19:51:09 -0500 (CDT) From: Igor Roshchin Message-Id: <199806280051.TAA04771@alecto.physics.uiuc.edu> Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT (fwd) To: freebsd-security@FreeBSD.ORG Date: Sat, 27 Jun 1998 19:51:08 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Forwarded message from Igor Roshchin ----- > > > THere seems to be yet another similar buffer overflow > > > in pop_log.c > > > > Fixed. Please cvsup the latest ports collection and make sure > > that ports/mail/popper is updated - all the new patches are in > > ports/mail/popper/patches/patch-ag. > > > > - Jordan > > > > Jordan, > > I've just downloaded "popper" directory from > ftp://ftp.freebsd.org/.25/FreeBSD/FreeBSD-current/ports/mail > It is still missing patch for the "UIDL" problem > (pop_dropcopy.c) > > Several people had suggestion looking like: > if (strlen(cp) >= 128) cp[127] = 0; > > before the line 497 as it appears in that file after patch-ad is applied. > (originally, I believe, before 459 ) > > May be I am missing something, but I don't think that patch-ad, which is > so far the only patch realted to pop_dropcopy.c addressed this problem > > Regards, > > IgoR > Some more on this issue: I've update popper from 2.4b2. With the patches applied, popper 2.41beta1 (on a 2.2.5-RELEASE) dumps core just on any connection. Am I missing something ? alecto: [19:25] [471] ~>telnet mailhost.somedomain.com pop3 escape character is '^Y'. Trying 209.125.17.11... Connected to mailhost.somedomain.com. Escape character is '^Y'. Connection closed by foreign host. alecto: [19:25] [472] ~>l /tmp/STRING -rw------- 1 igor group 48406 Jun 27 02:44 /tmp/STRING Jun 27 20:25:40 mailhost /kernel: pid 13587 (popper), uid 0: exited on signal 11 (core dumped) IgoR ----- End of forwarded message from Igor Roshchin ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 17:53:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26700 for freebsd-security-outgoing; Sat, 27 Jun 1998 17:53:12 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26681 for ; Sat, 27 Jun 1998 17:53:07 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id RAA06846; Sat, 27 Jun 1998 17:53:43 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Igor Roshchin cc: freebsd-security@FreeBSD.ORG, igor@alecto.physics.uiuc.edu (Igor Roshchin) Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT In-reply-to: Your message of "Sat, 27 Jun 1998 19:23:54 CDT." <199806280023.TAA04462@alecto.physics.uiuc.edu> Date: Sat, 27 Jun 1998 17:53:43 -0700 Message-ID: <6842.898995223@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've just downloaded "popper" directory from > ftp://ftp.freebsd.org/.25/FreeBSD/FreeBSD-current/ports/mail > It is still missing patch for the "UIDL" problem > (pop_dropcopy.c) Yes, well, I didn't try to fix that one is why. :) I think maybe I'll wait for Peter to come back with his changes since he claims to have fixed a whole _slew_ of potential overflows whereas I've just gone at the problem one overflow at a time. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 18:32:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01992 for freebsd-security-outgoing; Sat, 27 Jun 1998 18:32:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01910; Sat, 27 Jun 1998 18:32:02 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: (from dima@localhost) by burka.rdy.com (8.8.8/RDY&DVV) id SAA15276; Sat, 27 Jun 1998 18:32:00 -0700 (PDT) Message-Id: <199806280132.SAA15276@burka.rdy.com> Subject: is it me or? To: security@FreeBSD.ORG, jkh@FreeBSD.ORG Date: Sat, 27 Jun 1998 18:31:59 -0700 (PDT) X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is it me or patch-ag for popper is broken? I've just compiled popper with the second version of patch-ag (rev1.5) and popper started to segfault in the very begining. It doesn't even give me +OK QPOP etc etc string. -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 18:34:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02261 for freebsd-security-outgoing; Sat, 27 Jun 1998 18:34:36 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02244; Sat, 27 Jun 1998 18:34:28 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id SAA07151; Sat, 27 Jun 1998 18:35:06 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: dima@best.net cc: security@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: is it me or? In-reply-to: Your message of "Sat, 27 Jun 1998 18:31:59 PDT." <199806280132.SAA15276@burka.rdy.com> Date: Sat, 27 Jun 1998 18:35:05 -0700 Message-ID: <7147.898997705@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmm. I wonder. I will check, but I don't recall doing anything really boneheaded in there. - Jordan > Is it me or patch-ag for popper is broken? > I've just compiled popper with the second version of patch-ag (rev1.5) > and popper started to segfault in the very begining. > It doesn't even give me +OK QPOP etc etc string. > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 21:46:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA25281 for freebsd-security-outgoing; Sat, 27 Jun 1998 21:46:00 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from brooklyn.slack.net (root@brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA25276 for ; Sat, 27 Jun 1998 21:45:58 -0700 (PDT) (envelope-from pfm@brooklyn.slack.net) Received: from localhost (pfm@localhost) by brooklyn.slack.net (8.8.7/8.8.7) with SMTP id AAA16067; Sun, 28 Jun 1998 00:48:52 -0400 (EDT) Date: Sun, 28 Jun 1998 00:48:52 -0400 (EDT) From: Patrick McAndrew To: jtb cc: Wojciech Sobczuk , fpscha@schapachnik.com.ar, Niall Smart , ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 27 Jun 1998, jtb wrote: > What do you mean, checking for this is very easy, just before something > gets executed, you take argv and envp and loop through them looking for > those certain ascii characters, it's like 10-15 lines of code, if that. I > don't see why you'd think that would be cumbersome to the kernel. I thought you were talking about userland programs. However, this could make it hardware dependant (as control codes can change between archs), and if this routine is called several hundred times a second (ona busy system), it could slow things down a bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 21:56:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26352 for freebsd-security-outgoing; Sat, 27 Jun 1998 21:56:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bock.nettek-llc.com (d01a8866.dip.cdsnet.net [208.26.136.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26347; Sat, 27 Jun 1998 21:56:49 -0700 (PDT) (envelope-from stevel@mail.cdsnet.net) Received: from mail.cdsnet.net (localhost.nettek-llc.com [127.0.0.1]) by bock.nettek-llc.com (8.8.8/8.8.8) with ESMTP id VAA08284; Sat, 27 Jun 1998 21:56:42 -0700 (PDT) (envelope-from stevel@mail.cdsnet.net) Message-ID: <3595CD09.EF68CBB1@mail.cdsnet.net> Date: Sat, 27 Jun 1998 21:56:42 -0700 From: Steve Logue Organization: http://www.nettek-llc.com/ X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: dima@best.net, security@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: is it me or? References: <7147.898997705@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard wrote: > Hmmm. I wonder. I will check, but I don't recall doing anything > really boneheaded in there. > > - Jordan > > > Is it me or patch-ag for popper is broken? > > I've just compiled popper with the second version of patch-ag (rev1.5) > > and popper started to segfault in the very begining. > > It doesn't even give me +OK QPOP etc etc string. > > > > -- dima > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message Yep it is now exiting on signal 11 for me where previously it was working fine... -STEVEl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 22:29:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29868 for freebsd-security-outgoing; Sat, 27 Jun 1998 22:29:31 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29863 for ; Sat, 27 Jun 1998 22:29:25 -0700 (PDT) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.7/8.8.7) with SMTP id RAA01498; Sun, 28 Jun 1998 17:26:30 +1200 (NZST) (envelope-from andrew@squiz.co.nz) X-Authentication-Warning: aniwa.sky: andrew owned process doing -bs Date: Sun, 28 Jun 1998 17:26:30 +1200 (NZST) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Niall Smart cc: Patrick McAndrew , jtb , Wojciech Sobczuk , fpscha@schapachnik.com.ar, ncb05@uow.edu.au, security@FreeBSD.ORG Subject: Re: non-executable stack? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 27 Jun 1998, Niall Smart wrote: > You misunderstand. My proposal, seemingly seconded by jtb, was to > allow the administrator to disallow the presence of non-printable ascii > characters in the environment or command line arguments at the time of > execve of certain processes. We still don't know if this will have any > effect on security though, since no-one has checked to see if its possible > to write shellcode using just printable ASCII. It would certainly > make life difficult for the attacker, since it would be impossible to > overwrite the saved eip with an address on the stack since the stack > is at the top of the address space around 0xFFxxxxxx or 0xEFxxxxxx. > > Niall I know next to nothing about assembly level programming, but if you mean that there is a problem because 0xFF and 0xEF are out of bounds, then I figure this means very little if the attacker has access to a small range of arithmetic or bitwise operators to generate these characters. With a little more effort, byte values could perhaps be borrowed from elsewhere, copying them from addressable locations. Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 22:31:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00255 for freebsd-security-outgoing; Sat, 27 Jun 1998 22:31:17 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from infowest.com (infowest.com [204.17.177.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00244 for ; Sat, 27 Jun 1998 22:31:15 -0700 (PDT) (envelope-from agifford@infowest.com) Received: from infowest.com (liberty.infowest.com [207.49.60.254]) by infowest.com (8.8.8/8.8.8) with ESMTP id XAA27161 for ; Sat, 27 Jun 1998 23:30:43 -0600 (MDT) Message-ID: <3595D4F7.DDCF4E0E@infowest.com> Date: Sat, 27 Jun 1998 23:30:31 -0600 From: "Aaron D. Gifford" X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: popper popper and more popper (Included is a FIX to the not-working popper) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I don't know this message really should go, but I have an additional bug fix for qpopper (at the bottom of this message), a suggested cosmetic change (the first part of this message), and an optional patch (middle of this message) for qpopper. ===== FIRST ===== The purely cosmetic change first... In the file pop_auth.c the line: return (pop_msg(p,POP_FAILURE,"This command is not supported yet")); functions perfectly, but my log files keep getting messages like: Jun 27 21:52:52 blah popper[22348]: @dialport05.xyzisp.org: -ERR This command is not supported yet Before I groked the popper source code, I had NO CLUE what this meant. After changing the above line of code thus: return (pop_msg(p,POP_FAILURE,"The auth command is not supported yet")); my log files are completely comprehensible without having to look at the popper source code. ===== SECOND ===== Now for the second change, the optional patch. Take it with a grain of salt. I personally like it and think it improves the security and handling of untrusted data from the POP client. It MIGHT violate the POP3 RFC even though it does not break any of the POP clients I've tested (Eudora, Netscape mail, and MS Internet Mail). In looking at the recent buffer overflows, I noticed that popper.h had an interesting define: #define MAXPARMLEN 10 Yet if you grep for MAXPARMLEN, it ONLY shows up in the header file. I highly suspect that the qpopper author(s) intended to limit POP commands and parameters to this length but never implemented it. Here's a quick patch that implements this feature. Had it been implemented in the first place, the recent buffer exploits would have been more difficult or perhaps even impossible. It may be that such an implementation may violate an RFC (I haven't read the POP3 definition). I don't know. Perhaps you might only include the patch as an additonal optional patch with a brief note in the README for those who want to add this functionality. I have been running the patch below on a moderate volume 6,000 user system without any trouble. Here it is: diff -p popper.h popper.new.h *** popper.h Sat Jun 27 22:46:59 1998 --- popper.new.h Sat Jun 27 22:47:09 1998 *************** *** 59,65 **** #define MAXMSGLINELEN MAXLINELEN #define MAXCMDLEN 4 #define MAXPARMCOUNT 5 ! #define MAXPARMLEN 10 #define ALLOC_MSGS 20 #ifndef OSF1 --- 59,65 ---- #define MAXMSGLINELEN MAXLINELEN #define MAXCMDLEN 4 #define MAXPARMCOUNT 5 ! #define MAXPARMLEN 16 #define ALLOC_MSGS 20 #ifndef OSF1 diff -p pop_parse.c pop_parse.new.c *** pop_parse.c Wed Nov 19 14:20:38 1997 --- pop_parse.new.c Sat Jun 27 22:58:17 1998 *************** char * buf; /* Pointer *** 26,31 **** --- 26,32 ---- { char * mp; register int i; + register int parmlen; /* Loop through the POP command array */ for (mp = buf, i = 0; ; i++) { *************** char * buf; /* Pointer *** 45,52 **** /* Point to the start of the token */ p->pop_parm[i] = mp; /* Search for the first space character (end of the token) */ ! while (!isspace(*mp) && *mp) mp++; /* Delimit the token with a null */ if (*mp) *mp++ = 0; --- 46,75 ---- /* Point to the start of the token */ p->pop_parm[i] = mp; + /* Start counting the length of this token */ + parmlen = 0; + /* Search for the first space character (end of the token) */ ! while (!isspace(*mp) && *mp) { ! mp++; ! parmlen++; ! if (parmlen > MAXPARMLEN) { ! /* Truncate parameter to the max. allowable size */ ! *mp = '\0'; ! ! /* Fail with an appropriate message */ ! if (i == 0) { ! pop_msg(p,POP_FAILURE, ! "Command \"%s\" (truncated) exceedes maximum permitted size.", ! p->pop_command); ! } else { ! pop_msg(p,POP_FAILURE, ! "Argument %d \"%s\" (truncated) exceeds maximum permitted size.", ! i, p->pop_parm[i]); ! } ! return(-1); ! } ! } /* Delimit the token with a null */ if (*mp) *mp++ = 0; ===== LAST the BUG FIX (Two parts) ===== Last of all, I have a few problems with patch-ag. First, in a patched pop_msg.c, beginning at line 92: /* Append the */ len -= strlen(message); (void)strncat(message, len, "\r\n"); Before the above assignment: len == sizeof(message) - strlen(stat == POP_SUCCESS ? POP_OK : POP_ERR) After the assignment: len == sizeof(message) - strlen(stat == POP_SUCCESS ? POP_OK : POP_ERR) - strlen(message) That means that if: stat == POP_SUCCESS strlen(POP_OK) == 5 sizeof(message) == 1024 assume that vsnprintf(mp,len,format,ap) appends a VERY LARGE string with a strlen of 1018 to message Then the before and after would be: BEFORE: len == 1019 (or 1024 - 5) AFTER: len == -4 (or 1019 - 1023) The strlen(stat == POP_SUCCESS ? POP_OK : POP_ERR) essentially gets subtracted twice by the code, once above the v/snprintf()'s and again afterward. I believe the code should instead read beginning at line 92: /* Append the */ len -= strlen(mp); (void)strncat(message, "\r\n", len); There is also the possibility that the strncat() will fail to append the "\r\n" in extremem cases because there's not enough buffer length left. I believe this should not be allowed to happen. **** BIG NOTE **** The problems reported today about popper not working after Jordan's patches occur because the new call to strncat() mistakenly transposes the "\r\n" and len parameters. The correct parameter order is as I show in my above code. This fixes this problem and lets popper work normally. **** END NOTE **** The pop_msg.c code at line 62 as currently patched reads: /* Point past the POP status indicator in the message message */ l = strlen(mp); len -= l, mp += l; I would instead do: /* Point past the POP status indicator in the message message */ l = strlen(mp); mp += l; /* * Subtract an additional 2 from the remaining buffer length * so that after the vsnprintf()/snprintf() calls there will * still be enough buffer space to append a "\r\n" even in a * worst-case scenario. */ len -= l - 2; Why? By pre-removing 2 chars from the buffer maximum limit, there should always be room left for the "\r\n" appended later on. I believe this would be the "right" thing to do. It guarantees that the POP client will always be sent the expected "\r\n" sequence even in abnormal cases. On a mostly unrelated note, many many kudos and thanks to the entire FreeBSD core team and to all contributors! I use FreeBSD as the core OS for InfoWest, a local ISP I work for and it is ROCK SOLID! I also run it at home and now RARELY ever boot to Windows. Sincerely, Aaron Gifford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Jun 27 23:33:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA07138 for freebsd-security-outgoing; Sat, 27 Jun 1998 23:33:48 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA07127 for ; Sat, 27 Jun 1998 23:33:45 -0700 (PDT) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with SMTP id CAA14927 for ; Sun, 28 Jun 1998 02:35:52 -0400 (EDT) Date: Sun, 28 Jun 1998 02:35:52 -0400 (EDT) From: Mike To: security@FreeBSD.ORG Subject: Re: popper popper and more popper (Included is a FIX to the not-working popper) In-Reply-To: <3595D4F7.DDCF4E0E@infowest.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Great! Are these going to be added to the popper port? If so I'll just wait until they are and pull down the newest ports collection tomorrow. On Sat, 27 Jun 1998, Aaron D. Gifford wrote: [snip] > Here it is: > > diff -p popper.h popper.new.h > *** popper.h Sat Jun 27 22:46:59 1998 > --- popper.new.h Sat Jun 27 22:47:09 1998 > *************** > *** 59,65 **** [snip] -mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message