From owner-freebsd-security Sun Feb 25 10:21:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10142 for security-outgoing; Sun, 25 Feb 1996 10:21:28 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA10135 for ; Sun, 25 Feb 1996 10:21:25 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA15742; Sun, 25 Feb 1996 13:21:16 -0500 Date: Sun, 25 Feb 1996 13:21:16 -0500 From: "Garrett A. Wollman" Message-Id: <9602251821.AA15742@halloran-eldar.lcs.mit.edu> To: Warner Losh Cc: freebsd-security@FreeBSD.ORG Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) In-Reply-To: <199602240437.VAA14882@rover.village.org> References: <199602240437.VAA14882@rover.village.org> Sender: owner-security@FreeBSD.ORG Precedence: bulk < said: > You'd not have these services :-) Usually the daytime service can be > moderately useful, since it doesn't suffer from the bombing problems > (sure, you can get it to generate a packet, but it will be only > one). However, it is trivial to get the daytime service to ping-pong with the echo service. Same thing for the chargen service (don't know what purpose that serves...) > UDP is, at present, the only thing impacted. It only takes one rogue > packet to set them jabbering at each other (which is one reason we > don't allow any IP packets with "src" of one of our netblock through > our firewall). Of course, that doesn't help you if the forged source is on someone else's network... > I don't see how a TCP attack could succeed given the > three way handshake that is required by TCP to establish a connection. Guess the Initial Sequence Number. On old BSD systems, this was almost trivial. On modern BSD systems, this is much more difficult. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Sun Feb 25 10:48:59 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11498 for security-outgoing; Sun, 25 Feb 1996 10:48:59 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA11487 for ; Sun, 25 Feb 1996 10:48:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id LAA18341; Sun, 25 Feb 1996 11:48:33 -0700 Message-Id: <199602251848.LAA18341@rover.village.org> To: "Garrett A. Wollman" Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of Sun, 25 Feb 1996 13:21:16 EST Date: Sun, 25 Feb 1996 11:48:33 -0700 From: Warner Losh Sender: owner-security@FreeBSD.ORG Precedence: bulk : However, it is trivial to get the daytime service to ping-pong with : the echo service. Same thing for the chargen service (don't know what : purpose that serves...) True, I'd forgotten that part. Chargen is for network testing. The original theory was to see if the UDP/TCP implementations are working. It is a good thing for that, but not good enough for this latest attack. : > UDP is, at present, the only thing impacted. It only takes one rogue : > packet to set them jabbering at each other (which is one reason we : > don't allow any IP packets with "src" of one of our netblock through : > our firewall). : : Of course, that doesn't help you if the forged source is on someone : else's network... That's why we also filter almost all inbound UDP messages as well :-) I think we let in DNS packets, and that is about it. : > I don't see how a TCP attack could succeed given the : > three way handshake that is required by TCP to establish a connection. : : Guess the Initial Sequence Number. On old BSD systems, this was : almost trivial. On modern BSD systems, this is much more difficult. I know that's how you make machine A think machine B is talking to it, but how do you do both sides such that connections will be established? The initial three way handshake is assymetric. Warner From owner-freebsd-security Sun Feb 25 13:21:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20434 for security-outgoing; Sun, 25 Feb 1996 13:21:33 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA20410 for ; Sun, 25 Feb 1996 13:21:08 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id NAA08497; Sun, 25 Feb 1996 13:19:18 -0800 (PST) Date: Sun, 25 Feb 1996 13:19:18 -0800 (PST) From: invalid opcode To: Brian Tao cc: FREEBSD-SECURITY-L Subject: Re: Suspicious symlinks in /tmp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Sat, 24 Feb 1996, Brian Tao wrote: > lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.19573 -> /tmp/passwd-dir.19573 > lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.20196 -> /tmp/passwd-dir.20196 > lrwxrwxrwt 1 bin user 21 Feb 24 17:04 passwd-link.20543 -> /tmp/passwd-dir.20543 > > Brian Tao (BT300, taob@io.org) Looks like someone is trying to exploit a race condition in order to grab the password file. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-security Sun Feb 25 13:24:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20849 for security-outgoing; Sun, 25 Feb 1996 13:24:54 -0800 (PST) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA20843 for ; Sun, 25 Feb 1996 13:24:51 -0800 (PST) Received: from Ken (tsunami.awod.com [198.81.225.31]) by sumter.awod.com (8.6.11/8.6.9) with SMTP id QAA11561 for ; Sun, 25 Feb 1996 16:24:44 -0500 Message-Id: <1.5.4b11.32.19960225212632.00a341e0@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Feb 1996 16:26:32 -0500 To: freebsd-security@FreeBSD.org From: Ken Lam Subject: Kerberos 4 Slave Server Setup in 2.1 Sender: owner-security@FreeBSD.org Precedence: bulk I am trying to setup a slave server in 2.1. Both master and slave are 2.1. I have scrounged up all the docs from the web that I could find on doing it including some stuff from indiana.edu and cygnus.com(CNS). I have tried a few likely configurations with no luck and was wondering if there was someone out there in BSD-land who could give me a hand. Thanks, Ken From owner-freebsd-security Sun Feb 25 13:25:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20890 for security-outgoing; Sun, 25 Feb 1996 13:25:18 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA20782 for ; Sun, 25 Feb 1996 13:24:10 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id NAA08525 for ; Sun, 25 Feb 1996 13:23:39 -0800 (PST) Date: Sun, 25 Feb 1996 13:23:39 -0800 (PST) From: invalid opcode To: freebsd-security@freebsd.org Subject: BoS: internic-gen-1.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk Heh, looks like InterNIC is finally solving this problem. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == ---------- Forwarded message ---------- Date: Mon, 26 Feb 1996 03:43:28 +1100 From: Julian Assange To: best-of-security@suburbia.net Subject: BoS: internic-gen-1.txt [ URL ftp://rs.internic.net/policy/internic/internic-gen-1.txt ] [ 2/96 ] Jasdip Singh Network Solutions Mark Kosters Network Solutions The InterNIC Guardian Object DRAFT Table of Contents 1. Introduction....................................................... 1 2. Main Features of a Guardian........................................ 1 3. Guardian Attributes................................................ 1 4. Registering the Guardian Attributes................................ 4 4.1. Using the New Contact Template................................... 5 4.2. Using the Modified Registration Templates........................ 5 5. Linking Guardian Information to Existing Records................... 5 6. Notification....................................................... 6 7. Object Update Rules................................................ 6 7.1. Request from a Contact with Authentication Information........... 7 7.2. Request from a Contact without Authentication Information........ 7 7.3. Request from a Sender not listed as a Contact.................... 7 8. Object Use Rules................................................... 8 8.1. Request from a Contact........................................... 8 8.2. Request from a Sender not listed as a Contact.................... 8 9. Other Guardian Issues.............................................. 8 9.1. Number of Guardians per Object................................... 8 9.2. Protecting Guardian Information.................................. 9 9.3. Displaying Guardian Information.................................. 9 10. Conclusion........................................................ 9 11. References........................................................ 9 12. Acknowledgements.................................................. 9 A. The Proposed Contact Template...................................... 10 B. The Proposed Link Template......................................... 12 C. The Proposed Notify Template....................................... 14 D. Object Update Rules................................................ 15 E. Object Use Rules................................................... 16 F. Examples........................................................... 17 F.1. How to Register a New Contact with Authentication Information.... 17 F.2. How to Link Guardian Information to Existing Records............. 18 F.3. How to Update a Guarded Record................................... 19 F.4. WHOIS Display of Guardian Information............................ 20 [Page i] 1. Introduction This document proposes a model to authorize changes made to the Objects (Domains, Networks, Autonomous System Numbers, and Hosts) registered with the InterNIC. The registration activity at the InterNIC has increased exponentially with the rapid growth of the Internet. In the absence of a formal authorization model, the likelihood of making malicious changes to the registered Objects has also increased and could have serious consequences at the affected sites. For example, an unauthorized update could lead a commercial organization to lose its presence on the Internet until that update is reversed. 2. Main Features of a Guardian - A Guardian is an Object that protects other Objects from unauthorized changes. It is basically a Contact with Authentication Information. - The different authorization schemes to authenticate a Guardian are MAIL-FROM, CRYPT-PW, and PGP. - The use of a Guardian is OPTIONAL. - An Object may be guarded by multiple Guardians with each Guardian having an equal authority to make changes to the Object. 3. Guardian Attributes Currently, the InterNIC allows a registered Object to be updated if the request came from one of its Contacts. This model is weak due to potential mail spoofing. To allow for stronger authorization schemes, the proposed authorization model defines a new Object called Guardian. A Guardian is basically a Contact with Authentication Information. It inherits the attributes of a Contact Object and has the additional authentication attributes. The definition of a Guardian is derived from a Contact because a particular Contact (Administrative, Technical, or Billing) represents some form of holding of a registered Object and the holder of an Object is most likely to guard it also. [Page 1] The attributes of a Guardian are: Name REQUIRED Type REQUIRED Address REQUIRED Phone REQUIRED Fax OPTIONAL Email REQUIRED Notify Update OPTIONAL Notify Use OPTIONAL Auth Scheme REQUIRED * Auth Info REQUIRED * Public OPTIONAL * The Auth Scheme and Auth Info attributes are REQUIRED only for a Guardian Object (a Contact with Authentication Information) and not for a Contact Object (a Contact without Authentication Information). Name, Type, Address, Phone, Fax, Email, Notify Update, and Notify Use are the attributes a Guardian inherits from a Contact Object. Auth Scheme, Auth Info, and Public are the additional authentication attributes of a Guardian. Name Name of a Guardian. Type Type of a Guardian. It can have values I (Individual) or R (Role Account). Address Postal address of a Guardian. Phone Phone number of a Guardian. Fax Fax number of a Guardian. Email Email address of a Guardian. [Page 2] Notify Update This attribute determines if and when a Guardian should be notified about the update of an Object the Guardian is responsible for. It can have values BEFORE-UPDATE, AFTER-UPDATE, and NOT-CARE. BEFORE-UPDATE The Guardian will be notified before updating the Object. AFTER-UPDATE The Guardian will be notified after updating the Object. AFTER-UPDATE is the DEFAULT value. NOT-CARE The Guardian will not be notified about the Object update because it does not want to be notified. Currently, a Guardian's Notify Update attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Notify Use This attribute determines if and when a Guardian should be notified about the use of an Object the Guardian is responsible for. For example, a Guardian of a Host may be notified when someone else lists it as a Domain Name System (DNS) server for a Domain. It can have values BEFORE-USE, AFTER-USE, and NOT-CARE. BEFORE-USE The Guardian will be notified before using the Object. AFTER-USE The Guardian will be notified after using the Object. AFTER-USE is the DEFAULT value. NOT-CARE The Guardian will not be notified about the Object use because it does not want to be notified. Currently, a Guardian's Notify Use attribute will be the same for all the Objects the Guardian is responsible for. In future, it will be defined on a per Object basis for each of the Objects a Guardian is guarding. Auth Scheme Authorization scheme used to authenticate a Guardian before updating the Object it is guarding. The proposed schemes in an increasing order of strength are MAIL-FROM, CRYPT-PW, and PGP [1]. MAIL-FROM MAIL-FROM will parse the FROM: field in the mail header of an update message and match it with the email address of the Guardian guarding the Object to be updated. MAIL-FROM is the DEFAULT Auth Scheme. [Page 3] CRYPT-PW CRYPT-PW will encrypt the cleartext password supplied in an update message and match it with the encrypted password of the Guardian guarding the Object to be updated. Initially when a new Guardian is being registered or the authentication information is being added to an existing Contact, the encrypted password MUST be supplied. The Unix crypt(3) routine SHOULD be used to encrypt a cleartext password. PGP PGP stands for Pretty Good Privacy [2]. The sender will sign the update message with a Guardian's secret PGP key. The InterNIC will verify the received update message with the Guardian's public PGP key. How to register a Guardian's public PGP key with the InterNIC will be explained in another document. Auth Info Information for the selected authorization scheme. The authentication information stored in the database for a Guardian registered with the InterNIC is: MAIL-FROM Email address of a Guardian. CRYPT-PW Encrypted password of a Guardian. PGP Key ID of the public PGP key of a Guardian. Public Boolean indicating whether the authentication information for a Guardian will be public or not. Public means visible in WHOIS. It can have values Y (Yes) or N (No). The DEFAULT value is Y. Note that the terms "Guardian" and "Contact with Authentication Information" are used interchangeably in the remaining document. 4. Registering the Guardian Attributes There will be two alternatives available to register or update the Guardian attributes: - Using the new Contact Template, or - Using the registration templates for Domains, Networks, Autonomous System Numbers (ASN's), and Hosts modified to include the authentication information for the Contacts. Note that registering a PGP-authenticated Guardian will be a two-step process because the Guardian will first have to register its public PGP key with the InterNIC and then report the key ID as Auth Info using one of the above methods. [Page 4] 4.1. Using the New Contact Template A new Contact Template is proposed to independently register or update a Contact with Authentication Information. Appendix A describes the new Contact Template and its use. 4.2. Using the Modified Registration Templates The registration templates for Domains, Networks, ASN's, and Hosts will be modified to include: a) The Authentication Information for the Contacts. b) The Authorization Section in the beginning of the template to authenticate the Guardian updating the Object. It SHOULD be filled only when the Object is being modified or deleted, and if the Object is being guarded. It has the following items: Auth Scheme Authorization scheme used to authenticate the Guardian updating the Object. It can have values MAIL-FROM, CRYPT-PW, or PGP. Auth Info Information for the selected authorization scheme. The different Auth Scheme and Auth Info combinations are: Auth Scheme Auth Info MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Object and send it in cleartext to the InterNIC. 5. Linking Guardian Information to Existing Records There are two ways to link Guardian information to existing records: a) Once the authentication information is added to an existing Contact, all the database records the Contact is responsible for will be automatically guarded by that Contact and any subsequent update request from that Contact for one of those records will be first authenticated. This approach should be used carefully because here a Contact guards either all or none of its Objects. [Page 5] b) A new Link Template is proposed to do a wholesale linkage of Contacts with Authentication Information (Guardian Objects) to database records (Guarded Objects) in a single transaction. This approach is more flexible because the records that need to be guarded by a particular set of Guardians are listed explicitly in the Link Template. Appendix B describes the new Link Template and its use. 6. Notification The rules to update or use an Object will depend on when its Contacts are notified. There are two types of notification: Active Notification If the Notify Update attribute for a Contact of an Object is set to BEFORE-UPDATE, the Contact will be notified before updating the Object and the request will only be processed if an ACK (Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to BEFORE-USE, the Contact will be notified before using the Object and the request will only be processed if an ACK is received. Passive Notification If the Notify Update attribute for a Contact of an Object is set to AFTER-UPDATE, the Contact will be notified after the Object has been updated and the processed request will be revoked if a NAK (Negative Acknowledgement) is received. If the Notify Use attribute for a Contact of an Object is set to AFTER-USE, the Contact will be notified after the Object has been used and the processed request will be revoked if a NAK is received. An ACK or a NAK MUST be received within a certain time interval to be effective. Clearly, Active Notification is safer than Passive Notification. Appendix C describes the new Notify Template and its use. 7. Object Update Rules A request to update an Object could possibly come from a Contact with Authentication Information, a Contact without Authentication Information or a sender not listed as a Contact for the Object. [Page 6] The Object Update Rules for such requests are: 7.1. Request from a Contact with Authentication Information The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE. 7.2. Request from a Contact without Authentication Information 7.2.1. Object has at least one Contact with Authentication Information All the Contacts with Authentication Information will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2. Object has no Contacts with Authentication Information 7.2.2.1. Object has at least one of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE All the other Contacts with Notify Update attribute set to BEFORE-UPDATE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 7.2.2.2. Object has none of the other Contacts with Notify Update Attribute set to BEFORE-UPDATE The request will be processed immediately with notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE. The Contacts with Notify Update attribute set to NOT-CARE will not be notified. 7.3. Request from a Sender not listed as a Contact All the Contacts will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. If the request from a sender not listed as a Contact is rejected, the sender MUST present an evidence that the Object holder has approved it to update the Object. Another request from the same sender must be faxed to the InterNIC on the corporate letterhead and must contain the tracking number of the initial request. The sender could also fax a copy of its contract with the Object holder. Appendix D gives a summary of the Object Update Rules. [Page 7] 8. Object Use Rules One of the more common registration problems at the InterNIC is a Domain holder using without permission someone else's DNS servers or someone else's IP addresses to number its DNS servers. The Object Use Rules will help prevent such illegal use of Objects, particularly Hosts and Networks. A request to use an Object could possibly come from one of its Contacts or a sender not listed as a Contact for the Object. The Object Use Rules for such requests are: 8.1. Request from a Contact The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE. 8.2. Request from a Sender not listed as a Contact 8.2.1. Object to be used has at least one Contact with Notify Use Attribute set to BEFORE-USE All the Contacts with Notify Use attribute set to BEFORE-USE will be notified before processing the request. If the InterNIC receives an ACK first before the waiting time indicated on the Notify Template expires, the request will be processed. Otherwise, the request will NOT be processed. 8.2.2. Object to be used has no Contact with Notify Use Attribute set to BEFORE-USE The request will be processed immediately with notification to all the Contacts with Notify Use attribute set to AFTER-USE. The Contacts with Notify Use attribute set to NOT-CARE will not be notified. Appendix E gives a summary of the Object Use Rules. 9. Other Guardian Issues 9.1. Number of Guardians per Object The number of Guardians for an Object will be equal to the number of its Contacts with Authentication Information. Each Guardian will have an equal authority to make changes to the Object. In future, multiple Contacts of the same type (for example, Technical) will be allowed for an Object. This will facilitate multiple Guardians of the same type for an Object. If an Object has no Contacts with Authentication Information, it will not be guarded at all. [Page 8] 9.2. Protecting Guardian Information By DEFAULT, a Guardian will guard itself (that is, only the Guardian will have the authority to make changes to its information). However, a Guardian can be guarded by another Guardian. If a Guardian is guarding itself and needs to update its authentication information or scheme, the update message MUST contain the Guardian's old authentication information. Otherwise, the Guardian can not be authenticated before the update. For example, if a Guardian's Auth Scheme is MAIL-FROM, and it needs to either update its email address or change its Auth Scheme, the update message must come from its old email address. 9.3. Displaying Guardian Information The authentication information for a Guardian will be visible in WHOIS unless the Guardian chooses to keep it private by setting its Public attribute to N. This information will be public by DEFAULT because a Guarded Object should be protected by the inherent strength of the selected authorization scheme rather than by hiding the authorization information for its Guardian. The WHOIS display of a Guarded Object will be extended to indicate that the Object is being guarded. 10. Conclusion The increased market value of the Objects registered with the InterNIC, particularly Domains and Networks, has necessitated the need for more secure database transactions. This Guardian proposal will help solve most of the current, unauthorized Object update and use problems at the InterNIC. It balances operational expediency with stronger authorization by allowing the Contacts of an Object to select the appropriate level of security (MAIL-FROM, CRYPT-PW, or PGP) for the Object. 11. References [1] Karrenberg, D., Terpstra, M., "Authorisation and Notification of Changes in the RIPE Database", ripe-120, RIPE NCC, RIPE NCC. [2] Garfinkel, S., "PGP Pretty Good Privacy", O'Reilly & Associates, Inc. 12. Acknowledgements The authors thank the InterNIC staff for some very useful suggestions, especially Eric Eden, Tom Newell, Kim Hubbard, Duane Stone, and Carley Johnson. [Page 9] A. The Proposed Contact Template [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: Contact Information 2a. NIC Handle..............: 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: The Contact Template will be used to independently register or update a Contact (with or without Authentication Information). Items 0a-0b SHOULD be filled only when a Contact is being modified or deleted, and if the Contact is being guarded. These items contain the information to authenticate the Guardian updating the Contact. Item 0a is the authorization scheme for that Guardian. It can have values MAIL-FROM, CRYPT-PW, or PGP. Item 0b is the information for the selected authorization scheme. [Page 10] The different items 0a and 0b combinations are: Item 0a Item 0b MAIL-FROM Ignored. The FROM: field in the mail header of an update message will be parsed to verify the Guardian. CRYPT-PW Cleartext password. PGP Ignored. The sender SHOULD sign the entire update message with the secret PGP key of the Guardian updating the Contact and send it in cleartext to the InterNIC. Item 1 is the registration action type. It can have values N, M, or D. N registers a new Contact. M modifies the information for an existing Contact. D deletes an existing Contact if it is no longer linked to any Object. Items 2a-2k contain the basic information for a Contact. Item 2a is the NIC handle assigned to a Contact. Items 2b, 2c, 2d-2h, 2i, 2j, and 2k are respectively the Name, Type, Address, Phone, Fax, and Email attributes of a Contact. Items 3a-3b contain the notification information for a Contact. Items 3a and 3b are respectively the Notify Update and Notify Use attributes of a Contact. Items 4a-4c contain the authentication information for a Contact. These items are OPTIONAL, and are REQUIRED only if either the authentication information is being added to an existing Contact or a new Contact with Authentication Information is being registered. Items 4a, 4b, and 4c are respectively the Auth Scheme, Auth Info, and Public attributes of a Guardian. [Page 11] B. The Proposed Link Template [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: Object 1a. Identifier..............: 1b. Type....................: 1c. Function................: Linked Object 2a. Identifier..............: 2b. Type....................: The Link Template will be used to do wholesale database changes in a single transaction. Some of the more commonly requested database changes are: a) Link or unlink Contacts (with or without Authentication Information) to or from existing Domains, Networks, ASN's, and Hosts. b) Link or unlink DNS servers to or from existing Domains and Networks. Item 0 is the registration action type. It can have values N, M, or D. N links the Objects (Contacts or DNS servers) in the Object Sections to the Objects (Domains, Networks, ASN's, and Hosts) in the Linked Object Sections. M modifies the linkage. D unlinks the Objects in the Object Sections from the Objects in the Linked Object Sections. Items 1a-1c contain information for an Object (Contact or DNS server) in the Object Section. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is OPTIONAL and is REQUIRED only if the Object is a Contact. It is the Function Type of a Contact. It can have values AC (Administrative Contact), TC (Technical Contact), or BC (Billing Contact). The Object Section SHOULD be copied for each Object (Contact or DNS server). Items 2a-2b contain information for an Object (Domain, Network, ASN, or Host) in the Linked Object Section. Item 2a is the Identifier of the Object. Item 2b is the Type of the Object. The Linked Object Section SHOULD be copied for each Object (Domain, Network, ASN, or Host). [Page 12] The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 13] C. The Proposed Notify Template [ URL ftp://rs.internic.net/templates/notify-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Notify Version Number: 1.0 ************** Please see attached detailed instructions ************** 0a. (A)ck (N)ak.....: 0b. Comments........: Object 1a. Identifier......: 1b. Type............: 1c. Tracking Number.: 1d. Message ID......: The Notify Template will be used to notify a Contact of an Object before or after updating or using the Object, and get its approval. The InterNIC will fill in the information for the requested Object update or use in the template (Items 1a-1d), append the request, and send it to a Contact of the Object for approval. The Contact will, in turn, fill in the ACK/NAK response in the template (Items 0a-0b) and send it back to the InterNIC. If no ACK or NAK is received within 4 days for an Object update request or 2 days for an Object use request, the InterNIC may assume an implicit ACK or NAK depending on the type of request. Items 0a-0b contain the response from a Contact. Item 0a is the ACK/NAK response. It can have values A (Ack) or N (Nak). Item 0b contains the comments from the Contact on the approval or disapproval of the request. Items 1a-1d contain information for the requested Object update or use. Item 1a is the Identifier of the Object. Item 1b is the Type of the Object. Item 1c is the Tracking Number of the request. Item 1d is the Message ID of the request. Items 1c and 1d will help locate the request. The different Identifiers and Types of the Objects are: Object Identifier Type Domain NIC Handle/Domain Name D Network NIC Handle/Network Name N ASN NIC Handle/AS Name A Host NIC Handle/Host Name H Contact NIC Handle I/R [Page 14] D. Object Update Rules IF Request from a Contact with Authentication Information Passive Notification to all the Contacts with Notify Update attribute set to BEFORE-UPDATE or AFTER-UPDATE after updating the Object ELSE IF Request from a Contact without Authentication Information IF Object has at least one Contact with Authentication Information Active Notification to these Contacts before updating the Object ELSE IF Object has at least one of the other Contacts with Notify Update attribute set to BEFORE-UPDATE Active Notification to these Contacts before updating the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-UPDATE after updating the Object ENDIF ENDIF ELSE IF Request from a Sender not listed as a Contact Notification to all the Contacts before updating the Object IF the InterNIC receives an ACK Object updated ELSE IF the Sender faxes the request on the corporate letterhead Object updated ELSE IF the Sender faxes a copy of its contract with the Object Holder Object updated ELSE Object not updated ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 4 days Object updated ELSE Object not updated ENDIF Passive Notification: IF the InterNIC receives a NAK first within 4 days Object update revoked ELSE OK ENDIF [Page 15] E. Object Use Rules IF Request from a Contact Passive Notification to all the Contacts with Notify Use attribute set to BEFORE-USE or AFTER-USE after using the Object ELSE IF Request from a Sender not listed as a Contact IF Object has at least one Contact with Notify Use attribute set to BEFORE-USE Active Notification to these Contacts before using the Object ELSE Passive Notification to all the Contacts with Notify Update attribute set to AFTER-USE after using the Object ENDIF ENDIF Active Notification: IF the InterNIC receives an ACK first within 2 days Object used ELSE Object not used ENDIF Passive Notification: IF the InterNIC receives a NAK first within 2 days Object use revoked ELSE OK ENDIF [Page 16] F. Examples F.1. How to Register a New Contact with Authentication Information [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: 0b. Auth Info...............: 1. (N)ew (M)odify (D)elete.: N Contact Information 2a. NIC Handle..............: 2b. Name....................: Xary Y. Zmith 2c. (I)ndividual (R)ole.....: I 2d. Street Address..........: Fictitious Street 2e. City....................: Imaginary 2f. State...................: VA 2g. Postal Code.............: 22079 2h. Country Code............: US 2i. Phone Number............: 1-703-999-8484 2j. Fax Number..............: 1-703-999-8485 2k. E-Mailbox...............: xyz@internic.net Notify Information 3a. Notify Update...........: BEFORE-UPDATE 3b. Notify Use..............: AFTER-USE Authentication Information 4a. Auth Scheme.............: CRYPT-PW 4b. Auth Info...............: %.d!Hr3@rm.Gh 4c. Public (Y/N)............: Y Here, a new Contact Xary Y. Zmith is registered with CRYPT-PW as its Auth Scheme. The Contact will be notified before updating or after using an Object it is responsible for. The authentication information for the Contact will be visible in WHOIS. [Page 17] F.2. How to Link Guardian Information to Existing Records [ URL ftp://rs.internic.net/templates/link-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Link Version Number: 1.0 ************** Please see attached detailed instructions ************** 0. (N)ew (M)odify (D)elete.: N Object 1a. Identifier..............: XYZ10000 1b. Type....................: I 1c. Function................: TC Linked Object 2a. Identifier..............: HOST.EXAMPLE.COM 2b. Type....................: H In Example F.1, the new Contact is registered with NIC handle XYZ10000. Here, the Contact XYZ10000 is linked as Technical Contact to the Host HOST.EXAMPLE.COM. [Page 18] F.3. How to Update a Guarded Record [ URL ftp://rs.internic.net/templates/Contact-template.txt ] [ 1/96 ] ***************** Please DO NOT REMOVE Version Number ***************** Contact Version Number: 1.0 ************** Please see attached detailed instructions ************** Authorization 0a. Auth Scheme.............: CRYPT-PW 0b. Auth Info...............: Cleartext Password 1. (N)ew (M)odify (D)elete.: M Contact Information 2a. NIC Handle..............: XYZ10000 2b. Name....................: 2c. (I)ndividual (R)ole.....: 2d. Street Address..........: 2e. City....................: 2f. State...................: 2g. Postal Code.............: 2h. Country Code............: 2i. Phone Number............: 1-703-999-8486 2j. Fax Number..............: 2k. E-Mailbox...............: Notify Information 3a. Notify Update...........: 3b. Notify Use..............: Authentication Information 4a. Auth Scheme.............: 4b. Auth Info...............: 4c. Public (Y/N)............: Here, the authorization information in items 0a-0b is first verified and then the record for the Contact XYZ10000 is updated. [Page 19] F.4. WHOIS Display of Guardian Information Whois: XYZ10000 Zmith, Xary Y. (XYZ10000) xyz@INTERNIC.NET Fictitious Street Imaginary, VA 22079 (703) 999-8486 (703) 999-8485 Auth Scheme: CRYPT-PW %.d!Hr3@rm.Gh Record last updated on 18-Jan-96. Here, the WHOIS display of the Guardian XYZ10000 contains its authentication information because its Public attribute is set to Y. [Page 20] From owner-freebsd-security Sun Feb 25 14:18:54 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA24271 for security-outgoing; Sun, 25 Feb 1996 14:18:54 -0800 (PST) Received: from zygaena.com (zygaena.com [206.148.80.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA24266 for ; Sun, 25 Feb 1996 14:18:48 -0800 (PST) From: ewb@zygaena.com Received: (from nobody@localhost) by zygaena.com (8.7.3/8.7.3) id RAA01373 for ; Sun, 25 Feb 1996 17:18:56 -0500 (EST) X-Authentication-Warning: zygaena.com: nobody set sender to using -f Received: from lochsa.i.com(198.30.169.3) by zygaena.com via smap (V1.3) id sma001371; Sun Feb 25 17:18:50 1996 Received: (from ewb@localhost) by lochsa.i.com (8.7.3/8.7.3) id RAA00532 for freebsd-security@freebsd.org; Sun, 25 Feb 1996 17:18:39 -0500 (EST) Date: Sun, 25 Feb 1996 17:18:39 -0500 (EST) Message-Id: <199602252218.RAA00532@lochsa.i.com> To: freebsd-security@freebsd.org Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) Sender: owner-security@freebsd.org Precedence: bulk >> UDP is, at present, the only thing impacted. It only takes one rogue >> packet to set them jabbering at each other (which is one reason we >> don't allow any IP packets with "src" of one of our netblock through >> our firewall). > >Of course, that doesn't help you if the forged source is on someone >else's network... Depends on whether you have a packet filter or firewall that blocks these "services" - or UDP in general except perhaps for 53. All depends on your stance. Mr. Wollman at MIT has to be concerned since his academic network is probably pretty open. Most ISP's could block these UDP services into (and out of) their local LANS, but a disgruntled user could still cause problems.. But of course the problem is nicely solved within inetd (as has been pointed out I believe): from FreeBSD inetd(8): All of these services are available in both TCP and UDP versions; the UDP versions will refuse service if the request specifies a reply port corresponding to any internal service. (This is done as a defense against looping attacks; If we have Mr. Wollman to thank for this - Bravo! Solaris 2.4 and SunOS 4.1.4 DO NOT have this note in the inetd man pages - and thus I presume they are vulnerable. Don't know about other un*xen. -- Will Brown ewb@zygaena.com Zygaena Network Services http://www.zygaena.com From owner-freebsd-security Sun Feb 25 15:04:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA26494 for security-outgoing; Sun, 25 Feb 1996 15:04:26 -0800 (PST) Received: from anna.az.com (root@anna.az.com [204.57.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA26489 for ; Sun, 25 Feb 1996 15:04:23 -0800 (PST) Received: (from yankee@localhost) by anna.az.com (8.6.12/8.6.12) id PAA02149; Sun, 25 Feb 1996 15:06:38 -0800 Date: Sun, 25 Feb 1996 15:06:37 -0800 (PST) From: "az.com" To: invalid opcode cc: Brian Tao , FREEBSD-SECURITY-L Subject: Re: Suspicious symlinks in /tmp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk >From what I understand, the attack involves pointing a symlink to an important file in a priveledged area so that the file gets deleted upon system startup via the rc's auto /tmp clearing feature. From owner-freebsd-security Sun Feb 25 18:55:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA13952 for security-outgoing; Sun, 25 Feb 1996 18:55:33 -0800 (PST) Received: from cbn.cbn.com.sg ([203.120.18.128]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA13935 for ; Sun, 25 Feb 1996 18:55:15 -0800 (PST) Received: (from ngps@localhost) by cbn.cbn.com.sg (8.6.12/8.6.12) id KAA11962; Mon, 26 Feb 1996 10:48:09 +0800 Date: Mon, 26 Feb 1996 10:48:09 +0800 (SST) From: Ng Pheng Siong To: James FitzGibbon cc: Rashid Karimov , Brian Tao , freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Fri, 23 Feb 1996, James FitzGibbon wrote: > There's an excellent passwd replacement written in PERL that's part of > chapter 6 of "Programming Perl". It does bad words, pattern matching, > checking against reversed logins, other people's logins, GECOS fields, > etc. Being PERL, it could easily be changed to generation of passwords > (if that's what you want - I personally don't like it). I believe ANLpasswd is an improvement on that. - PS -- Ng Pheng Siong NetCentre Pte Ltd * Singapore Finger for PGP key. From owner-freebsd-security Sun Feb 25 20:57:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA20922 for security-outgoing; Sun, 25 Feb 1996 20:57:25 -0800 (PST) Received: from comtch.iea.com (comtch.iea.com [198.17.249.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA20917 for ; Sun, 25 Feb 1996 20:57:24 -0800 (PST) Received: by comtch.iea.com (8.6.10/SMI-4.1) id EAA07774; Mon, 26 Feb 1996 04:56:59 GMT Message-Id: <199602260456.EAA07774@comtch.iea.com> Subject: Re: Suspicious symlinks in /tmp To: coredump@nervosa.com (invalid opcode) Date: Sun, 25 Feb 1996 20:56:58 -0800 (PST) From: "Mark Smith" Cc: taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "invalid opcode" at Feb 25, 96 01:19:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > Looks like someone is trying to exploit a race condition in order to grab > the password file. > Will this attack work under FreeBSD 2.1R ? Mark From owner-freebsd-security Sun Feb 25 22:05:38 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA26391 for security-outgoing; Sun, 25 Feb 1996 22:05:38 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA26386 for ; Sun, 25 Feb 1996 22:05:33 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id HAA02200; Mon, 26 Feb 1996 07:51:00 +0200 (SAT) Message-Id: <199602260551.HAA02200@grumble.grondar.za> To: Ken Lam cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos 4 Slave Server Setup in 2.1 Date: Mon, 26 Feb 1996 07:50:59 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Ken Lam wrote: > I am trying to setup a slave server in 2.1. Both master and > slave are 2.1. I have scrounged up all the docs from the web > that I could find on doing it including some stuff from > indiana.edu and cygnus.com(CNS). > > I have tried a few likely configurations with no luck and > was wondering if there was someone out there in BSD-land > who could give me a hand. Ask away... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Sun Feb 25 23:28:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA00333 for security-outgoing; Sun, 25 Feb 1996 23:28:26 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA00327 for ; Sun, 25 Feb 1996 23:28:22 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id XAA10188; Sun, 25 Feb 1996 23:28:08 -0800 (PST) Date: Sun, 25 Feb 1996 23:28:07 -0800 (PST) From: invalid opcode To: Mark Smith cc: taob@io.org, freebsd-security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-Reply-To: <199602260456.EAA07774@comtch.iea.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Sun, 25 Feb 1996, Mark Smith wrote: > > Looks like someone is trying to exploit a race condition in order to grab > > the password file. > > Will this attack work under FreeBSD 2.1R ? > Mark A race condition attack will work under any OS when a race condition is possible. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-security Sun Feb 25 23:51:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA01610 for security-outgoing; Sun, 25 Feb 1996 23:51:28 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA01591 for ; Sun, 25 Feb 1996 23:51:12 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id IAA26861 ; Mon, 26 Feb 1996 08:51:04 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id IAA27618 ; Mon, 26 Feb 1996 08:51:03 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id IAA05354; Mon, 26 Feb 1996 08:47:45 +0100 (MET) From: Ollivier Robert Message-Id: <199602260747.IAA05354@keltia.freenix.fr> Subject: Re: Informing users of cracked passwords? To: ngps@cbn.com.sg (Ng Pheng Siong) Date: Mon, 26 Feb 1996 08:47:45 +0100 (MET) Cc: james@teamos2.org, rashid@rk.ios.com, taob@io.org, freebsd-security@FreeBSD.ORG In-Reply-To: from Ng Pheng Siong at "Feb 26, 96 10:48:09 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk It seems that Ng Pheng Siong said: > > I believe ANLpasswd is an improvement on that. Except that it does not support shadowing schemes. I had to hack it to support Sun's /etc/security/*.adjuct files. The same has to be done to support /etc/master.passwd and the new fields in it. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-security Mon Feb 26 07:37:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25586 for security-outgoing; Mon, 26 Feb 1996 07:37:03 -0800 (PST) Received: from comtch.iea.com (comtch.iea.com [198.17.249.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25580 for ; Mon, 26 Feb 1996 07:37:00 -0800 (PST) Received: by comtch.iea.com (8.6.10/SMI-4.1) id PAA11711; Mon, 26 Feb 1996 15:36:50 GMT Message-Id: <199602261536.PAA11711@comtch.iea.com> Subject: Re: Suspicious symlinks in /tmp To: coredump@nervosa.com (invalid opcode) Date: Mon, 26 Feb 1996 07:36:50 -0800 (PST) From: "Mark Smith" Cc: taob@io.org, freebsd-security@freebsd.org In-Reply-To: from "invalid opcode" at Feb 25, 96 11:28:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > On Sun, 25 Feb 1996, Mark Smith wrote: > > > > Looks like someone is trying to exploit a race condition in order to grab > > > the password file. > > > > Will this attack work under FreeBSD 2.1R ? > > Mark > > A race condition attack will work under any OS when a race condition is > possible. > Possibly, I didn't make my self clear. Is this race condition possible under FreeBSD 2.1R ? Mark From owner-freebsd-security Mon Feb 26 07:50:10 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26707 for security-outgoing; Mon, 26 Feb 1996 07:50:10 -0800 (PST) Received: from anna.az.com (root@anna.az.com [204.57.139.9]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA26701 for ; Mon, 26 Feb 1996 07:50:07 -0800 (PST) Received: (from yankee@localhost) by anna.az.com (8.6.12/8.6.12) id HAA03876; Mon, 26 Feb 1996 07:51:06 -0800 Date: Mon, 26 Feb 1996 07:51:06 -0800 (PST) From: "az.com" To: Ollivier Robert cc: Ng Pheng Siong , james@teamos2.org, rashid@rk.ios.com, taob@io.org, freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602260747.IAA05354@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk Perhaps it would be nice project to try to upgrade FreeBSD's password authentication and add an option which would move it away from the host and onto a separate system and also allow it to check for qualified passwords. The system's design would make it impossible in any way for even the owner of the authentication server to know what the real or encrypted version of the passwords were. (The first idea is similar to cisco TACACS or XYLOGICS Annex's ACP_PASSWD, the second idea is mine (or undoubtedly someone else's too?)) This system would be a 'drop-in-replacement' like kerberos that would go a step further and offer a super-huge DES like key that 'could not' be decrypted by any future super computer. It would use an encrypted handshaking scheme, moving time synchronization scheme, and even a unique mutating algorithm scheme that would make it immune to sniffing and hacking of all kinds. The changing algorithm(s) and/or the flavors in use on any particular password entry would again, not be viewable by even the owner of the authentication server. This system might require a chip on the authentication server used to randomly select the encryption formats and handshaking keys in case someone broke open and physically read the server's media, although I think something pretty good could be designed in software with enough effort. I realize this idea is in left field and does not follow the single-system model, but for bigger organizations who can afford a separate system, it should be at least added to unix as an alternative to the shadow password file and get password entry routines, etc. I know that similar things already exist, but I know of no 'drop-in-replacement' like this that can go right into a running unix system like kerberos or nis, etc. In addition, it would be nice if a set of special additional changing keys were granted by the server that could be used for things like optional decrypting/encrypting all data read/written from the file systems for a particular UID. On Mon, 26 Feb 1996, Ollivier Robert wrote: > It seems that Ng Pheng Siong said: > > > > I believe ANLpasswd is an improvement on that. > > Except that it does not support shadowing schemes. I had to hack it to > support Sun's /etc/security/*.adjuct files. The same has to be done to > support /etc/master.passwd and the new fields in it. > -- > Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net > FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 > From owner-freebsd-security Mon Feb 26 08:26:39 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA28494 for security-outgoing; Mon, 26 Feb 1996 08:26:39 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA28483 for ; Mon, 26 Feb 1996 08:26:31 -0800 (PST) Received: by haven.uniserve.com id <30777-28103>; Mon, 26 Feb 1996 08:28:38 -0800 Date: Mon, 26 Feb 1996 08:28:33 -0800 (PST) From: Tom Samplonius To: Mark Smith cc: invalid opcode , taob@io.org, freebsd-security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-Reply-To: <199602261536.PAA11711@comtch.iea.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 26 Feb 1996, Mark Smith wrote: > > > > On Sun, 25 Feb 1996, Mark Smith wrote: > > > > > > Looks like someone is trying to exploit a race condition in order to grab > > > > the password file. > > > > > > Will this attack work under FreeBSD 2.1R ? > > > Mark > > > > A race condition attack will work under any OS when a race condition is > > possible. > > > > Possibly, I didn't make my self clear. Is this race condition possible > under FreeBSD 2.1R ? The stock password file editing utils use /etc for temp space, so symlinks in /tmp is harmless. And as some have suggested, files pointed to by symlinks in /tmp will not be deleted during clearing of /tmp at bootup. Tom From owner-freebsd-security Mon Feb 26 08:32:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA28974 for security-outgoing; Mon, 26 Feb 1996 08:32:47 -0800 (PST) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA28960 for ; Mon, 26 Feb 1996 08:32:42 -0800 (PST) Received: from Ken (tsunami.awod.com [198.81.225.31]) by sumter.awod.com (8.6.11/8.6.9) with SMTP id LAA04399; Mon, 26 Feb 1996 11:32:27 -0500 Message-Id: <1.5.4b11.32.19960226163421.0068c12c@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 11:34:21 -0500 To: Mark Murray From: Ken Lam Subject: Re: Kerberos 4 Slave Server Setup in 2.1 Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG Precedence: bulk OK. The following is currently what I have done: I have added kpropd to inetd.conf in my slave, it does respond when I telnet to the port. I have a script which uses kdb_util to do a slave_dump and then calls kprop. I'm not quite sure which machines need the 'rcmd' principal and what instance they need, and I may have done the following wrong. rcmd.kerberos and rcmd.indigo are in both master and slave (with an 'ext_srvtab kerberos' srvtab on the slave). the docs say rcmd.HOSTNAME@REALM does that mean rcmd.indigo.awod.com@AWOD.COM ? krb.conf ---- AWOD.COM AWOD.COM moultrie.awod.com admin server AWOD.COM indigo.awod.com krb.realms ---- AWOD.COM AWOD.COM .AWOD.COM AWOD.COM krb.slaves ---- indigo.awod.com this is the console message I receive when trying to propogate: moultrie# /usr/sbin/kdbupdate Start slave propagation: Mon Feb 26 11:09:29 1996 indigo.awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo .awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.awod. com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com: G eneric kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.kprop: propagation failed. this is from the kerberos.log: 26-Feb-96 11:09:29 Initial ticket request Host: 198.81.225.2 User: "rcmd" "kerbe ros" 26-Feb-96 11:09:29 APPL Request rcmd.kerberos@AWOD.COM on 198.81.225.2 for rcmd. indigo Thanks again! Ken From owner-freebsd-security Mon Feb 26 09:35:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02830 for security-outgoing; Mon, 26 Feb 1996 09:35:09 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA02799 for ; Mon, 26 Feb 1996 09:34:41 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id TAA06499; Mon, 26 Feb 1996 19:33:52 +0200 (SAT) Message-Id: <199602261733.TAA06499@grumble.grondar.za> To: Ken Lam cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos 4 Slave Server Setup in 2.1 Date: Mon, 26 Feb 1996 19:33:50 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Ken Lam wrote: > OK. The following is currently what I have done: > > I have added kpropd to inetd.conf in my slave, it does > respond when I telnet to the port. I have a script > which uses kdb_util to do a slave_dump and then calls > kprop. > > I'm not quite sure which machines need the 'rcmd' > principal and what instance they need, and I may > have done the following wrong. The master needs to have an rcmd principal for each kerberised machine on the network in his realm. Each principal needs an instance that is the same name as the machine. Eg - I have two kerberised machines grunt.grondar.za and grumble.grondar.za. My kerberos server therefore has rcmd.grunt and rcmd.grumble. > rcmd.kerberos and rcmd.indigo are in both master > and slave (with an 'ext_srvtab kerberos' srvtab on > the slave). Do you have two machines called kerberos and indigo? Are they your master and slave? If so, you are OK. I would also put a srvtab on the master. > the docs say rcmd.HOSTNAME@REALM > > does that mean rcmd.indigo.awod.com@AWOD.COM ? No. rcmd.indigo@AWOD.COM, > krb.conf > ---- > AWOD.COM > AWOD.COM moultrie.awod.com admin server > AWOD.COM indigo.awod.com You have your rcmd.'s wrong. They should be (by above definition) be rcmd.moultrie and rcmd.indigo. > krb.realms > ---- > AWOD.COM AWOD.COM > .AWOD.COM AWOD.COM OK... > krb.slaves > ---- > indigo.awod.com ??? Is this a file? I find no reference to it anywhere? > this is the console message I receive when trying to propogate: > > moultrie# /usr/sbin/kdbupdate ^^^^^^^^^ What is this? > Start slave propagation: Mon Feb 26 11:09:29 1996 > indigo.awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.ind igo > .awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.aw od. > com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com : G > eneric kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com: Gene ric > kerberos error (kfailure). Calling krb_sendauth.kprop: propagation failed. > > this is from the kerberos.log: > > 26-Feb-96 11:09:29 Initial ticket request Host: 198.81.225.2 User: "rcmd" "ke rbe > ros" > 26-Feb-96 11:09:29 APPL Request rcmd.kerberos@AWOD.COM on 198.81.225.2 for rc md. Hmm. I'll need to look at a bit more. Do your logs mention any other (perhaps funny looking) pricipal.instance pairs? What other "Initial ticket requests" are you getting? Not being a kprop[d] user, I cannot offer you much specific advice about that. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Mon Feb 26 10:06:27 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04678 for security-outgoing; Mon, 26 Feb 1996 10:06:27 -0800 (PST) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA04668 for ; Mon, 26 Feb 1996 10:06:18 -0800 (PST) Received: from Ken (tsunami.awod.com [198.81.225.31]) by sumter.awod.com (8.6.11/8.6.9) with SMTP id NAA10961; Mon, 26 Feb 1996 13:05:56 -0500 Message-Id: <1.5.4b11.32.19960226180750.0068c940@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Feb 1996 13:07:50 -0500 To: Mark Murray From: Ken Lam Subject: Re: Kerberos 4 Slave Server Setup in 2.1 Cc: freebsd-security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG Precedence: bulk >> rcmd.kerberos and rcmd.indigo are in both master >> and slave (with an 'ext_srvtab kerberos' srvtab on >> the slave). > >Do you have two machines called kerberos and indigo? Are they your >master and slave? If so, you are OK. I would also put a srvtab on the >master. > >> the docs say rcmd.HOSTNAME@REALM >> >> does that mean rcmd.indigo.awod.com@AWOD.COM ? > >No. rcmd.indigo@AWOD.COM, > >> krb.conf >> ---- >> AWOD.COM >> AWOD.COM moultrie.awod.com admin server >> AWOD.COM indigo.awod.com > >You have your rcmd.'s wrong. They should be (by above definition) be >rcmd.moultrie and rcmd.indigo. OK. I have a DNS CNAME entry of kerberos for moultrie, but I will change that my conf file to kerberos. >> krb.realms >> ---- >> AWOD.COM AWOD.COM >> .AWOD.COM AWOD.COM > >OK... > >> krb.slaves >> ---- >> indigo.awod.com > >??? Is this a file? I find no reference to it anywhere? I found that in documentation from indiana.edu http://browneyes.ucs.indiana.edu/subject/kerberos/krb.slaves.html >> this is the console message I receive when trying to propogate: >> >> moultrie# /usr/sbin/kdbupdate > ^^^^^^^^^ >What is this? #!/bin/sh /usr/sbin/kdb_util slave_dump /etc/kerberosIV/krb_update_dump /usr/sbin/kprop /etc/kerberosIV/krb_update_dump /etc/kerberosIV/krb.slaves >> Start slave propagation: Mon Feb 26 11:09:29 1996 >> indigo.awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.ind >igo >> .awod.com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.aw >od. >> com: Generic kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com >: G >> eneric kerberos error (kfailure). Calling krb_sendauth.indigo.awod.com: Gene >ric >> kerberos error (kfailure). Calling krb_sendauth.kprop: propagation failed. >> >> this is from the kerberos.log: >> >> 26-Feb-96 11:09:29 Initial ticket request Host: 198.81.225.2 User: "rcmd" "ke >rbe >> ros" >> 26-Feb-96 11:09:29 APPL Request rcmd.kerberos@AWOD.COM on 198.81.225.2 for rc >md. > >Hmm. I'll need to look at a bit more. Do your logs mention any other >(perhaps funny looking) pricipal.instance pairs? What other "Initial ticket >requests" are you getting? Those are the only one's being generated by these attempts. >Not being a kprop[d] user, I cannot offer you much specific advice about >that. How are you handling your master/slave servers without kprop? Is there some other means? Thanks again Ken > From owner-freebsd-security Mon Feb 26 12:07:08 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12468 for security-outgoing; Mon, 26 Feb 1996 12:07:08 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA12460 for ; Mon, 26 Feb 1996 12:07:03 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id MAA11976; Mon, 26 Feb 1996 12:01:46 -0800 (PST) Date: Mon, 26 Feb 1996 12:01:46 -0800 (PST) From: invalid opcode To: Mark Smith cc: taob@io.org, freebsd-security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-Reply-To: <199602261536.PAA11711@comtch.iea.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 26 Feb 1996, Mark Smith wrote: > > A race condition attack will work under any OS when a race condition is > > possible. > > Possibly, I didn't make my self clear. Is this race condition possible > under FreeBSD 2.1R ? > Mark If it is a race condition, it will work. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-security Mon Feb 26 12:17:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12873 for security-outgoing; Mon, 26 Feb 1996 12:17:46 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA12864 for ; Mon, 26 Feb 1996 12:17:25 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id WAA07549; Mon, 26 Feb 1996 22:16:52 +0200 (SAT) Message-Id: <199602262016.WAA07549@grumble.grondar.za> To: Ken Lam cc: freebsd-security@FreeBSD.ORG Subject: Re: Kerberos 4 Slave Server Setup in 2.1 Date: Mon, 26 Feb 1996 22:16:51 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG Precedence: bulk Ken Lam wrote: > >> krb.slaves > >> ---- > >> indigo.awod.com > > > >??? Is this a file? I find no reference to it anywhere? > > I found that in documentation from indiana.edu > http://browneyes.ucs.indiana.edu/subject/kerberos/krb.slaves.html Scanning around this site, I get the general impression that their Kerberos is a little different to our eBones. Not much evidence to go on, but it seems as though they have a few scripts that we do not have. Might be worthwhile your getting their kprop[d] docs. > >Not being a kprop[d] user, I cannot offer you much specific advice about > >that. > > How are you handling your master/slave servers without kprop? Is there > some other means? I am a small site (very small!), so I do not have much call for it. OTOH, if I was asked to set up something, I would probably (and this is suggested with just about ZERO thought) use something like encrypted and kerberised rcp with cron jobs to kick action into the file movements. Look at the source for kprop[d]. Even MIT doesn't advocate their use. (Thinks - "Hmm - what is MIT using now?" - you may want to look in Kerberos5) > Thanks again No prob. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Mon Feb 26 12:26:15 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13365 for security-outgoing; Mon, 26 Feb 1996 12:26:15 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13360 for ; Mon, 26 Feb 1996 12:26:11 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id PAA28045; Mon, 26 Feb 1996 15:25:12 -0500 Date: Mon, 26 Feb 1996 15:25:12 -0500 (EST) From: Brian Tao To: invalid opcode cc: Mark Smith , freebsd-security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 26 Feb 1996, invalid opcode wrote: > > On Mon, 26 Feb 1996, Mark Smith wrote: > > > A race condition attack will work under any OS when a race condition is > > > possible. > > > > Possibly, I didn't make my self clear. Is this race condition possible > > under FreeBSD 2.1R ? > > Mark > > If it is a race condition, it will work. We seem to be going around in circles here. ;-) -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Feb 26 12:50:58 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15001 for security-outgoing; Mon, 26 Feb 1996 12:50:58 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA14994 for ; Mon, 26 Feb 1996 12:50:55 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id PAA00245; Mon, 26 Feb 1996 15:49:30 -0500 Date: Mon, 26 Feb 1996 15:49:30 -0500 (EST) From: Brian Tao To: Ollivier Robert cc: Ng Pheng Siong , james@teamos2.org, rashid@rk.ios.com, freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602260747.IAA05354@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Mon, 26 Feb 1996, Ollivier Robert wrote: > > It seems that Ng Pheng Siong said: > > > > I believe ANLpasswd is an improvement on that. > > Except that it does not support shadowing schemes. Linking in libcrack with the standard passwd that comes with FreeBSD and BSD/OS works quite well for us (we're obviously using DES here). -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Feb 26 13:09:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16326 for security-outgoing; Mon, 26 Feb 1996 13:09:26 -0800 (PST) Received: from merit.edu (merit.edu [35.1.1.42]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA16321 for ; Mon, 26 Feb 1996 13:09:23 -0800 (PST) Received: from ohm.merit.edu (ohm.merit.edu [198.108.60.65]) by merit.edu (8.7.3/merit-2.0) with ESMTP id QAA26936; Mon, 26 Feb 1996 16:07:28 -0500 (EST) From: William Bulley Received: (web@localhost) by ohm.merit.edu (8.6.9/8.6.5) id QAA09158; Mon, 26 Feb 1996 16:17:06 -0500 Message-Id: <199602262117.QAA09158@ohm.merit.edu> Subject: Re: Informing users of cracked passwords? To: yankee@anna.az.com Date: Mon, 26 Feb 1996 16:17:05 -0500 (EST) Cc: freebsd-security@freebsd.org, roberto@keltia.freenix.fr, ngps@cbn.com.sg, james@teamos2.org, rashid@rk.ios.com, taob@io.org In-Reply-To: from "az.com" at Feb 26, 96 07:51:06 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk According to az.com: > > Perhaps it would be nice project to try to upgrade FreeBSD's password > authentication and add an option which would move it away from the host > and onto a separate system and also allow it to check for qualified > passwords. The system's design would make it impossible in any way for > even the owner of the authentication server to know what the real or > encrypted version of the passwords were. (The first idea is similar to > cisco TACACS or XYLOGICS Annex's ACP_PASSWD, the second idea is mine (or > undoubtedly someone else's too?)) I would recommend RADIUS for this job. I would be willing to give some informal quidance to those interested in doing the actual work... Regards, web... -- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 4251 Plymouth Road MaBell: (313) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (313) 747-3185 From owner-freebsd-security Mon Feb 26 13:11:00 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16473 for security-outgoing; Mon, 26 Feb 1996 13:11:00 -0800 (PST) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16464 for ; Mon, 26 Feb 1996 13:10:52 -0800 (PST) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id NAA13050; Mon, 26 Feb 1996 13:10:47 -0800 From: Nathan Lawson Message-Id: <199602262110.NAA13050@kdat.calpoly.edu> Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Mon, 26 Feb 1996 13:10:47 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <9602251821.AA15742@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Feb 25, 96 01:21:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > < said: > > > You'd not have these services :-) Usually the daytime service can be > > moderately useful, since it doesn't suffer from the bombing problems > > (sure, you can get it to generate a packet, but it will be only > > one). > > However, it is trivial to get the daytime service to ping-pong with > the echo service. Same thing for the chargen service (don't know what > purpose that serves...) Another attack that would possibly work is that you could send a packet to the daytime port from the broadcast address. I believe that most modern systems (including FreeBSD) will need the socket to have SO_BROADCAST set so this most likely won't succeed. However, I believe that if a service is for network testing, then why have it enabled by default? What percentage of traffic on your average net is to the chargen port as opposed to say, telnet and smtp? It can possibly hurt things, it doesn't necessarily help much, so leave it off by default. > > UDP is, at present, the only thing impacted. It only takes one rogue > > packet to set them jabbering at each other (which is one reason we > > don't allow any IP packets with "src" of one of our netblock through > > our firewall). > > Of course, that doesn't help you if the forged source is on someone > else's network... Be kind to your neighbors. Block outgoing spoofed source addresses as well as incoming. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, CS-EE double \when she told me 'mad and meaningless as ever...' and a song major, \came on the radio like a cemetery rhyme for a million crying unaccredited \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Mon Feb 26 13:19:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17305 for security-outgoing; Mon, 26 Feb 1996 13:19:48 -0800 (PST) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17300 for ; Mon, 26 Feb 1996 13:19:46 -0800 (PST) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id NAA13075; Mon, 26 Feb 1996 13:19:27 -0800 From: Nathan Lawson Message-Id: <199602262119.NAA13075@kdat.calpoly.edu> Subject: Re: Suspicious symlinks in /tmp To: msmith@comtch.iea.com (Mark Smith) Date: Mon, 26 Feb 1996 13:19:27 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <199602261536.PAA11711@comtch.iea.com> from "Mark Smith" at Feb 26, 96 07:36:50 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > > > > On Sun, 25 Feb 1996, Mark Smith wrote: > > > > > Looks like someone is trying to exploit a race condition in order to grab > > > > the password file. > > > > > > Will this attack work under FreeBSD 2.1R ? > > > Mark > > > > A race condition attack will work under any OS when a race condition is > > possible. > > > > Possibly, I didn't make my self clear. Is this race condition possible > under FreeBSD 2.1R ? No. Absolutely not. That was a bug in SunOS's passwd program. Specifying -F allowed the user to specify a passwd file to change. However, the bug that I have seen for quite a while and complained about is that a symlink is owned by the owner of the file it points to, not by the creator of the symlink. That is a bad idea and I really can't see the logic behind doing that. Could someone explain this behavior? -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, CS-EE double \when she told me 'mad and meaningless as ever...' and a song major, \came on the radio like a cemetery rhyme for a million crying unaccredited \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Mon Feb 26 13:21:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17584 for security-outgoing; Mon, 26 Feb 1996 13:21:45 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA17572 for ; Mon, 26 Feb 1996 13:21:41 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id QAA04587; Mon, 26 Feb 1996 16:20:48 -0500 Date: Mon, 26 Feb 1996 16:20:48 -0500 (EST) From: Brian Tao To: William Bulley cc: freebsd-security@freebsd.org Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602262117.QAA09158@ohm.merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 26 Feb 1996, William Bulley wrote: > > I would recommend RADIUS for this job. I would be willing to give some > informal quidance to those interested in doing the actual work... I'm *very* interested in this. We are embarking here on an ambitious project to centralize accounting and billing information with user authentication and access control. We need something scalable beyond 100,000 users, yet still be accessible through secure channels on a nation-wide network. We are already using RADIUS for dialup authentication on our Livingston PM-2e termservers. Luckily, I'm not directly involved in the coding of that project ;-), but if you have any thoughts on alternatives to the traditional UNIX passwd/NIS-based solutions, I'm all ears. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Feb 26 13:30:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18491 for security-outgoing; Mon, 26 Feb 1996 13:30:51 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA18481 for ; Mon, 26 Feb 1996 13:30:45 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA24901; Mon, 26 Feb 1996 16:30:42 -0500 Date: Mon, 26 Feb 1996 16:30:42 -0500 From: "Garrett A. Wollman" Message-Id: <9602262130.AA24901@halloran-eldar.lcs.mit.edu> To: Nathan Lawson Cc: security@freebsd.org Subject: Re: Alert: UDP Port Denial-of-Service Attack (fwd) In-Reply-To: <199602262110.NAA13050@kdat.calpoly.edu> References: <9602251821.AA15742@halloran-eldar.lcs.mit.edu> <199602262110.NAA13050@kdat.calpoly.edu> Sender: owner-security@freebsd.org Precedence: bulk < said: > Another attack that would possibly work is that you could send a packet to > the daytime port from the broadcast address. I believe that most modern > systems (including FreeBSD) will need the socket to have SO_BROADCAST set > so this most likely won't succeed. Actually, substitute `all-hosts multicast' for `broadcast' and `to and from' for `from', and you've got the original scenario which caused me to shudder for a minute and then write this code. Can you say `broadcast storm'? I knew you could... :-( > Be kind to your neighbors. Block outgoing spoofed source addresses as well > as incoming. That doesn't help us, where most of the trouble comes from cracked machines on our own networks... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Mon Feb 26 15:37:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA27014 for security-outgoing; Mon, 26 Feb 1996 15:37:32 -0800 (PST) Received: from gw0.telebase.com (root@gw0.telebase.com [192.132.57.100]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA27007 for ; Mon, 26 Feb 1996 15:37:25 -0800 (PST) Received: from wormhole.telebase.com by gw0.telebase.com id SAA10660; Mon, 26 Feb 1996 18:37:16 -0500 (EST) Received: from odo.telebase.com (root@odo.telebase.com [172.16.2.217]) by wormhole.telebase.com (8.7.1/8.6.9.1) with ESMTP id SAA16955; Mon, 26 Feb 1996 18:37:15 -0500 (EST) Received: (from bmc@localhost) by odo.telebase.com (8.6.12/8.6.9.1) id SAA00872; Mon, 26 Feb 1996 18:37:15 -0500 Date: Mon, 26 Feb 1996 18:37:15 -0500 Message-Id: <199602262337.SAA00872@telebase.com.> From: Brian Clapper To: Nathan Lawson Cc: msmith@comtch.iea.com (Mark Smith), security@FreeBSD.ORG Subject: Re: Suspicious symlinks in /tmp In-Reply-To: <60614237@toto.iv> Sender: owner-security@FreeBSD.ORG Precedence: bulk >>>>> "Nathan" == Nathan Lawson writes: Nathan> However, the bug that I have seen for quite a while and complained Nathan> about is that a symlink is owned by the owner of the file it points Nathan> to, not by the creator of the symlink. That is a bad idea and I Nathan> really can't see the logic behind doing that. Nathan> Could someone explain this behavior? Hmmm. Doesn't work that way on my 2.1R system: % id uid=200(bmc) gid=200(bmc) groups=200(bmc), 1000(eng) % ln -s /etc/passwd . % ls -l /etc/passwd passwd -rw-r--r-- 1 root wheel 1176 Feb 16 09:59 /etc/passwd lrwxr-xr-x 1 bmc wheel 11 Feb 26 18:31 passwd -> /etc/passwd As it turns out, the symlink ends up being owned by whoever owns its parent directory--regardless of the UID of the process that created the symlink and regardless of the UID that owns the file to which it points. Thus, if I create the same symlink in /tmp (as `bmc'), the symlink is owned by `bin' (the owner of /tmp). Likewise, if I login as `root' and create the same symlink in my home directory, the symlink is owned by `bmc', not `root'. Also highly counterintuitive behavior, at least to me. ---- Brian Clapper .............................................. bmc@telebase.com http://www.netaxs.com/~bmc/ ............. PGP public key available on request And now for something completely different. From owner-freebsd-security Mon Feb 26 17:10:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA03655 for security-outgoing; Mon, 26 Feb 1996 17:10:20 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA03646 for ; Mon, 26 Feb 1996 17:10:16 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id UAA03295; Mon, 26 Feb 1996 20:08:15 -0500 Date: Mon, 26 Feb 1996 20:08:14 -0500 (EST) From: Brian Tao To: cschuber@orca.gov.bc.ca cc: FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602231757.JAA27883@passer.osg.gov.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk On Fri, 23 Feb 1996, Cy Schubert - BCSC Open Systems Group wrote: > > ALL EXCEPT rlogind rshd rexecd fingerd: ALL > rlogind rshd rexecd: .io.org > > These two lines restrict rlogin, rsh, and rexec to hosts within the io.org > domain while allowing connections to all other services from anywhere in the > world. Yes, that sounds like a good idea to me. I'm toying with the idea of disallowing rlogin and rsh connections from outside the io.org domain and forcing users to supply passwords through a telnet connection. Is there anything wrong with his idea? I know users will kick and scream about it, but I can't think of any reason other than security vs. convenience issues. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Mon Feb 26 20:16:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA20518 for security-outgoing; Mon, 26 Feb 1996 20:16:53 -0800 (PST) Received: from psychotic.communica.com.au (gw.communica.com.au [203.8.94.161]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA20274 for ; Mon, 26 Feb 1996 20:15:30 -0800 (PST) Received: from communica.com.au (newton@frenzy [192.82.222.1]) by psychotic.communica.com.au (8.6.12/8.6.9) with SMTP id OAA04941; Tue, 27 Feb 1996 14:42:54 +1030 Received: by communica.com.au (4.1/SMI-4.1) id AA25647; Tue, 27 Feb 96 14:41:27 CDT From: newton@communica.com.au (Mark Newton) Message-Id: <9602270411.AA25647@communica.com.au> Subject: Re: Suspicious symlinks in /tmp To: bmc@telebase.com (Brian Clapper) Date: Tue, 27 Feb 1996 14:41:27 +1030 (CST) Cc: nlawson@kdat.csc.calpoly.edu, msmith@comtch.iea.com, security@FreeBSD.ORG In-Reply-To: <199602262337.SAA00872@telebase.com.> from "Brian Clapper" at Feb 26, 96 06:37:15 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-security@FreeBSD.ORG Precedence: bulk Brian Clapper wrote: > -rw-r--r-- 1 root wheel 1176 Feb 16 09:59 /etc/passwd > lrwxr-xr-x 1 bmc wheel 11 Feb 26 18:31 passwd -> /etc/passwd > > As it turns out, the symlink ends up being owned by whoever owns its parent > directory--regardless of the UID of the process that created the symlink > and regardless of the UID that owns the file to which it points. [ ... ] > Also highly counterintuitive behavior, at least to me. ... also totally irrelevent: The permissions on the symlink don't arbitrate file access permissions -- The permissions on the file it's pointing to (ie: the destination) are used for that purpose. So: Not only does it not matter who owns the symlink, it also doesn't matter how it is chmod'ed. You can set its permissions to rwxrwxrwx without making a spot of difference to the accessibility of the file it's pointing at. - mark --- Mark Newton Email: newton@communica.com.au Systems Engineer Phone: +61-8-373-2523 Communica Systems WWW: http://www.communica.com.au From owner-freebsd-security Mon Feb 26 21:42:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28378 for security-outgoing; Mon, 26 Feb 1996 21:42:49 -0800 (PST) Received: from zap.zap.qc.ca (zap.zap.qc.ca [199.202.234.77]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA28371 for ; Mon, 26 Feb 1996 21:42:44 -0800 (PST) Received: (from fortin@localhost) by zap.zap.qc.ca (8.7.4/8.7.3) id AAA03324; Tue, 27 Feb 1996 00:42:23 -0500 (EST) Date: Tue, 27 Feb 1996 00:42:22 -0500 (EST) From: Denis Fortin To: Brian Tao cc: cschuber@orca.gov.bc.ca, FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org Precedence: bulk On Mon, 26 Feb 1996, Brian Tao wrote: > I'm toying with the idea of disallowing rlogin and rsh connections from > outside the io.org domain and forcing users to supply passwords through a > telnet connection. Is there anything wrong with his idea? I know users will > kick and scream about it, but I can't think of any reason other than > security vs. convenience issues. This is what I usually do (i.e. disable rlogin and let people use telnet), but fans of rlogin will then tell you that by doing that you're forcing people to send login passwords in clear on the network where they can be sniffed (whereas with rlogin, you wouldn't have to type in the password). But anyway, I'd rather have people use telnet... I've always found the "r" commands to be too magical for my taste :-) Denis Fortin fortin@acm.org DMR Group Inc, (514) 877-3301 These opinions are my own From owner-freebsd-security Mon Feb 26 23:20:36 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA07436 for security-outgoing; Mon, 26 Feb 1996 23:20:36 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA07431 for ; Mon, 26 Feb 1996 23:20:33 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id XAA14610; Mon, 26 Feb 1996 23:20:02 -0800 (PST) Date: Mon, 26 Feb 1996 23:20:02 -0800 (PST) From: invalid opcode To: Brian Tao cc: Mark Smith , freebsd-security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Mon, 26 Feb 1996, Brian Tao wrote: > We seem to be going around in circles here. ;-) > Brian Tao (BT300, taob@io.org) It has been brought to my attention that none of the standard password utilities make use of /tmp, only /etc. So you should be safe there. But of course, if there are any suid programs that use relative paths instead of absolute ones, this will be a problem. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-security Tue Feb 27 01:09:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA20003 for security-outgoing; Tue, 27 Feb 1996 01:09:23 -0800 (PST) Received: from mistery.mcafee.com (root@mistery.mcafee.com [192.187.128.69]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA19998 for ; Tue, 27 Feb 1996 01:09:17 -0800 (PST) Received: (from jimd@localhost) by mistery.mcafee.com (8.6.11/8.6.9) id AAA01133; Tue, 27 Feb 1996 00:17:22 -0800 From: Jim Dennis Message-Id: <199602270817.AAA01133@mistery.mcafee.com> Subject: Re: Informing users of cracked passwords? To: taob@io.org (Brian Tao) Date: Tue, 27 Feb 1996 00:17:21 -0800 (PST) Cc: cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Feb 26, 96 08:08:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk > > On Fri, 23 Feb 1996, Cy Schubert - BCSC Open Systems Group wrote: > > > > ALL EXCEPT rlogind rshd rexecd fingerd: ALL > > rlogind rshd rexecd: .io.org > > > > These two lines restrict rlogin, rsh, and rexec to hosts within the io.org > > domain while allowing connections to all other services from anywhere in the > > world. > > Yes, that sounds like a good idea to me. I'm toying with the idea > of disallowing rlogin and rsh connections from outside the io.org > domain and forcing users to supply passwords through a telnet > connection. Is there anything wrong with his idea? I know users will > kick and scream about it, but I can't think of any reason other than > security vs. convenience issues. > -- Anyone who kicks about the "inconvenience" of supplying a password to telnet should seriously consider learning 'expect' (on their *ix systems) or getting a script capable telnet client (on other systems). Give them a fish, feed them for a day, give them a scripting language .... From owner-freebsd-security Tue Feb 27 06:16:01 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA20736 for security-outgoing; Tue, 27 Feb 1996 06:16:01 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA20723 for ; Tue, 27 Feb 1996 06:15:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id GAA07122; Tue, 27 Feb 1996 06:15:40 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602271415.GAA07122@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Brian Tao cc: cschuber@orca.gov.bc.ca, FREEBSD-SECURITY-L Subject: Re: Informing users of cracked passwords? In-reply-to: Your message of "Mon, 26 Feb 96 20:08:14 EST." Date: Tue, 27 Feb 96 06:15:40 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk > On Fri, 23 Feb 1996, Cy Schubert - BCSC Open Systems Group wrote: > > > > ALL EXCEPT rlogind rshd rexecd fingerd: ALL > > rlogind rshd rexecd: .io.org > > > > These two lines restrict rlogin, rsh, and rexec to hosts within the io.org > > domain while allowing connections to all other services from anywhere in th e > > world. > > Yes, that sounds like a good idea to me. I'm toying with the idea > of disallowing rlogin and rsh connections from outside the io.org > domain and forcing users to supply passwords through a telnet > connection. Is there anything wrong with his idea? I know users will > kick and scream about it, but I can't think of any reason other than > security vs. convenience issues. If a user trusts an account on another host and that host has been hacked, you have to assume your host has been compromised as well. You cannot assume otherwise because you have no evidence to the contrary. Once a hacker has an account on a system you or your users trust, it's just a matter of time before the hacker has root on your system. > -- > Brian Tao (BT300, taob@io.org) > Systems Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Feb 27 07:03:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA24116 for security-outgoing; Tue, 27 Feb 1996 07:03:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA24100 for ; Tue, 27 Feb 1996 07:03:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA03316; Wed, 28 Feb 1996 01:57:55 +1100 Date: Wed, 28 Feb 1996 01:57:55 +1100 From: Bruce Evans Message-Id: <199602271457.BAA03316@godzilla.zeta.org.au> To: bmc@telebase.com, newton@communica.com.au Subject: Re: Suspicious symlinks in /tmp Cc: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk >... also totally irrelevent: The permissions on the symlink don't >arbitrate file access permissions -- The permissions on the file it's >pointing to (ie: the destination) are used for that purpose. >So: Not only does it not matter who owns the symlink, it also doesn't >matter how it is chmod'ed. You can set its permissions to rwxrwxrwx >without making a spot of difference to the accessibility of the file >it's pointing at. The uid matters for symlinks in sticky directories: $ ln -s /etc/passwd /tmp/mysymlink $ rm /tmp/mysymlink rm: /tmp/mysymlink: Operation not permitted Bruce From owner-freebsd-security Tue Feb 27 07:07:29 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA24577 for security-outgoing; Tue, 27 Feb 1996 07:07:29 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA24560 for ; Tue, 27 Feb 1996 07:07:17 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA03513; Wed, 28 Feb 1996 02:03:09 +1100 Date: Wed, 28 Feb 1996 02:03:09 +1100 From: Bruce Evans Message-Id: <199602271503.CAA03513@godzilla.zeta.org.au> To: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu Subject: Re: Suspicious symlinks in /tmp Cc: security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk >However, the bug that I have seen for quite a while and complained about is >that a symlink is owned by the owner of the file it points to, not by the >creator of the symlink. That is a bad idea and I really can't see the logic >behind doing that. >Could someone explain this behavior? The symlink is owned by the owner of its parent directory. I think this is to conform to future POSIX standards. Many other things involving symlinks changed in 4.4lite. See `man 7 symlink'. Bruce From owner-freebsd-security Tue Feb 27 09:37:37 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06157 for security-outgoing; Tue, 27 Feb 1996 09:37:37 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06152 for ; Tue, 27 Feb 1996 09:37:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id IAA07339; Tue, 27 Feb 1996 08:46:14 -0800 Message-Id: <199602271646.IAA07339@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Bruce Evans cc: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@FreeBSD.org Subject: Re: Suspicious symlinks in /tmp In-reply-to: Your message of "Wed, 28 Feb 1996 02:03:09 +1100." <199602271503.CAA03513@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 27 Feb 1996 08:46:14 -0800 Sender: owner-security@FreeBSD.org Precedence: bulk >>However, the bug that I have seen for quite a while and complained about is >>that a symlink is owned by the owner of the file it points to, not by the >>creator of the symlink. That is a bad idea and I really can't see the logic >>behind doing that. > >>Could someone explain this behavior? > >The symlink is owned by the owner of its parent directory. > >I think this is to conform to future POSIX standards. Many other things >involving symlinks changed in 4.4lite. See `man 7 symlink'. NetBSD recently went back to the previous/traditional behavior for symlinks. I think we should too - the "new" model is incompatible with sticky bit directories. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Feb 27 09:52:51 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07467 for security-outgoing; Tue, 27 Feb 1996 09:52:51 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07451 for freebsd-security; Tue, 27 Feb 1996 09:52:47 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199602271752.JAA07451@freefall.freebsd.org> Subject: strawman comments To: freebsd-security Date: Tue, 27 Feb 1996 09:52:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-security@FreeBSD.ORG Precedence: bulk i want to able to filter on both incoming and outgoing interfaces. if0 is accounting if1 is engineering if2 is marketing no traffic from marketing to engineering allow traffic from engineering to marketing allow traffic from marketing to accounting allow traffic from accounting to marketing allow traffic from accounting to engineering allow traffic from engineering to marketing this can be done using ip addresses (or ranges) but specifying interfaces is easier, and i wont let me forget any (sub)nets it does not seems to be possible to filter on both interfaces from the strawman. this may be a real bear to implement in the kernel only after the route is chosen can the rule be applied. the packet has to carry around information regarding which interface it arrived on. (ugh.) warning the following may be just "persnickitiness" on my part. actions: it is implied that all actions are mutually exclusive. "count" could be combined with any of the other actions. should state mall actions are mutually exclusive. count action: strawman says "counters are updated, but the rule doesnt match the packet, and the next rule is tried." man page says "update counters for all packets that match rule. The search continues with the next rule." this confuses me. i guess that "but the rule doesnt match" means that "count" is never the last rule applied. "rules are applied in numerical order until one of them matches the packet" implying that once a match occurs ipfw applies the actions specified in that rule and stops processing that packet. we dont want "count" to be a terminal rule, so it must not match, ever. this exception is needed because "count" cant be combined with any other action. should ipfw be changed to allow "count" to combine with any other action? we would then need a "continue" action to let us count all packets of a general type, some of which we will later drop, others we will accept. on the external interface: i want to count all inbound nnrp (but continue processing rules) i want to accept and count inbound nnrp from allowed news readers i want to drop, cound and log all other nnrp packets should should "count" be a modifier like "syslog"? not an action like "accept"? -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ From owner-freebsd-security Tue Feb 27 12:56:06 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA02551 for security-outgoing; Tue, 27 Feb 1996 12:56:06 -0800 (PST) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA02546 for ; Tue, 27 Feb 1996 12:56:04 -0800 (PST) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id MAA15968; Tue, 27 Feb 1996 12:55:46 -0800 From: Nathan Lawson Message-Id: <199602272055.MAA15968@kdat.calpoly.edu> Subject: Re: Suspicious symlinks in /tmp To: newton@communica.com.au (Mark Newton) Date: Tue, 27 Feb 1996 12:55:45 -0800 (PST) Cc: security@freebsd.org In-Reply-To: <9602270411.AA25647@communica.com.au> from "Mark Newton" at Feb 27, 96 02:41:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > ... also totally irrelevent: The permissions on the symlink don't > arbitrate file access permissions -- The permissions on the file it's > pointing to (ie: the destination) are used for that purpose. > > So: Not only does it not matter who owns the symlink, it also doesn't > matter how it is chmod'ed. You can set its permissions to rwxrwxrwx > without making a spot of difference to the accessibility of the file > it's pointing at. Yes, but let's say Joe User tries out the ln -s command. Now he can't delete his symlink. This behavior is broken. A user should not be able to create any type of file, whether a symlink or just a normal file, that is owned by another user. Like I said before, how about a justification as to the usefullness of this behavior? I've already provided one annoying result of it. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, CS-EE double \when she told me 'mad and meaningless as ever...' and a song major, \came on the radio like a cemetery rhyme for a million crying unaccredited \corpses in their tragedy of respectable existence. - BR From owner-freebsd-security Tue Feb 27 21:01:45 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA12451 for security-outgoing; Tue, 27 Feb 1996 21:01:45 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA12446 for ; Tue, 27 Feb 1996 21:01:44 -0800 (PST) Received: from GndRsh.aac.dev.com ([198.145.92.241]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id VAA21897 for ; Tue, 27 Feb 1996 21:01:40 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id UAA16688; Tue, 27 Feb 1996 20:49:37 -0800 From: "Rodney W. Grimes" Message-Id: <199602280449.UAA16688@GndRsh.aac.dev.com> Subject: Re: Suspicious symlinks in /tmp To: davidg@Root.COM Date: Tue, 27 Feb 1996 20:49:37 -0800 (PST) Cc: bde@zeta.org.au, msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org In-Reply-To: <199602271646.IAA07339@Root.COM> from "David Greenman" at Feb 27, 96 08:46:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk > > >>However, the bug that I have seen for quite a while and complained about is > >>that a symlink is owned by the owner of the file it points to, not by the > >>creator of the symlink. That is a bad idea and I really can't see the logic > >>behind doing that. > > > >>Could someone explain this behavior? > > > >The symlink is owned by the owner of its parent directory. > > > >I think this is to conform to future POSIX standards. Many other things > >involving symlinks changed in 4.4lite. See `man 7 symlink'. > > NetBSD recently went back to the previous/traditional behavior for > symlinks. I think we should too - the "new" model is incompatible with > sticky bit directories. I wish we would have done this last time this discussion came up, I think it is way past due. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-security Tue Feb 27 21:13:33 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA12595 for security-outgoing; Tue, 27 Feb 1996 21:13:33 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA12590 for ; Tue, 27 Feb 1996 21:13:32 -0800 (PST) Received: from zip.io.org (root@[198.133.36.80]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id VAA21975 for ; Tue, 27 Feb 1996 21:13:30 -0800 Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id AAA02864; Wed, 28 Feb 1996 00:11:14 -0500 Date: Wed, 28 Feb 1996 00:11:14 -0500 (EST) From: Brian Tao To: Jim Dennis cc: freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602280504.VAA05385@mistery.mcafee.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Tue, 27 Feb 1996, Jim Dennis wrote: > > According to this the standard shadow password suite has an > option in the semantics of the /etc/shadow file to specify > an additional or alternative authentication program (as well > as all that password aging and account expiration stuff). BSD/OS 2.1 has implemented login classes (defined in the pw_class member of the standard passwd struct) to this end. It allows for additional authentication in addition to the traditiional UNIX password scheme (typically one-time password or challenge-response schemes). The /etc/login.conf file lets you specify user classes, the authentication model they follow as well as other aspects such as maximum memory usage, maximum per-process CPU time, minimum and maximum password lengths, etc. It would be nice if FreeBSD could adopt this format, since this is the first commercial use (AFAIK) of the pw_class field in a master.passwd entry. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Tue Feb 27 22:41:41 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA15650 for security-outgoing; Tue, 27 Feb 1996 22:41:41 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA15643 for ; Tue, 27 Feb 1996 22:41:38 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA12475 ; Wed, 28 Feb 1996 07:41:32 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA09004 ; Wed, 28 Feb 1996 07:41:30 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id XAA01033; Tue, 27 Feb 1996 23:57:09 +0100 (MET) From: Ollivier Robert Message-Id: <199602272257.XAA01033@keltia.freenix.fr> Subject: Re: Suspicious symlinks in /tmp To: bde@zeta.org.au (Bruce Evans) Date: Tue, 27 Feb 1996 23:57:09 +0100 (MET) Cc: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@FreeBSD.org In-Reply-To: <199602271503.CAA03513@godzilla.zeta.org.au> from Bruce Evans at "Feb 28, 96 02:03:09 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that Bruce Evans said: > I think this is to conform to future POSIX standards. Many other things > involving symlinks changed in 4.4lite. See `man 7 symlink'. davidg also said it was not to use an inode for the symlink itself so every symlink in 4.4BSD are fast symlinks (as it was possible to use in FreeBSD 1.1.5.1). It don't like our behaviour either. Highly counterintuitive and deadly for sticky directories too where a user can't remove a link he made. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-security Tue Feb 27 22:41:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA15673 for security-outgoing; Tue, 27 Feb 1996 22:41:48 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA15661 for ; Tue, 27 Feb 1996 22:41:44 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA12479 ; Wed, 28 Feb 1996 07:41:41 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA09007 ; Wed, 28 Feb 1996 07:41:32 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id XAA01043; Tue, 27 Feb 1996 23:59:10 +0100 (MET) From: Ollivier Robert Message-Id: <199602272259.XAA01043@keltia.freenix.fr> Subject: Re: Informing users of cracked passwords? To: fortin@zap.qc.ca (Denis Fortin) Date: Tue, 27 Feb 1996 23:59:10 +0100 (MET) Cc: taob@io.org, cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.ORG In-Reply-To: from Denis Fortin at "Feb 27, 96 00:42:22 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk It seems that Denis Fortin said: > But anyway, I'd rather have people use telnet... I've always found the > "r" commands to be too magical for my taste :-) The answer is called SSH. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-security Tue Feb 27 23:32:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA18959 for security-outgoing; Tue, 27 Feb 1996 23:32:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA18949 for ; Tue, 27 Feb 1996 23:32:48 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA31286; Wed, 28 Feb 1996 18:30:59 +1100 Date: Wed, 28 Feb 1996 18:30:59 +1100 From: Bruce Evans Message-Id: <199602280730.SAA31286@godzilla.zeta.org.au> To: bde@zeta.org.au, roberto@keltia.freenix.fr Subject: Re: Suspicious symlinks in /tmp Cc: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk >> I think this is to conform to future POSIX standards. Many other things >> involving symlinks changed in 4.4lite. See `man 7 symlink'. >davidg also said it was not to use an inode for the symlink itself so every >symlink in 4.4BSD are fast symlinks (as it was possible to use in FreeBSD >1.1.5.1). Fast/small symlinks use an inode but not a data block. Very fast/small symlinks would use only a directory entry (or two). Then there would be nowhere to store the uid etc. >It don't like our behaviour either. Highly counterintuitive and deadly for >sticky directories too where a user can't remove a link he made. Very intuitive if you don't know about inodes :-). Bruce From owner-freebsd-security Wed Feb 28 00:04:25 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA20949 for security-outgoing; Wed, 28 Feb 1996 00:04:25 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA20943 for ; Wed, 28 Feb 1996 00:04:16 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id SAA16934; Wed, 28 Feb 1996 18:35:36 +1030 From: Michael Smith Message-Id: <199602280805.SAA16934@genesis.atrad.adelaide.edu.au> Subject: Re: Suspicious symlinks in /tmp To: nlawson@kdat.csc.calpoly.edu (Nathan Lawson) Date: Wed, 28 Feb 1996 18:35:36 +1030 (CST) Cc: newton@communica.com.au, security@freebsd.org In-Reply-To: <199602272055.MAA15968@kdat.calpoly.edu> from "Nathan Lawson" at Feb 27, 96 12:55:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Nathan Lawson stands accused of saying: > > > > So: Not only does it not matter who owns the symlink, it also doesn't > > matter how it is chmod'ed. You can set its permissions to rwxrwxrwx > > without making a spot of difference to the accessibility of the file > > it's pointing at. > > Yes, but let's say Joe User tries out the ln -s command. Now he can't delete > his symlink. This behavior is broken. A user should not be able to create > any type of file, whether a symlink or just a normal file, that is owned > by another user. How's that supposed to work? To create it, he has to have write permissions in the destination directory; the same are required to delete it. > Like I said before, how about a justification as to the usefullness of this > behavior? I've already provided one annoying result of it. You haven't. The alternative behaviour would allow a user to create a symlink to a protected file, change the permissions on the link, and thus access the file. Lose lose lose. Think of symlinks as a redirection, not a second instance of the file (contrast hard links). > Nate Lawson -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Wed Feb 28 02:31:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA29503 for security-outgoing; Wed, 28 Feb 1996 02:31:49 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA29498 for ; Wed, 28 Feb 1996 02:31:47 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id CAA24156 for ; Wed, 28 Feb 1996 02:31:45 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id VAA17622; Wed, 28 Feb 1996 21:00:31 +1030 From: Michael Smith Message-Id: <199602281030.VAA17622@genesis.atrad.adelaide.edu.au> Subject: Re: Suspicious symlinks in /tmp To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 28 Feb 1996 21:00:30 +1030 (CST) Cc: nlawson@kdat.csc.calpoly.edu, newton@communica.com.au, security@freebsd.org In-Reply-To: <199602280805.SAA16934@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Feb 28, 96 06:35:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org Precedence: bulk Michael Smith stands accused of saying: > > Yes, but let's say Joe User tries out the ln -s command. Now he can't delete > > his symlink. This behavior is broken. A user should not be able to create > > any type of file, whether a symlink or just a normal file, that is owned > > by another user. > > How's that supposed to work? To create it, he has to have write permissions > in the destination directory; the same are required to delete it. > Grrr. Sticky bit, brain fart. Sorry. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-security Wed Feb 28 04:42:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA05878 for security-outgoing; Wed, 28 Feb 1996 04:42:03 -0800 (PST) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA05867 for ; Wed, 28 Feb 1996 04:42:00 -0800 (PST) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Wed, 28 Feb 1996 06:42:12 -0600 Message-ID: Date: 28 Feb 1996 06:41:30 -0600 From: "Richard Wackerbarth" Subject: Re: strawman comments To: "freebsd-security@freefall.freebsd.org" , "Jonathan M. Bresler" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-security@FreeBSD.ORG Precedence: bulk On 2/27/96 at 5:52:46 PM Jonathan M. Bresler wrote: > i want to able to filter on both incoming > and outgoing interfaces. >if0 is accounting > this can be done using ip addresses (or ranges) but > specifying interfaces is easier, and it wont let me forget any (sub) > nets Here is my comtribution for the "thought pot" Let me point out that the "best" solution may be to have two filter languages. The external language can be compiled into rules that the kernel "executes". I think that there is good argument for being able to use either interface (particularly for firewall) and ip address (particularly for accounting) to specify a rule. I am concerned about the use of one set of integers to determine both the priority and the link between rules and the interfaces to which they apply. Editing such a scheme "on the fly" can be difficult, if not impossible. I think that a more auditable scheme is to have one filter set for incoming and one set for outgoing. Perhaps we should use a two stage filter. On input first apply the interface filter, then apply the common filter. On output, first apply the common filter, then apply the interface filter. Richard Wackerbarth rkw@dataplex.net Sent with a test-drive version of CTM PowerMail 1.0.6 From owner-freebsd-security Wed Feb 28 06:03:32 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA09990 for security-outgoing; Wed, 28 Feb 1996 06:03:32 -0800 (PST) Received: from zygaena.com (zygaena.com [206.148.80.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA09984 for ; Wed, 28 Feb 1996 06:03:26 -0800 (PST) From: ewb@zygaena.com Received: (from nobody@localhost) by zygaena.com (8.7.3/8.7.3) id JAA19750; Wed, 28 Feb 1996 09:03:20 -0500 (EST) X-Authentication-Warning: zygaena.com: nobody set sender to using -f Received: from lochsa.i.com(198.30.169.3) by zygaena.com via smap (V1.3) id sma019747; Wed Feb 28 09:03:16 1996 Received: (from ewb@localhost) by lochsa.i.com (8.7.3/8.7.3) id JAA05423; Wed, 28 Feb 1996 09:03:14 -0500 (EST) Date: Wed, 28 Feb 1996 09:03:14 -0500 (EST) Message-Id: <199602281403.JAA05423@lochsa.i.com> To: cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.org Subject: Re: Informing users of cracked passwords? Sender: owner-security@FreeBSD.org Precedence: bulk Cy Schubert wrote: >If a user trusts an account on another host and that host has been >hacked, you have to assume your host has been compromised as well. >You cannot assume otherwise because you have no evidence to the >contrary. Once a hacker has an account on a system you or your users >trust, it's just a matter of time before the hacker has root on your >system. This is a rather sweeping statement that I don't think is true in general. Certainly if there is root trust via /.rhosts and the hack has root on the trusted system then you're a goner. Otherwise, the hack simply has user level access - which I hope is not a *guarantee* that they can get root. Are you suggesting that root on every un*x (or FreeBSD?) system is inherently compromised by having untrusted users? If so, I hope that you are helping to plug the particular hole(s) that you know of! -- Will Brown ewb@zygaena.com Zygaena Network Services http://www.zygaena.com From owner-freebsd-security Wed Feb 28 06:05:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10178 for security-outgoing; Wed, 28 Feb 1996 06:05:49 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA10168 for ; Wed, 28 Feb 1996 06:05:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id GAA10468; Wed, 28 Feb 1996 06:05:24 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602281405.GAA10468@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Michael Smith cc: nlawson@kdat.csc.calpoly.edu (Nathan Lawson), newton@communica.com.au, security@FreeBSD.ORG Subject: Re: Suspicious symlinks in /tmp In-reply-to: Your message of "Wed, 28 Feb 96 18:35:36 +1030." <199602280805.SAA16934@genesis.atrad.adelaide.edu.au> Date: Wed, 28 Feb 96 06:05:23 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.ORG Precedence: bulk > Nathan Lawson stands accused of saying: > > > > > > So: Not only does it not matter who owns the symlink, it also doesn't > > > matter how it is chmod'ed. You can set its permissions to rwxrwxrwx > > > without making a spot of difference to the accessibility of the file > > > it's pointing at. > > > > Yes, but let's say Joe User tries out the ln -s command. Now he can't dele te > > his symlink. This behavior is broken. A user should not be able to create > > any type of file, whether a symlink or just a normal file, that is owned > > by another user. > > How's that supposed to work? To create it, he has to have write permissions > in the destination directory; the same are required to delete it. > > > Like I said before, how about a justification as to the usefullness of this > > behavior? I've already provided one annoying result of it. > > You haven't. The alternative behaviour would allow a user to create a symlin k > to a protected file, change the permissions on the link, and thus > access the file. Lose lose lose. It doesn't work that way. In every version of UNIX I've ever used the symlink's permissions are not referenced when the O/S decides to grant or deny permission to the file. The symlink is jist a pointer. > > Think of symlinks as a redirection, not a second instance of the file > (contrast hard links). > > > Nate Lawson > > -- > ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ > ]] Genesis Software genesis@atrad.adelaide.edu.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ > ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Feb 28 06:26:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA11004 for security-outgoing; Wed, 28 Feb 1996 06:26:20 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA10996 for ; Wed, 28 Feb 1996 06:26:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id GAA10572; Wed, 28 Feb 1996 06:18:32 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602281418.GAA10572@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Bruce Evans cc: roberto@keltia.freenix.fr, msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-reply-to: Your message of "Wed, 28 Feb 96 18:30:59 +1100." <199602280730.SAA31286@godzilla.zeta.org.au> Date: Wed, 28 Feb 96 06:18:31 -0800 X-Mts: smtp Sender: owner-security@freebsd.org Precedence: bulk > >> I think this is to conform to future POSIX standards. Many other things > >> involving symlinks changed in 4.4lite. See `man 7 symlink'. > > >davidg also said it was not to use an inode for the symlink itself so every > >symlink in 4.4BSD are fast symlinks (as it was possible to use in FreeBSD > >1.1.5.1). > > Fast/small symlinks use an inode but not a data block. Very fast/small > symlinks would use only a directory entry (or two). Then there would be > nowhere to store the uid etc. > > >It don't like our behaviour either. Highly counterintuitive and deadly for > >sticky directories too where a user can't remove a link he made. > > Very intuitive if you don't know about inodes :-). > > Bruce > Why not kernel config option??? Let the sysadmin decide whether he/she wishes to implement the feature or not. Of course this would require a somewhat significant change to the filesystem creating two types of symbolic link objects, one that would be defined in a directory entry and the other which would be defined in an inode. One which would give you better performance while the other better user friendliness. The reason you need to have both types defined is when a kernel reconfig is performed the type of symbolic link that is not defined in the kernel config would still be followed but not created. An FSCK option could be added to make all symbolic links on a filesystem consistent with the kernel definition. It's just a thought... Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Feb 28 06:37:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA11623 for security-outgoing; Wed, 28 Feb 1996 06:37:47 -0800 (PST) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA11501 for ; Wed, 28 Feb 1996 06:34:35 -0800 (PST) Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id QAA22946 for security@freebsd.org; Wed, 28 Feb 1996 16:32:21 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id MAA23809 for ; Wed, 28 Feb 1996 12:15:38 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id MAA01148 for security@freebsd.org; Wed, 28 Feb 1996 12:15:37 +0200 Received: from spider2.elvisti.kiev.ua (spider2.elvisti.kiev.ua [193.125.28.35]) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id FAA11658 for ; Wed, 28 Feb 1996 05:54:37 +0200 Received: from sivka.UUCP (uucp@localhost) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with UUCP id FAA16409 for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:51:04 +0200 Received: from kiae.UUCP (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id FAA05076 for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:00:56 +0200 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 28 Feb 96 05:30:52 +0300 Received: by kremvax.demos.su (uumail v3.2.2/D) for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:21:30 +0300 Received: by kremvax.demos.su (8.6.12/D) from relay5.UU.NET [192.48.96.15] for with ESMTP id FAA04246; Wed, 28 Feb 1996 05:21:29 +0300 Received: from miles.greatcircle.com by relay5.UU.NET with ESMTP id QQaeur23493; Tue, 27 Feb 1996 21:20:37 -0500 (EST) Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-951222-1) id CAA09762 for firewalls-outgoing; Tue, 27 Feb 1996 02:57:43 -0800 (PST) Received: from gatekeeper.origin-at.co.uk (gatekeeper.origin-at.co.uk [194.130.16.17]) by miles.greatcircle.com (8.7.1/Miles-951221-1) with SMTP id CAA09757 for ; Tue, 27 Feb 1996 02:57:31 -0800 (PST) Received: from mailhost (pc158.origin-at.co.uk [194.130.16.158]) by gatekeeper.origin-at.co.uk (8.6.12/8.6.12) with SMTP id KAA14152 for ; Tue, 27 Feb 1996 10:38:03 GMT Date: Tue, 27 Feb 1996 10:38:03 GMT Message-Id: <1.5.4b11.16.19960227104358.31171af0@gatekeeper> X-Sender: jlarmour@gatekeeper X-Mailer: Windows Eudora Light Version 1.5.4b11 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Jonathan Larmour Subject: Java security risk (bypassing firewalls) Sender: owner-security@FreeBSD.ORG Precedence: bulk I picked this up from a friend. Its totally plausible and seems to affect anyone using Java behind a firewall. Any ideas on how to deal with it (apart from disallowing files with .cla or .class extensions at the proxy level)? The most I've done is recompile my bind with -DSUNSECURITY which should (hopefully) log any times when the reverse mapping does not match the name->IP mapping. Although, I'm not entirely sure that will help either. So, any ideas? >Date: Sun, 18 Feb 1996 23:57:02 -0500 >From: Drew Dean >Subject: Java security problems > >We have discovered a serious security problem with Netscape Navigator's 2.0 >Java implementation. (The problem is also present in the 1.0 release of the >Java Development Kit from Sun.) An applet is normally allowed to connect >only to the host from which it was loaded. However, this restriction is not >properly enforced. A malicious applet can open a connection to an arbitrary >host on the Internet. At this point, bugs in any TCP/IP-based network >service can be exploited. We have implemented (as a proof of concept) an >exploitation of an old sendmail bug. > >If the user viewing the applet is behind a firewall, this attack can >be used against any other machine behind the same firewall. The >firewall will fail to defend against attacks on internal networks, >because the attack originates behind the firewall. > >The immediate fix for this problem is to disable Java from Netscape's >"Security Preferences" dialog. An HTTP proxy server could also >disable Java applets by refusing to fetch Java ".class" files. We've >sent a more detailed description of this bug to CERT, Sun, and >Netscape. > >A second, also serious, bug exists in javap, the bytecode >disassembler. An overly long method name can overflow a stack >allocated buffer, potentially causing arbitrary native code to be >executed. The problem is an unchecked sprintf() call, just like the >syslog(3) problem last year. Many such bugs were in the alpha 3 >release's runtime, but were carefully fixed in the beta release. The >disassembler bug apparently slipped through. This attack only works >on users who disassemble applets. The fix is to not run javap until >Sun releases a patch. > >Note that we've only had success in exploiting the first flaw on an SGI. >Windows 95 and DEC Alpha versions of Netscape have other bugs in their >socket implementations that make it harder (although not necessarily >impossible) to exploit the problem. This is the second time that unrelated >implementation bugs have prevented us from demonstrating security problems >in Java. > >http://www.cs.princeton.edu/~ddean/java will contain more information >soon, including a revised version of our paper, to appear in the 1996 >IEEE Symposium on Security and Privacy. > >Drew Dean >Ed Felten >Dan Wallach > Department of Computer Science, Princeton University > >For more information, please contact Ed Felten, 609-258-5906, FAX >609-258-1771. 323 Cambridge Science Park, Origin UK, Cambridge, England. CB4 4WG. Tel: +44 (1223)-423355 Fax: +44 (1223)-420724 E-mail: guess... Disclaimer: This is not a disclaimer From owner-freebsd-security Wed Feb 28 07:03:44 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA12886 for security-outgoing; Wed, 28 Feb 1996 07:03:44 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA12881 for ; Wed, 28 Feb 1996 07:03:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id HAA10286; Wed, 28 Feb 1996 07:03:17 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602281503.HAA10286@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: ewb@zygaena.com cc: cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.org Subject: Re: Informing users of cracked passwords? In-reply-to: Your message of "Wed, 28 Feb 96 09:03:14 EST." <199602281403.JAA05423@lochsa.i.com> Date: Wed, 28 Feb 96 07:03:16 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk > Cy Schubert wrote: > >If a user trusts an account on another host and that host has been > >hacked, you have to assume your host has been compromised as well. > >You cannot assume otherwise because you have no evidence to the > >contrary. Once a hacker has an account on a system you or your users > >trust, it's just a matter of time before the hacker has root on your > >system. > > This is a rather sweeping statement that I don't think is true > in general. Certainly if there is root trust via /.rhosts > and the hack has root on the trusted system then you're a goner. > Otherwise, the hack simply has user level access - which I hope > is not a *guarantee* that they can get root. > > Are you suggesting that root on every un*x (or FreeBSD?) system is > inherently compromised by having untrusted users? If you take the point of view that auditors do, yes. That is why any host with .rhosts or hosts.equiv files ususally get poor audit reports. It is only a matter of time that a hacker can break gain root. If you're running SunOS 4.x (a SunOS 4.x system can be broken with two shell commands), elm, pine, or an improperly configured httpd, and the list goes on, your system is at risk. That's not to say a an absolute guarantee but at risk. If another system in your shop or a system that you or your users trust has been compromised that risk goes up. The key is that if a site that you or your users trust has been hacked, you must _CONSIDER_ your site compromised (at least user level) until you can prove it hasn't been. Otherwise you may be hacked and assume your not. Call me paranoid. On the other hand, in a government shop, like the one I work at, even a non-privileged user can do a lot of "political" damage. > > If so, I hope that you are helping to plug the particular hole(s) > that you know of! Of that you can be sure of! That is one of the reasons I and my clients have switched from Linux to FreeBSD. Under Linux it was a losing battle. Of the two broad classes of "free" UNIX the *BSD variants do a better job of security, even better than many commercial variants of UNIX I've worked on. > > -- > Will Brown ewb@zygaena.com > Zygaena Network Services http://www.zygaena.com Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Feb 28 07:14:23 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA13632 for security-outgoing; Wed, 28 Feb 1996 07:14:23 -0800 (PST) Received: from zip.io.org (root@zip.io.org [198.133.36.80]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA13626 for ; Wed, 28 Feb 1996 07:14:20 -0800 (PST) Received: (from taob@localhost) by zip.io.org (8.6.12/8.6.12) id KAA06598; Wed, 28 Feb 1996 10:13:13 -0500 Date: Wed, 28 Feb 1996 10:13:13 -0500 (EST) From: Brian Tao To: Ollivier Robert cc: Denis Fortin , cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.ORG Subject: Re: Informing users of cracked passwords? In-Reply-To: <199602272259.XAA01043@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk On Tue, 27 Feb 1996, Ollivier Robert wrote: > > > But anyway, I'd rather have people use telnet... I've always found the > > "r" commands to be too magical for my taste :-) > > The answer is called SSH. You need ssh running at both ends, don't you? -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-security Wed Feb 28 14:47:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23113 for security-outgoing; Wed, 28 Feb 1996 14:47:28 -0800 (PST) Received: from alpha.dsu.edu (ghelmer@[138.247.32.12]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA23102 for ; Wed, 28 Feb 1996 14:47:24 -0800 (PST) Received: (from ghelmer@localhost) by alpha.dsu.edu (8.7.4/8.7.3) id QAA29383; Wed, 28 Feb 1996 16:47:16 -0600 (CST) Date: Wed, 28 Feb 1996 16:47:16 -0600 (CST) From: Guy Helmer To: freebsd-security@freebsd.org Subject: Re: Kerberos Insecurities (COAST Announcement) In-Reply-To: <199602180722.JAA16952@grumble.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Sun, 18 Feb 1996, Mark Murray wrote: > Paul Danckaert wrote: > > Does anybody know if this effects the ebones-based kerberos package? If > > so, is there any info on a bug-fix? > > Too early to tell. We are eagerly awaiting the follow-up. Has anyone tried merging MIT's patches into the eBones kerberos? A cursory examination of the eBones kerberos.c indicates that it doesn't use des_new_random_key & friends... Guy Helmer, Dakota State University Computing Services - ghelmer@alpha.dsu.edu From owner-freebsd-security Wed Feb 28 18:52:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12512 for security-outgoing; Wed, 28 Feb 1996 18:52:47 -0800 (PST) Received: from soli.inav.net (root@[199.120.107.103]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12505 for ; Wed, 28 Feb 1996 18:52:45 -0800 (PST) Received: from deanstoy (dip41.inav.net [199.120.107.231]) by soli.inav.net (8.6.12/8.6.12) with ESMTP id UAA07204 for ; Wed, 28 Feb 1996 20:52:30 -0600 Received: (from dean@localhost) by deanstoy (8.6.12/8.6.9) id UAA00458 for freebsd-security@freebsd.org; Wed, 28 Feb 1996 20:51:05 -0600 Date: Wed, 28 Feb 1996 20:51:05 -0600 From: "Dean M. Phillips" Message-Id: <199602290251.UAA00458@deanstoy> To: freebsd-security@freebsd.org Subject: eBones appears free of PRNG bug. Sender: owner-security@freebsd.org Precedence: bulk I have done a quick check of the eBones that is shipped with FreeBSD 2.1R and it appears to have already been fixed. In /usr/src/eBones/include/des.h there is a "#define random_key des_random_key". The random_key function appears to have vanished from the sources. All the usual disclaimers apply :-) Dean M. Phillips _________________________________________________________________________ Dean M. Phillips PGP mail encouraged dphill@inav.net Office: 319-373-9825 Home: 319-373-9825 PGP key on server, ID: 2CE87FB5 From owner-freebsd-security Wed Feb 28 22:42:52 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA05835 for security-outgoing; Wed, 28 Feb 1996 22:42:52 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA05809 for ; Wed, 28 Feb 1996 22:42:39 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA04328 ; Thu, 29 Feb 1996 07:42:32 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA14916 ; Thu, 29 Feb 1996 07:42:29 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id BAA05542; Thu, 29 Feb 1996 01:31:10 +0100 (MET) From: Ollivier Robert Message-Id: <199602290031.BAA05542@keltia.freenix.fr> Subject: Re: Informing users of cracked passwords? To: taob@io.org (Brian Tao) Date: Thu, 29 Feb 1996 01:31:09 +0100 (MET) Cc: fortin@zap.qc.ca, cschuber@orca.gov.bc.ca, freebsd-security@FreeBSD.ORG In-Reply-To: from Brian Tao at "Feb 28, 96 10:13:13 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG Precedence: bulk It seems that Brian Tao said: > > The answer is called SSH. > > You need ssh running at both ends, don't you? Yes as it does use another entirely different protocol. But it can replace entirely rsh/rlogin/rsp. The X11 support is one of the primary features. It is even compatible in terms of IP filters if you use RSA/Rhosts authentication (port used downward from 1023) with rsh/rlogin. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-security Thu Feb 29 08:01:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA19228 for security-outgoing; Thu, 29 Feb 1996 08:01:47 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA19220 for ; Thu, 29 Feb 1996 08:01:35 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id SAA04923; Thu, 29 Feb 1996 18:01:04 +0200 (SAT) Message-Id: <199602291601.SAA04923@grumble.grondar.za> To: Guy Helmer cc: freebsd-security@freebsd.org Subject: Re: Kerberos Insecurities (COAST Announcement) Date: Thu, 29 Feb 1996 18:01:03 +0200 From: Mark Murray Sender: owner-security@freebsd.org Precedence: bulk Guy Helmer wrote: > On Sun, 18 Feb 1996, Mark Murray wrote: > > Paul Danckaert wrote: > > > Does anybody know if this effects the ebones-based kerberos package? If > > > so, is there any info on a bug-fix? > > > > Too early to tell. We are eagerly awaiting the follow-up. > > Has anyone tried merging MIT's patches into the eBones kerberos? A > cursory examination of the eBones kerberos.c indicates that it doesn't > use des_new_random_key & friends... Its in CURRENT, not yet in STABLE. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Thu Feb 29 08:05:40 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA19451 for security-outgoing; Thu, 29 Feb 1996 08:05:40 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA19443 for ; Thu, 29 Feb 1996 08:05:32 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id SAA04943; Thu, 29 Feb 1996 18:04:37 +0200 (SAT) Message-Id: <199602291604.SAA04943@grumble.grondar.za> To: "Dean M. Phillips" cc: freebsd-security@freebsd.org Subject: Re: eBones appears free of PRNG bug. Date: Thu, 29 Feb 1996 18:04:36 +0200 From: Mark Murray Sender: owner-security@freebsd.org Precedence: bulk "Dean M. Phillips" wrote: > I have done a quick check of the eBones that is shipped with FreeBSD 2.1R > and it appears to have already been fixed. In /usr/src/eBones/include/des.h > there is a "#define random_key des_random_key". The random_key function > appears to have vanished from the sources. Close. No Cigar. The routine required is des_new_random_key(). This was added to our libdes by me a while back, and is a part of the new libdes. Andrey (ache) added the MIT fixes to eBones, but it is not yet in STABLE. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-security Thu Feb 29 14:11:43 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14185 for security-outgoing; Thu, 29 Feb 1996 14:11:43 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA14178 for ; Thu, 29 Feb 1996 14:11:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id OAA04629; Thu, 29 Feb 1996 14:09:48 -0800 (PST) To: Joe Greco cc: phk@critter.tfs.com (Poul-Henning Kamp), fenner@parc.xerox.com, nate@sri.MT.net, security@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Thu, 29 Feb 1996 14:16:15 CST." <199602292016.OAA06433@brasil.moneng.mei.com> Date: Thu, 29 Feb 1996 14:09:48 -0800 Message-ID: <4627.825631788@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk > Okay, firewall debaters. Here's what I've done on gateway.inr.sol.net. Who still REFUSE to take this flippin' discussion to security. Guys? Please? I'm begging! I don't FREAKIN' CARE ABOUT FIREWALLS! This is a security issue and it belongs on the security mailing list, where people that genuinely care will read it. I've already complained bitterly once, after the last 30-round flamefest, and it doesn't seem to have had any effect. SIGH. Jordan From owner-freebsd-security Fri Mar 1 02:04:09 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA01393 for security-outgoing; Fri, 1 Mar 1996 02:04:09 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA01386 for ; Fri, 1 Mar 1996 02:04:06 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsRgV-0003vrC; Fri, 1 Mar 96 02:03 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id LAA02153; Fri, 1 Mar 1996 11:03:32 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Darren Reed cc: security@FreeBSD.ORG Subject: Re: IP filtering strawman, comments please. In-reply-to: Your message of "Thu, 29 Feb 1996 12:02:58 +1100." <199602290101.RAA02493@freefall.freebsd.org> Date: Fri, 01 Mar 1996 11:03:29 +0100 Message-ID: <2151.825674609@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@FreeBSD.ORG Precedence: bulk > I was passed this e-mail and asked to comment, which I don't mind doing, > so long as someone will listen. Don't worry, I will :-) > This can (only) reliably come from looking at the MAC address and will need > to be done in the driver, somewhere. ie if_ether.c and if_ppp.c (not if_ed.c , > etc). Yes, it is a problem, but a check for IP level broadcase is better than no check for broadcast. > If this is a requirement, then the current ipfw structure needs to be > totally scrapped and something using BPF implemented. Having looked into > this already, I'd suggest that a filter list would then be a set of BPF > programs, with filter return statuses used bsed on what BPF thinks. > There are some problems with this, however... Yes, I have been looking at this, and I should be possible to add a the possiblity of specifying a BPF-code filter as well. These will be too much slower than the regular ones, so they should only be used for "weird" things. > Have you considered what this does for management of packet filtering ? yes, carefully even. > The complexity is increased too much, I fear. If I want to delete a rule, > how many times do I have to delete it if it is referenced by several > interfaces/control points ? My idea is that unless you tell it to apply a rule at a certain point, it will be installed at the points needed for it to appear as a "global" rule. (A,B,C in the draft. If you delete a rule by lineno, it will be gone from all points of application. If you delete it by lineno+filter-point, it will only disappear from there. That means that the normal case will look just like now. > The main problem I see with this is: how easily can I view a complete list of > rules that can possibly effect the packet and what do I have to do to verify > that my access list rules are doing what I want ? I imagined that you could view the matrix like the example in the strawman, but this is clearly a point that needs some work. > Filtering packets being "routed onwards" is a dubious distinction from those > being sent as output, IMHO. No, you need to be able to do that if you want to use the "divert" action to examine a packet, also, it will make proxys easier, for instance a mandatory web-proxy can be made that way. > The only reason I'd be thinking about making changes like this would be for > performance reasons. In testing IP Filter, I've noticed very little > degradation on a P-100 with 1 or 100 rules for ftp across my own ethernet. There are a lot of things that are needlessly hard to express in the current setup. Having the option of multiple filter-points will make these easier to express. If you just want "one filter, one place: all over the place", then you should hopefully find that to be the default :-) > The correctness of the implementation also becomes harder to prove, requiring > bits of the kernel to be used in testing. Currently, you could take the > engine from ipfw and build a userland progam around it (I hope!) which could > trivially test any/all packets. Firewalls are hard to get right. > The problem of how to "log" packets is a side effect of how it is currently > being done: either via log() or printf()/kprintf(). This is better solved > by fixing the way interaction is done with the in-kernel filtering. exactly. Havn't really got a good idea for it yet. > On a separate note, prior to 2.1.0 release, a few people from > freebsd-security asked about incorporating IP Filter. The reason given then > for not including it (accounting) has since been fixed; > URL: http://coombs.anu.edu.au/~avalon/ip-filter.html wasn't there some copyright thing also ? > I guess what you end up doing depends upon what your goals and aims are. and what gives the most mileage and the fewest problems... > What problems are you trying to address (and solve) with your strawman ? I'm trying to make it easier to setup complext firewalls, without making it harder to set up simple ones. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Fri Mar 1 02:10:31 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA01706 for security-outgoing; Fri, 1 Mar 1996 02:10:31 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA01701 for ; Fri, 1 Mar 1996 02:10:28 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsRn5-0003vrC; Fri, 1 Mar 96 02:10 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id LAA02185; Fri, 1 Mar 1996 11:10:21 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Archie Cobbs cc: security@freebsd.org Subject: Re: IP filtering strawman, comments please. In-reply-to: Your message of "Thu, 29 Feb 1996 18:18:30." <199603010218.SAA05571@bubba.tribe.com> Date: Fri, 01 Mar 1996 11:10:18 +0100 Message-ID: <2183.825675018@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org Precedence: bulk > > And finally, what should be done when the rule matches: > > > Howabout: > > "remap X" Change the (source/dest) network number to X from whatever > it was. This would provide very easy network address translation > in the case that the two netmask widths are identical. This could > be a big feature if people have to start renumbering their > networks but aren't ready yet... cf. rfc1900. > > The more general case (such as remapping an entire network > into a single IP address) is slightly harder, since you have > to remember what UDP/TCP ports you have mapped to as well, > time them out, sniff FTP packets, etc... but it can and has > been done... I would rather leave this to a user-land process by using the divert trick. I'm trying to get maximum mileage from the minimum kernel-code. The kernel-code needs to be audited very very carefully, so I don't want to bloat it with little used functionality, that could just as well be done in user-land. > "divert" would be great for security auditing purposes. and other things too. remember that packet can be reinjected after being chewed on. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Fri Mar 1 04:28:28 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA08520 for security-outgoing; Fri, 1 Mar 1996 04:28:28 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA08505 for ; Fri, 1 Mar 1996 04:28:23 -0800 (PST) Message-Id: <199603011228.EAA08505@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA018713388; Fri, 1 Mar 1996 23:29:48 +1100 From: Darren Reed Subject: Re: IP filtering strawman, comments please. To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 1 Mar 1996 23:29:48 +1100 (EDT) Cc: security@FreeBSD.ORG In-Reply-To: <2151.825674609@critter.tfs.com> from "Poul-Henning Kamp" at Mar 1, 96 11:03:29 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@FreeBSD.ORG Precedence: bulk In some mail from Poul-Henning Kamp, sie said: [...] > Yes, it is a problem, but a check for IP level broadcase is better than > no check for broadcast. That is a degenerate case of ip#/mask, where the IP# is the broadcast address and the mask is 255.255.255.255, ie not an issue worth considering. [...] > Yes, I have been looking at this, and I should be possible to add a > the possiblity of specifying a BPF-code filter as well. These will > be too much slower than the regular ones, so they should only be > used for "weird" things. Define `much'. I think you should look at both the BPF code and the ip_firewall.c code. Then look at performance results from PathFinder. Besides which, there is work in progress to improve BPF, but don't hold your breath waiting. What about the overhead from invoking filtering not just once, or twice in the packets life in the kernel, but half a dozen times ? In designing IP Filter, I gave careful consideration to pipelining CPU's and can remove a large number of branches from the code in the early stages of filtering, if need be (hmmm, this should be a compile time option, perhaps). This is just an example of keeping in mind the target system as well as overall speed. [...] > My idea is that unless you tell it to apply a rule at a certain point, > it will be installed at the points needed for it to appear as a "global" > rule. (A,B,C in the draft. Is this intuitive ? Have you looked at some of the packages available today, what they provide in terms of flexibility and managability (commercial & non) ? > > Filtering packets being "routed onwards" is a dubious distinction from > > those being sent as output, IMHO. > No, you need to be able to do that if you want to use the "divert" action > to examine a packet, also, it will make proxys easier, for instance a > mandatory web-proxy can be made that way. No, you don't. A packet being output is a packet being output. Whether it is being diverted, routed, generated, whatever, it is still being output. You can pretend to know how it got into the kernel, and how it was generated. To give you an idea of how this is not a problem, the structure of IP Filter is something like this: input-->[NAT]-->[fragment|state]-->[filter]-->[kernel] \------>----/ [kernel]-->[NAT]-->[fragment|state]-->[filter]-->output \------>----/ Where a fragment/state cache/table is kept and matching packets skip the filter (which can add items to the aforementioned cache/table). Even this is getting more complex than I am (almost) comfortable with. The basis I've used is, if it stays simple, the code will be simple, and simple code is always fast :-) It should also be easier to verify, etc. btw, doing transparent proxying is _not_ as simple as you might think. The obvious solution (redirect packts to *.www to localhost.www) breaks TCP connections being 1:1. [...] > There are a lot of things that are needlessly hard to express in the current > setup. Having the option of multiple filter-points will make these easier > to express. If you just want "one filter, one place: all over the place", > then you should hopefully find that to be the default :-) Examples of things which are hard to express ? Are they hard to express because of the interface tool or the engine ? I think you overestimate the multiple filter-point gain. [...] > Firewalls are hard to get right. There are two very good books and a number of papers on them. They don't have to be hard to get right, any more. > > The problem of how to "log" packets is a side effect of how it is currently > > being done: either via log() or printf()/kprintf(). This is better solved > > by fixing the way interaction is done with the in-kernel filtering. > exactly. Havn't really got a good idea for it yet. Suggestion: managing filters through setsockopt()'s is _stupid_ if you're not implementing it for a new protocol/socket type. I've thought about doing it this way and would probably do it via recv() on this socket. > > On a separate note, prior to 2.1.0 release, a few people from > > freebsd-security asked about incorporating IP Filter. The reason given then > > for not including it (accounting) has since been fixed; > > URL: http://coombs.anu.edu.au/~avalon/ip-filter.html > > wasn't there some copyright thing also ? That disappeared some time ago. > > What problems are you trying to address (and solve) with your strawman ? > I'm trying to make it easier to setup complext firewalls, without making > it harder to set up simple ones. Complex firewalls == complex code... On a separate note, you could totally rework the internal packet delivery for each protocol (ie kill off protosw and pcblists/tables) and do it all with filtering. See PathFinder (OSDI a year or two ago). darren From owner-freebsd-security Fri Mar 1 04:38:18 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA09167 for security-outgoing; Fri, 1 Mar 1996 04:38:18 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA09162 for ; Fri, 1 Mar 1996 04:38:13 -0800 (PST) Message-Id: <199603011238.EAA09162@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA020833822; Fri, 1 Mar 1996 23:37:03 +1100 From: Darren Reed Subject: Re: IP filtering strawman, comments please. To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 1 Mar 1996 23:37:02 +1100 (EDT) Cc: archie@tribe.com, security@freebsd.org In-Reply-To: <2183.825675018@critter.tfs.com> from "Poul-Henning Kamp" at Mar 1, 96 11:10:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-security@freebsd.org Precedence: bulk In some mail from Poul-Henning Kamp, sie said: > > > > And finally, what should be done when the rule matches: > > > > > Howabout: > > > > "remap X" Change the (source/dest) network number to X from whatever > > it was. This would provide very easy network address translation > > in the case that the two netmask widths are identical. This could > > be a big feature if people have to start renumbering their > > networks but aren't ready yet... cf. rfc1900. > > > > The more general case (such as remapping an entire network > > into a single IP address) is slightly harder, since you have > > to remember what UDP/TCP ports you have mapped to as well, > > time them out, sniff FTP packets, etc... but it can and has > > been done... > I would rather leave this to a user-land process by using the divert > trick. I'm trying to get maximum mileage from the minimum kernel-code. [...] > > "divert" would be great for security auditing purposes. > and other things too. remember that packet can be reinjected after > being chewed on. "remap" and "divert" are two sides of the same coin. Doing things in userland is nice/safe, BUT (big BUT), there is a significant performance hit. darren