From owner-freebsd-security Sun Dec 3 00:41:45 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04340 for security-outgoing; Sun, 3 Dec 1995 00:41:45 -0800 Received: from onyx.southwind.net (root@onyx.southwind.net [204.95.83.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04335 for ; Sun, 3 Dec 1995 00:41:41 -0800 Received: (from Ucomplet@localhost) by onyx.southwind.net (8.6.12/8.6.12) with UUCP id CAA13195; Sun, 3 Dec 1995 02:25:10 -0600 Received: (from jgoerzen@localhost) by complete.org (8.7.2/8.7.2) id WAA04835; Sat, 2 Dec 1995 22:12:06 -0600 (CST) Date: Sat, 2 Dec 1995 22:12:05 -0600 (CST) From: John Goerzen To: "Jordan K. Hubbard" cc: Robert Du Gaue , Robert Watson , Michael Smith , security@freebsd.org Subject: Re: ****HELP***** In-Reply-To: <4271.817941603@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk Unfortunately, only the easiest files to configure are setup by the novice config option. Things such as UUCP, sendmail, INN, etc -- the programs that can take hours or days to properly configure -- are not handled by the novice config. It would be better if the installer would just: 1) Overwrite older versions of programs with the newer versions 2) Delete any obsoleted programs (and preferably make symlinks to the newer ones) 3) Add new files to existing system John Goerzen, programmer and owner | MICRO$oft only exists because some Communications Centre & Complete BBS | people are too dumb to get something E-mail jgoerzen@complete.org | better, such as FreeBSD. On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > I plan on rebuilding a new system from scratch, then I'll wipe all the > > bin directories clena on the compromised systems and use the rebuilt > > system to update all the bins. Which should I do? > > > > Erm. In this instance, you might be better off simply backing up the > files you want to *keep* and then reinstalling the entire system from > the 2.1 distribution. 2.1's installer isn't bad, and it's possible > to get back a lot of the configuration data just through answering > questions in the novice install. > > Jordan > > > > /bin /sbin /usr/sbin /usr/bin Where else? I know there are alot I'm > > missing... > > > > > > On Sat, 2 Dec 1995, Robert Watson wrote: > > > > > Date: Sat, 2 Dec 1995 13:14:42 -0500 (EST) > > > From: Robert Watson > > > To: "Jordan K. Hubbard" > > > Cc: Michael Smith , > > > Robert Du Gaue , security@FreeBSD.ORG > > > Subject: Re: ****HELP***** > > > > > > > > > Actually, what might be nice is to include the MD5's with the system, and > > > have a script in daily.local that verifies that the key system binaries > > > are correct. Obviously then the md5 file would be at risk, but.. This > > > would also be nice, unrelated to the daily part, after an upgrade to > > > check if there are any old binaries lying around. > > > > > > Actually, one thing I was going to ask about was -- is there a difference > > > between the 2.1.0 binaries for standard executables (eg., pine) and the > > > 2.0.5 ones? Is there anyway I can use strings (or something) to get a > > > list of all the old binaries on my system and upgrade them if needed? > > > > > > On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > > > > > > > Jordan; how hard would it be to generate a file with the md5's of a sto > ck > > > > > release system's "standard binaries" for this sort of thing? > > > > > > > > Probably not too hard. Let me think about it. You'd want a file > > > > for each distrib, probably. > > > > > > > > Jordan > > > > > From owner-freebsd-security Sun Dec 3 00:49:42 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04828 for security-outgoing; Sun, 3 Dec 1995 00:49:42 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04820 for ; Sun, 3 Dec 1995 00:49:36 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA00823; Sun, 3 Dec 1995 00:48:59 -0800 To: John Goerzen cc: Robert Du Gaue , Robert Watson , Michael Smith , security@freebsd.org Subject: Re: ****HELP***** In-reply-to: Your message of "Sat, 02 Dec 1995 22:12:05 CST." Date: Sun, 03 Dec 1995 00:48:58 -0800 Message-ID: <821.817980538@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk > It would be better if the installer would just: > 1) Overwrite older versions of programs with the newer versions > 2) Delete any obsoleted programs (and preferably make symlinks to the > newer ones) > 3) Add new files to existing system Unfortunately, the raw materials that the installer has to work with (distributions) aren't nearly that easily applicable to the more general problem you'd like me to solve. Only a filestore that allows me to do file by file operations will allow for this kind of intelligent merge. A split, gzip'd tar file is not that kind of filestore. I'm happy, as always, to accept contributions of code that help solve these problems! :-) Jordan From owner-freebsd-security Mon Dec 4 00:43:35 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09912 for security-outgoing; Mon, 4 Dec 1995 00:43:35 -0800 Received: from onyx.southwind.net (root@onyx.southwind.net [204.95.83.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA09901 for ; Mon, 4 Dec 1995 00:43:30 -0800 Received: (from Ucomplet@localhost) by onyx.southwind.net (8.6.12/8.6.12) with UUCP id CAA01893; Mon, 4 Dec 1995 02:25:06 -0600 Received: from complete.org (complete.org [127.0.0.1]) by complete.org (8.7.2/8.7.2) with SMTP id BAA00543; Mon, 4 Dec 1995 01:46:05 -0600 (CST) Message-Id: <199512040746.BAA00543@complete.org> X-Authentication-Warning: complete.org: Host complete.org [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.4 10/10/95 To: "Jordan K. Hubbard" cc: Robert Du Gaue , Robert Watson , Michael Smith , security@freebsd.org Subject: Re: ****HELP***** In-reply-to: Your message of "Sun, 03 Dec 1995 00:48:58 PST." <821.817980538@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 1995 01:46:02 -0600 From: John Goerzen Sender: owner-security@freebsd.org Precedence: bulk > > It would be better if the installer would just: > > 1) Overwrite older versions of programs with the newer versions > > 2) Delete any obsoleted programs (and preferably make symlinks to the > > newer ones) > > 3) Add new files to existing system > > Unfortunately, the raw materials that the installer has to work with > (distributions) aren't nearly that easily applicable to the more > general problem you'd like me to solve. Only a filestore that allows > me to do file by file operations will allow for this kind of > intelligent merge. A split, gzip'd tar file is not that kind of > filestore. I'm not very much of a Unix expert at all, but it seems to me that problem #1 could easily be solved (the know binaries simply overwrite the old ones -- assuming the have the same name, as most do). #3 also, it just extracts the tar.gz'd files, no problem there. #2 is a different story. Probably all it would take, though, is a list of files to be deleted if exist. One filename per line, and a simple program to delete it. I'd be willing to write such a program if necessary. Perhaps a checksum or something would be good as well.... > > I'm happy, as always, to accept contributions of code that help > solve these problems! :-) Let me know on #2 via e-mail (not on this list) if you want me to throw together a C program.... -- John Goerzen, programmer and owner | MICRO$oft only exists because some Communications Centre & Complete BBS | people are too dumb to get something E-mail jgoerzen@complete.org | better, such as FreeBSD. From owner-freebsd-security Mon Dec 4 07:13:07 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07235 for security-outgoing; Mon, 4 Dec 1995 07:13:07 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA07229 for ; Mon, 4 Dec 1995 07:13:03 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA17682; Mon, 4 Dec 1995 10:12:49 -0500 Date: Mon, 4 Dec 1995 10:12:49 -0500 From: "Garrett A. Wollman" Message-Id: <9512041512.AA17682@halloran-eldar.lcs.mit.edu> To: Michael Smith Cc: security@FreeBSD.ORG Subject: Re: ****HELP***** In-Reply-To: <199512021909.TAA21321@genesis.atrad.adelaide.edu.au> References: <199512021909.TAA21321@genesis.atrad.adelaide.edu.au> Sender: owner-security@FreeBSD.ORG Precedence: bulk < said: > Jordan; how hard would it be to generate a file with the md5's of a stock > release system's "standard binaries" for this sort of thing? It would be incredibly easy; I have done so for the distributions that I have put together, and it's a three-line change to release/Makefile. -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 Dec 4 11:08:39 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24002 for security-outgoing; Mon, 4 Dec 1995 11:08:39 -0800 Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA23968 for ; Mon, 4 Dec 1995 11:07:06 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id VAA24417 for security@freebsd.org; Mon, 4 Dec 1995 21:06:31 +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 TAA02461 for ; Mon, 4 Dec 1995 19:45:31 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id TAA14138 for security@freebsd.org; Mon, 4 Dec 1995 19:45:29 +0200 From: "Andrew V. Stesin" Message-Id: <199512041745.TAA14138@office.elvisti.kiev.ua> Subject: port scanning. (fwd) To: security@freebsd.org Date: Mon, 4 Dec 1995 19:45:29 +0200 (EET) X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 5269 Sender: owner-security@freebsd.org Precedence: bulk Forwarded message: >From <@relay1.carrier.kiev.ua:kiae!demos!kremvax.demos.su!GreatCircle.COM!firewalls-owner> Mon Dec 4 17:09:42 1995 Message-Id: <199512041259.EAA21992@miles.greatcircle.com> From: Darren Reed Subject: port scanning. To: Firewalls@GreatCircle.COM (Firewalls Mailing List) Date: Tue, 5 Dec 1995 00:00:27 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: firewalls-owner@GreatCircle.COM Precedence: bulk (hopefully this is far enough from being an actual exploit to be suitable for the firewalls list. Whilst not directly relevant to firewalls, I believe some of the details herein will be of interest to its readers). "Stealth Scanning": etcp Well since newscan is available, I don't see too much harm in making this tool available (I was unaware that it existed, previously). There are "bugs" here for everyone...:-(( Hassle your vendor if you find your machines susceptible to some of the stranger things below. This document describes the behaviour of etcp and thus explains to a fair extent how Stealth Scanning works, how to take advantage of buggy firewalls which don't send back replies and points out some bugs in TCP. etcp is the precursor to ipsend (which has diverged from the role of doing TCP port scans). It ONLY works over Ethernet. It's primary role was to exercise the short-TCP packet bug, but became a bit more flexible. It will ONLY run on SunOS4 (NIT or BPF) and 4BSD boxes with BPF. The command line looks something like this: etcp [-d device] [-f fragflags] [-g gateway] [-m mtu] [-p min] [-P max] [-s src] [-S source-port] [-t port] dest flags Device is obvious (which device you want the packet to go out from). (defaults to le0) The "fragflags" field is there to niggle another bug observed in packet filters (mainly setting the highest bit -ONLY- and sending a packet with this field as 0x8000, even though it wasn't a fragment). The gateway allows it to send packets through to another network. The mtu paramter. This did "most of the damage". The key value for this field is 28 - enough to put port numbers in one packet and TCP flags in the next. The min and max parameters specify the minimum and maximum ports for the scan. Default is 0 and 1023. Source allows for a different source address to be specified - almost useless unless you don't want to see the replies. Source port sets the given field in the TCP header. If the port number is given, with the -t option, it will try to make a TCP connection and then send data across without using in-kernel TCP. This option work best with an MTU of 28 against a packet screen'd firewall which doesn't return any ICMP/TCP packets in response to blocked packets. Why ? Because it relies on the screen remaining silent and not giving the kernel any cause to close the TCP connection. So, if that bug was available, it'd call connect(), expect the SYN packet to be dropped, send across a SYN split in two which would hopefully make it through, assume an answer, and then send across an ACK (using a system call) with actual data, doing a kernel lookup to get the sequence/ack numbers from the TCP PCB. Sometimes not sending a reply is more dangerous than sending one :-) Destination is the destination IP address. Flags is any combination of TCP flags (SAFRPU). This table shows the packets returned to those sent. The target machines were an Ultrix 4.3 box and a FreeBSD 2.0.5 box. Hopefully two different `poles' of BSD TCP. L - Listening, I - Inuse, U - unused S - SYN, A - ACK, F - FIN, R - RST All packets should be considered to have bad sequence/ack numbers. Sent State Received Window* S L SA !=0 S I - - S U RA 0 SA L RA/R# !=0 SA I A/- !=0/-# SA U R 0 F L A/- !=0/- F I - - F U RA/R 0 FA L R/- !=0/- FA I A/- !=0/- FA U RA 0 FS L RA/SA !=0 & FS I - - FS U RA 0 R L R/- !=0/- R I RA/- !=0/- + R U - - RA L RA/- !=0/- RA I RA !=0 + RA U - - * - on Solaris 2, RST packets always have a window of 0. + - On some Unixes, where a reply is shown as received, this can close the connection a la ICMP destination unreachable `nukes' - hassle vendor! # - FreeBSD 2.0.5 reponses, where different & - it appears that 4.4BSD treats FS as a S. When kernels based on BSD networking are targetted, a non-zero window is returned for sockets which are listening. This is due to them (a) having a non-zero window in the listening state and (b) a pointer, tp, being non-null when passed to tcp_close() to send the RST. In case (b), tp points to the listening socket. Looking at the above table, we can scan for active listening ports quite successfully, so long as we know what to expect back. In particular, using a SYN-ACK instead of a SYN seems particularly fruitful. It can be found at: ftp://coombs.anu.edu.au/pub/misc/etcp.tar.Z darren p.s. between this and ipsend, I've found `bugs' in TCP/IP on Solaris2.4, 4.4BSDs, Linux, SunOS4, Ultrix 4.3...so there are probably some in the others too! Some bugs are more benign than others, and at least two can be made to crash/panic and not reboot. -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-security Mon Dec 4 11:10:43 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24133 for security-outgoing; Mon, 4 Dec 1995 11:10:43 -0800 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24013 for ; Mon, 4 Dec 1995 11:08:54 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id VAA24414 for security@freebsd.org; Mon, 4 Dec 1995 21:06:29 +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 TAA02429 for ; Mon, 4 Dec 1995 19:43:52 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id TAA14123 for security@freebsd.org; Mon, 4 Dec 1995 19:43:51 +0200 From: "Andrew V. Stesin" Message-Id: <199512041743.TAA14123@office.elvisti.kiev.ua> Subject: Stealth Scanning - Bypassing Firewalls/SATAN Detectors (fwd) To: security@freebsd.org Date: Mon, 4 Dec 1995 19:43:51 +0200 (EET) X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 9040 Sender: owner-security@freebsd.org Precedence: bulk Forwarded message: >From <@relay1.carrier.kiev.ua:kiae!demos!kremvax.demos.su!GreatCircle.COM!firewalls-owner> Mon Dec 4 11:22:54 1995 X-Sender: vin@shore.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Dec 1995 01:21:11 -0500 To: firewalls@GreatCircle.COM From: Christopher Klaus (by way of vin@shore.net (Vin McLellan)) Subject: Stealth Scanning - Bypassing Firewalls/SATAN Detectors Sender: firewalls-owner@GreatCircle.COM Precedence: bulk An interesting warning issued Friday to subscribers of Chris Klaus' new "Alert" mailing list. -vbm Stealth Scanning - Bypassing Firewalls and SATAN Detectors ---------------------------------------------------------- Administrators need tools to find out what is going on in their network. Maybe an internal employee has installed a unauthorized web server and put proprietary information online allowing anyone to access it, how does an administrator find out that there is even a web server running on their network? Many administrators use tools called TCP Port scanners. These programs which try to connect to all possible ports on a machine find which services are running. This information gives a network administrator better ability to understand and be aware of how his or her network is configured. Unfortunately, this technology is a double-edge sword because intruders can scan other networks and be able to gather information that helps better mount an attack. The intruder now knows which machines are running and what services are available. TCP port scanning is built into shareware auditing tools, such as ISS (Internet Security Scanner) and SATAN. These tools were intended to help administrators correct security risks in their network, but unfortunately they are just as useful to the bad guys. Because TCP port scanning is like knocking on the door of many services, people have written tools like SATAN detectors which notify administrators when outside people are knocking on their network. This has made the administrator feel like they are getting a good alarm notice if a hacker decides to attack their network. Here is a problem that we want to educate people about and possibly come up with some better solutions to addressing this problem. Most of the TCP port scanning technology relies on making an established connection with a port to determine if it is active or not. Many of the SATAN/Port Scanning Detectors rely on this fact. They record the connections and if a connection happens to a wrong port or the number of connections within a certian time reaches a threshhold, an alarm goes off. TCP_wrappers will also keep a record of any estblished connection which helps administrators find where an intruder came from. One problem which exists is that intruders can scan without establishing a connection. There is a technique for doing a half-open scan. The intruder can send a SYN packet that starts a connection, and if the port is active, it will respond with a SYN|ACK and the intruder records these packets, determining which ports were active now. In a typical established connection, the host responds to the SYN|ACK to finish completing the connection. The intruder can now send a reset packet removing from the kernel that a connection was half open. Here's the interesting information. ---- We do not even need to use a SYN packet to scan. Many firewalls block outside networks from sending in a SYN packet and that stops initiating a connection. So even the half-open scan won't work past a firewall. But we have tried other TCP flags and found many other packets will do the trick just as good, and if not better. Here's a table of the packets and response types to determine active ports. Flag Active Port Response Non-active Port Response SYN SYN|ACK Reset or Nothing SYN|FIN ACK or SYN|ACK* Reset ACK Nothing Reset 0 flag Nothing Reset * Depends on the TCP implementation. Windows 95 returned SYN|ACK while most Unix platforms return an ACK. We have picked the most interesting flags. You can also add URG and PUSH flags to any of the above flags and get the same response. The SYN|FIN is an illegal type of flags that contradict themselves, but a few router based firewalls that were blocking the other type packets allow this one through. The 0 flag packets are packets that designate the packet type as 0, which some packet filter based firewalls may allow through. Some firewalls allow ACK packets through as well. Using these type of packets, we called this a "stealth scan" because typically most TCP port scan detectors do not catch this type of activity and the scan enables you to bypass a firewall and see what services are running on the inside machines. Denial of Service Attacks ------------------------- In coming up with developing this code, we are able to do 2 types of denial of service attacks that people should be aware of and at some point, we need to have vendors fix the problems. 1) By scanning with all these different types of packets, we were able to crash a few popular type routers that could not handle these packets. We reported the problem back to the vendors. 2) By scanning with half-opens and not sending a RESET, the kernel's cache of half-open connections get full and will no longer accept any more connection. This would be a quick and easy way to cause a high connection rate machine to no longer provide any more connections, denying anyone from access to a machine, including a Web server. Solutions --------- Do not rely completely on SATAN detectors. Most of them are designed to only signal alarms if a full established connection is made. Courtney.pl is the only SATAN detector that we found that actually looked at the packets themselves looking for SYN packets. To detect a stealth scan, we need to come up with some heuristics for detecting an anomly of the number of reset packets generated as well. For denial of service attacks, if a device can't handle the packets it will be up to the vendor to provide a patch to fix this. Vendors need to look at potential solutions for half open attacks such as increasing in the kernel the number of half open connections possible, decreasing the time that the cached half opens stay in the memory, possibly logging when a particular host has filled up the half open cache and ignoring further half open packets from the offending host. Firewalls --------- The more secure setup of firewalls tend to be a combination of both packet filter / proxy server type firewalls that would prevent scanning past the firewall if configured properly. /--------------------------------------------------------------------------- -----------------\ To get on mailing list, Alert, send a message to alert-request@iss.net and within the message, type: subscribe alert \--------------------------------------------------------------------------- -----------------/ Copyright This paper is Copyright (c) 1994, 1995 by Christopher Klaus of Internet Security Systems, Inc. Permission is hereby granted to give away free copies electronically. You may distribute, transfer, or spread this paper electronically. You may not pretend that you wrote it. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Address of Author Please send suggestions, updates, and comments to: Christopher Klaus of Internet Security Systems, Inc. Internet Security Systems, Inc. Internet Security Systems, Inc, located in Atlanta, Ga., specializes in the developement of security scanning software tools. Its flagship product, Internet Scanner, is software that learns an organization's network and probes every device on that network for security holes. It is the most comprehensive "attack simulator" available, checking for over 100 security vulnerabilities. -- Christopher William Klaus Voice: (770)441-2531. Fax: (770)441-2431 Internet Security Systems, Inc. "Internet Scanner lets you find 2000 Miller Court West, Norcross, GA 30071 your network security holes Web: http://iss.net/ Email: cklaus@iss.net before the hackers do." -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-security Tue Dec 5 13:44:36 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA07701 for security-outgoing; Tue, 5 Dec 1995 13:44:36 -0800 Received: from gate3.fmr.com (gate3.fmr.com [192.223.170.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA07696 for ; Tue, 5 Dec 1995 13:44:29 -0800 Received: (from adm@localhost) by gate3.fmr.com (8.6.12/8.6.9) id QAA04442 for ; Tue, 5 Dec 1995 16:43:56 -0500 Message-Id: <199512052143.QAA04442@gate3.fmr.com> Received: from mail3.fmr.com(137.199.61.18) by gate3 via smap (V1.3) id sma004403; Tue Dec 5 21:43:02 1995 Date: Tue, 05 Dec 1995 16:41 -0400 (EDT) From: "Brown, James F." Subject: ****HELP***** To: "'security@FreeBSD.org'" MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID X2oO6AN9jw7c37lzHuH3rg)" Content-transfer-encoding: 7BIT Posting-date: Tue, 05 Dec 1995 16:41 -0400 (EDT) Priority: normal Sender: owner-security@FreeBSD.org Precedence: bulk --Boundary (ID X2oO6AN9jw7c37lzHuH3rg) Content-type: TEXT/PLAIN Olliver Robert said: > >> Jordan; how hard would it be to generate a file with the md5's of a stock >> release system's "standard binaries" for this sort of thing? > >Tripwire has been made for that purpose... You can generate a database with >all the signatures very easily. I think there is a lot of value in a standard database burned into the FreeBSD CD-ROM. - Jim Brown brownj@world.std.com --Boundary (ID X2oO6AN9jw7c37lzHuH3rg) Content-type: APPLICATION/OCTET-STREAM; NAME=WINMAIL.DAT Content-transfer-encoding: BASE64 eJ8+IjYVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAA AElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEADgAA ACoqKipIRUxQKioqKioAowIBBYADAA4AAADLBwwABQAQACEAMwACAEkBASCAAwAO AAAAywcMAAUAEAAfACwAAgBAAQEJgAEAIQAAAENERjk5MzRFMEIyRkNGMTFCMTZD MDA0MDFDNjA1OERGAEEHAQSQBgB8AQAAAQAAAA0AAAADAAAwAgAAAAsADw4AAAAA AgH/DwEAAABQAAAAAAAAAABglGRgQbgBCAArK4opAABVM10AZAAaADsAFQAAABQA J3NlY3VyaXR5QEZyZWVCU0Qub3JnJwBzZWN1cml0eUBGcmVlQlNELm9yZwAeAAIw AQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFQAAAHNlY3VyaXR5QEZyZWVCU0Qub3Jn AAAAAAMAFQwBAAAAAgH5DwEAAABHAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAA c2VjdXJpdHlARnJlZUJTRC5vcmcAU01UUABzZWN1cml0eUBGcmVlQlNELm9yZwAA AwD+DwYAAAAeAAEwAQAAABcAAAAnc2VjdXJpdHlARnJlZUJTRC5vcmcnAAACAQsw AQAAABoAAABTTVRQOlNFQ1VSSVRZQEZSRUVCU0QuT1JHAAAAAwAAOQAAAAALAEA6 AQAAAAIB9g8BAAAABAAAAAAAAAIbSgEDkAYASAMAABAAAAALACMAAAAAAAMAJgAA AAAACwApAAAAAAADADYAAAAAAEAAOQBAOP9eWcO6AR4AcAABAAAADgAAACoqKipI RUxQKioqKioAAAACAXEAAQAAABYAAAABusNZXv9Ok/nOLwsRz7FsAEAcYFjfAAAD AAYQRTTeCgMABxA0AQAAHgAIEAEAAABlAAAAT0xMSVZFUlJPQkVSVFNBSUQ6Sk9S REFOO0hPV0hBUkRXT1VMRElUQkVUT0dFTkVSQVRFQUZJTEVXSVRIVEhFTUQ1U09G QVNUT0NLUkVMRUFTRVNZU1RFTVMiU1RBTkRBUkRCSQAAAAACAQkQAQAAAA4CAAAK AgAA3AMAAExaRnVCwmDs/wAKAQ8CFQKoBesCgwBQAvIJAgBjaArAc2V0MjcGAAbD AoMyA8UCAHByQnER4nN0ZW0CgzN3AuQHEwKAfQqACM8J2TvxFg8yNTUCgAqBDbEL YOBuZzEwMxRQCwoUUQUL8mMAQCBPbGxptnYEkAfxYgSQBUBzC3C0ZDoKhT4ZzRNQ bxPQPmMFQAqPGhwcrx21PiAKSgWwZABwOyBob6MH4BGBZCB3CGBsIqAGaQVAG5Ag dG8gZwsJ8ASQYRPQIGEgZqcDECNgA/B0aCNwaCNgkG1kNScEIG9mJDHxE8BvY2se Jx8PIB8hJ3sWECSAYRGwG9ATsyVxIu8TwABwIeAikWILgArACJD8cyIkUAWxJNAE ABvQFbH3JZIsERkQPyZPJ18dLy1f+y5vL31UBRED8BYQImEEIHcbkAnwJTBhDbAr xSQAIFJwCHBwbxGwLjXwIPJZCGAgYwORI7kh4AGR/ynCJLIwbzF/L24HQAMgJQJ1 AJBnK1B0CHAHkRsxeeYgKbEDEHkuHi8aFx4W+kks02sk8jPhLDEkQBWg/SyTdgdA ClAjEAOgJdIqxf03Z2IIcCPQIwECMCOQJQICRgnRQlNEIENEsC1ST009Nj1FLSGg yQdwIEIDYHduPUVGsFJiRhJqQCLAciLwLvcTwEeQBaBtOD8vnwrBFTECAEqwAAAD ABAQAAAAAAMAERAAAAAAQAAHMMBQAxNZw7oBQAAIMMBQAxNZw7oBHgA9AAEAAAAB AAAAAAAAAPXe --Boundary (ID X2oO6AN9jw7c37lzHuH3rg)-- From owner-freebsd-security Fri Dec 8 05:05:34 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA03180 for security-outgoing; Fri, 8 Dec 1995 05:05:34 -0800 (PST) Received: from bsd.tseinc.com (bsd.tseinc.com [199.217.191.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA03175 for ; Fri, 8 Dec 1995 05:05:29 -0800 (PST) Received: (from jlwest@localhost) by bsd.tseinc.com (8.6.11/8.6.9) id HAA01534; Fri, 8 Dec 1995 07:04:29 GMT Date: Fri, 8 Dec 1995 07:04:28 +0000 () From: "Jay L. West" To: freebsd-security@freebsd.org Subject: ipfw schtuff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk I have a multihomed freebsd gateway to my internet provider. The freebsd machine has an ethernet card which connects to other local pc's and workstations, and a ppp link to my isp. I compiled the kernel with options for ipfw as well as "options GATEWAY". >From an ethernet attached workstation I can telnet to sites on the internet. However, if I issue "ipfw policy deny" on the freebsd machine those same internal ethernet attached workstations can still telnet outside. I thought a policy of deny would prevent this. Can anyone provide assistance? I suspect options GATEWAY overrides the ipfw stuff, but if so how do I then allow some outside access? If static routes between enet and ppp are the answer, what should they look like? THANKS! Jay West From owner-freebsd-security Fri Dec 8 14:27:34 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA27884 for security-outgoing; Fri, 8 Dec 1995 14:27:34 -0800 (PST) Received: from pain.csrv.uidaho.edu (root@pain.csrv.uidaho.edu [129.101.114.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA27875 for ; Fri, 8 Dec 1995 14:27:20 -0800 (PST) Received: from pain.csrv.uidaho.edu (fn@localhost [127.0.0.1]) by pain.csrv.uidaho.edu (8.6.12/8.6.9) with ESMTP id OAA00937 for ; Fri, 8 Dec 1995 14:27:05 -0800 Message-Id: <199512082227.OAA00937@pain.csrv.uidaho.edu> To: security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <932.818461623.1@pain.csrv.uidaho.edu> Date: Fri, 08 Dec 1995 14:27:04 -0800 From: Faried Nawaz Sender: owner-security@freebsd.org Precedence: bulk mmm...canada. ------- Forwarded Message Return-Path: xmisc-request@zephyr.ccrc.wustl.edu Received: from zephyr.ccrc.wustl.edu (zephyr.ccrc.wustl.edu [128.252.169.9]) by pain.csrv.uidaho.edu (8.6.12/8.6.9) with SMTP id NAA00348 for ; Fri, 8 Dec 1995 13:53:43 -0800 Received: from zephyr.ccrc.wustl.edu by zephyr.ccrc.wustl.edu id aa02678; 8 Dec 95 13:08 CST Received: from MAJORDOMO by zephyr.ccrc.wustl.edu id aa02675; 8 Dec 95 13:05 CST Received: from zeus.theos.com by zephyr.ccrc.wustl.edu id aa02666; 8 Dec 95 13:05 CST Received: from LOCALHOST.theos.com by theos.com (4.1/tdr1.0) id AA10446; Fri, 8 Dec 95 12:05:23 MST Message-Id: <9512081905.AA10446@theos.com> To: misc@openbsd.org Subject: crypto software export Date: Fri, 08 Dec 1995 12:05:22 -0700 From: Theo de Raadt Sender: owner-misc@openbsd.org Precedence: bulk I just got confirmation from the Canadian government that free software is not controlled by any cryptographic export or usage laws in Canada. Yes, this means we're free to include any and all cryptographic stuff that we want in any place in the source tree, as long as licensing, patent, etc. issues are handled. The actual text of the law is being mailed to me. I'll be able to quote from it later if anyone wants further details. BTW, in a twist of law, when I asked about ITAR the gentleman said that ITAR doesn't enter into the picture at all. Apparently one could bring ITAR code into Canada, and the Canadian government has no law on the books to prevent it from being re-exported to the world. I'd always suspected this loophole; the fellow picked up rather quickly on what I was suggesting..... and made it clear that there'd be no law to prevent one from doing so! (not that I want to re-export ITAR) ------- End of Forwarded Message From owner-freebsd-security Fri Dec 8 17:26:11 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA11834 for security-outgoing; Fri, 8 Dec 1995 17:26:11 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA11829 for ; Fri, 8 Dec 1995 17:26:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id RAA15606; Fri, 8 Dec 1995 17:24:37 -0800 Message-Id: <199512090124.RAA15606@precipice.shockwave.com> To: Faried Nawaz , jis@mit.edu cc: security@FreeBSD.org Subject: legal to export DES outside of the US via Canada? In-reply-to: Your message of "Fri, 08 Dec 1995 14:27:04 PST." <199512082227.OAA00937@pain.csrv.uidaho.edu> Date: Fri, 08 Dec 1995 17:24:36 -0800 From: Paul Traina Sender: owner-security@FreeBSD.org Precedence: bulk This is an amazing loophole if it is true, but like the old saying goes, it sounds too good to be true. All it would take would be two coopoerating parties to legally export (non-patented) non-commercial crypto code. If this is true, I wonder why MIT's crowd of friends didn't pick up on it with respect to Kerberos (which sounds like it meets all criteria)? Paul From: Faried Nawaz mmm...canada. ------- Forwarded Message Return-Path: xmisc-request@zephyr.ccrc.wustl.edu Received: from zephyr.ccrc.wustl.edu (zephyr.ccrc.wustl.edu [128.252.169.9]) >>by pain.csrv.uidaho.edu (8.6.12/8.6.9) with SMTP id NAA00348 for >v.uidaho.edu>; Fri, 8 Dec 1995 13:53:43 -0800 Received: from zephyr.ccrc.wustl.edu by zephyr.ccrc.wustl.edu id aa02678; 8 Dec 95 13:08 CST Received: from MAJORDOMO by zephyr.ccrc.wustl.edu id aa02675; 8 Dec 95 13:05 >>CST Received: from zeus.theos.com by zephyr.ccrc.wustl.edu id aa02666; 8 Dec 95 13:05 CST Received: from LOCALHOST.theos.com by theos.com (4.1/tdr1.0) id AA10446; Fri, 8 Dec 95 12:05:23 MST Message-Id: <9512081905.AA10446@theos.com> To: misc@openbsd.org Subject: crypto software export Date: Fri, 08 Dec 1995 12:05:22 -0700 From: Theo de Raadt Sender: owner-misc@openbsd.org Precedence: bulk I just got confirmation from the Canadian government that free software is not controlled by any cryptographic export or usage laws in Canada. Yes, this means we're free to include any and all cryptographic stuff that we want in any place in the source tree, as long as licensing, patent, etc. issues are handled. The actual text of the law is being mailed to me. I'll be able to quote from it later if anyone wants further details. BTW, in a twist of law, when I asked about ITAR the gentleman said that ITAR doesn't enter into the picture at all. Apparently one could bring ITAR code into Canada, and the Canadian government has no law on the books to prevent it from being re-exported to the world. I'd always suspected this loophole; the fellow picked up rather quickly on what I was suggesting..... and made it clear that there'd be no law to prevent one from doing so! (not that I want to re-export ITAR) ------- End of Forwarded Message From owner-freebsd-security Sat Dec 9 13:45:04 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16075 for security-outgoing; Sat, 9 Dec 1995 13:45:04 -0800 (PST) Received: from big-screw (BIG-SCREW.MIT.EDU [18.72.0.176]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16045 for ; Sat, 9 Dec 1995 13:45:00 -0800 (PST) Received: by big-screw id AA00439; Sat, 9 Dec 95 16:44:29 -0500 X-Sender: jis@e40-po.mit.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 9 Dec 1995 15:44:34 -0600 To: Paul Traina From: jis@mit.edu (Jeffrey I. Schiller) Subject: Re: legal to export DES outside of the US via Canada? Cc: Faried Nawaz , jis@mit.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk Ah. But when a Canadian receives ITAR controlled code from the U.S. he/she has to agree not to export it from Canada (we have to require this otherwise we cannot send it to the Canadians!). -Jeff