From owner-freebsd-security Sun May 4 09:50:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA03826 for security-outgoing; Sun, 4 May 1997 09:50:42 -0700 (PDT) Received: from tor-adm1.nbc.netcom.ca (taob@tor-adm1.nbc.netcom.ca [207.181.89.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA03821 for ; Sun, 4 May 1997 09:50:39 -0700 (PDT) Received: from localhost (taob@localhost) by tor-adm1.nbc.netcom.ca (8.8.5/8.8.5) with SMTP id MAA20219 for ; Sun, 4 May 1997 12:49:31 -0400 (EDT) Date: Sun, 4 May 1997 12:49:30 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY Subject: Buffer Overflows: A Summary (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 30 Apr 1997 01:03:17 -0500 From: Aleph One To: BUGTRAQ@NETSPACE.ORG Subject: Buffer Overflows: A Summary This is a short summary of the buffer overflow discussion on BugTraq. It will hopefully server to answer questions in a concise manner, and reduce the list traffic to what it normally is. As mentioned by Theo de Raadt, Michael Shields, Tim Newsham, and others the only real solution to buffer overflows is fixing the defective programs. Anything else is a stopgap measure. This by no means implies you should not use one or more of the alternatives as fall back methods. The more defenses the better. Just don't depend on them. Again the thing to do is fix the offending code. The OpenBSD project and some other teams have done a great job in this area. They have systematically gone through their code base looking for possible vulnerabilities. Not only have the fixed dozens of possible holes, at the same time they have made their software more reliable. Reliability and security go hand in hand. Another option is to use a language that implements bounds checking such as Ada, Java, or Perl. Richard Jones and Paul Kelly have developed patches to gcc that implement some bounds checking in C ( http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html ). There also exists commercial products such as Purify that attempt to help you identify this and other bugs. BSDI, OpenBSD and other operating systems have also modified the linker to generate warning messages when a program uses dangerous functions. This is no panacea since overflows not only occur in standard libraries nor are all uses of dangerous functions incorrect, but they will flag a program as suspicious. The C compiler and/or lint could be modified to attempt to catch obvious buffer overflows. The disadvantage is that not all possible overflows can be detected and such a modifications are not trivial. It's been suggested that you could modify the dangerous functions in the C library to perform a stack integrity check before returning. If the check does not pass, it would print a warning message and exit. The downside is that this method will not catch all buffer overflows and would introduce a performance penalty. Alexandre Snarskii has developed just such a patch for FreeBSD. ( ftp://ftp.lucky.net/pub/unix/local/libc-letter ) The security axiom of "least privilege" would insure that even if a program is compromised the privilege obtained by doing so is minimal. This is the case in Trusted Systems or systems implementing POSIX.1e (formerly POSIX.6) capabilities. Thomas Ptacek has developed kernel patches for FreeBSD that shifted the privilege of binding to a privileged port from root to a new uid. There is also a project underway to make Linux POSIX.1e compliant. If such facilities are not available the programs should be coded in such as way as to use their privilege in small, easy to audit, sections of code and then discard them as soon as possible by means of setreuid(2). Marking the stack non-executable will catch most cut and paste exploits but may break certain programs under some architectures and will not catch exploits that do not depend on an executable stack. As an example the Internet worm fingerd overflow overwrote the string "/usr/bin/finger" with "/bin/sh" in the data segment. Casper Dik developed a script that modifies the Solaris kernel so that the stack no longer has execute permission. Solar Designer made available a patch for Linux that performs a similar functionality. Search the BugTraq archives for both of them. Other more obscure solutions involve architecture changes as noted by Shawn Instenes. Such as if only the CALL instructions could put a return address on the stack, or having the OS enforce a "stack window" which limits where you can write in the stack. Or as pointed out by Zygo Blaxell you could allocate automatic variables on the heap or some other place that is not the stack. David Holland noted that new architectures could simply have multiple stacks: one for call frames, and one for automatic storage. It was suggested that the kernel should check in the exec system call to determine if a shell was being executed. Such a check would be of little use as the attacker may execute a file of any name in the filesystem. This path of thinking does lead to an interesting defense that I believe would be of great use and should be implemented. Most daemons and utilities will not exec a program. Most will simply fork. In such cases a system call that disabled any further calls to exec would stop all exploits that attempted to use the exec system call. Instead the kernel could print a warning message and call exit. This scheme could be extended to define an interface for a program to disable any system call that it did not need thus reducing the attackers options. To conclude, as we all know security is a risk management game. There is no such thing as 100% security. Even if you perform code reviews and QA testing bugs will creep into software. So your best bet is a multilayered approach to security. Would you rather have a vendor's or programmer's word that the code you are running in your security sensitive installation is safe, or recompile said code using a compiler that checks for buffer overflows and inserts bounds checking code, and run it in a machine that marks its stack non-executable and that allows you to turn off unnecessary system calls? I think the choice is obvious. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-security Mon May 5 01:37:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA12468 for security-outgoing; Mon, 5 May 1997 01:37:32 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA12461 for ; Mon, 5 May 1997 01:37:30 -0700 (PDT) Received: from uucp3.iij.ad.jp (uucp3.iij.ad.jp [202.232.2.203]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id RAA05939 for ; Mon, 5 May 1997 17:37:29 +0900 (JST) Received: (from uucp@localhost) by uucp3.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id RAA24729 for freebsd-security@FreeBSD.org; Mon, 5 May 1997 17:37:28 +0900 Received: (qmail 5999 invoked by uid 1000); 5 May 1997 08:37:12 -0000 Message-ID: <19970505083712.5998.qmail@reseau.toyonaka.osaka.jp> Date: Mon, 5 May 1997 17:37:12 +0900 (JST) From: Kenji Rikitake X-Sender: kenji@reseau.reseau.rcac.tdi.co.jp To: freebsd-security@FreeBSD.org Subject: questions on 2.2.1-RELEASE default value for kern.securelevel MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Today I found that kern.securelevel of my 2.2.1-RELEASE-running machine was -1. I decided to set it to 0 in /etc/rc so that it would be secured to level 1 in the multi-user mode. This was successful but when I tried to boot up XF86 server it failed because of the operation failure of KDENABIO. So I checked out some kernel code and found that in /sys/i386/isa/syscons.c the KDENABIO operation is prohibited when kern.securelevel > 0. Here's my questions: 1. Why the initial value of kern.securelevel is set to -1? 2. Why the KDENABIO operation is prohibited when kern.securelevel > 0? Obviously patching out the kern.securelevel check in KDENABIO code will run the XF86 server, but doing this may create a new vulnerability. I would appreciate if a FreeBSD guru can answer me about this. FYI my BSD/OS 2.0.1 runs Xaccel happily in kern.securelevel = 1. Why not on the FreeBSD? Regards, // Kenji Rikitake // An equal opportunistic encryptor. WWW: http://www.nn.iij4u.or.jp/~kenji/ From owner-freebsd-security Mon May 5 11:15:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA10066 for security-outgoing; Mon, 5 May 1997 11:15:04 -0700 (PDT) Received: from asteroid.intermedia.ru ([194.85.158.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA10052 for ; Mon, 5 May 1997 11:14:57 -0700 (PDT) Received: from asteroid.intermedia.ru (localhost.intermedia.ru [127.0.0.1]) by asteroid.intermedia.ru (8.8.5/8.8.5) with ESMTP id WAA09603 for ; Mon, 5 May 1997 22:19:32 +0400 (MSD) Message-Id: <199705051819.WAA09603@asteroid.intermedia.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: security@freebsd.org Subject: User since epoch??? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 22:19:30 +0400 From: Alex Povolotsky Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just noticed WERY strange output from w: asteroid#/var/log/squid 202_> w 10:18PM up 12:11, 7 users, load averages: 0.96, 1.23, 1.26 USER TTY FROM LOGIN@ IDLE WHAT root v1 - 1:33PM 8:43 xinit /root/.xinitrc -- /root/.xser root p0 :0.0 5:29PM 2 irc NiteWalk irc.voicenet.com (irc- root p1 :0.0 1:39PM 3:23 -tcsh (tcsh) root p2 :0.0 5:38PM 1 -tcsh (tcsh) tarkhil p3 :0.0 8:45PM 2 tin root p4 :0.0 7:20PM - w 5 - 01Jan70 7:48 - User "5" doesn't exists in /etc/passwd, nor UID 5. It doesn't have any processes. It looks VERY much like intrusion, but I just can't understand how can it be :-E FreeBSD-2.2.1-Release. Alex. From owner-freebsd-security Mon May 5 12:00:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA12286 for security-outgoing; Mon, 5 May 1997 12:00:58 -0700 (PDT) Received: from thermohaline.csc.ncsu.edu (thermohaline.csc.ncsu.edu [152.1.57.31]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA12276 for ; Mon, 5 May 1997 12:00:52 -0700 (PDT) Received: by thermohaline.csc.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05131; Mon, 5 May 1997 15:00:21 -0400 Message-Id: <9705051900.AA05131@thermohaline.csc.ncsu.edu> Subject: Re: User since epoch??? To: root@asteroid.intermedia.ru (Alex Povolotsky) Date: Mon, 5 May 1997 15:00:20 -0400 (EDT) Cc: security@FreeBSD.ORG In-Reply-To: <199705051819.WAA09603@asteroid.intermedia.ru> from "Alex Povolotsky" at May 5, 97 10:19:30 pm Reply-To: nsj@ncsu.edu From: nsj@ncsu.edu (Nate Johnson) X-Mailer: ELM [version 2.4 PL24/POP] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk %asteroid#/var/log/squid 202_> w %10:18PM up 12:11, 7 users, load averages: 0.96, 1.23, 1.26 %USER TTY FROM LOGIN@ IDLE WHAT %root v1 - 1:33PM 8:43 xinit /root/.xinitrc -- /root/.xser %root p0 :0.0 5:29PM 2 irc NiteWalk irc.voicenet.com (irc- %root p1 :0.0 1:39PM 3:23 -tcsh (tcsh) %root p2 :0.0 5:38PM 1 -tcsh (tcsh) %tarkhil p3 :0.0 8:45PM 2 tin %root p4 :0.0 7:20PM - w %5 - 01Jan70 7:48 - % %User "5" doesn't exists in /etc/passwd, nor UID 5. It doesn't have any %processes. It looks VERY much like intrusion, but I just can't understand how %can it be :-E % %FreeBSD-2.2.1-Release. I was experiencing very similar problems. As a matter of fact, I would also have "users" with ids of "ttypf" and other various oddities. The rumor is that if you grab the latest and greatest copy of XF86, this should clear it up. (Note that the problem doesn't, or shouldn't, show up when you're not in X). Cheers, nsj -- Nate Johnson / nsj@ncsu.edu / nsj@catt.ncsu.edu / nsj@FreeBSD.org Head Systems Administrator, Computer and Technologies Theme Program North Carolina State University, Raleigh, North Carolina From owner-freebsd-security Mon May 5 23:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA20183 for security-outgoing; Mon, 5 May 1997 23:48:19 -0700 (PDT) Received: from pc-pvl.nanoteq.co.za (pc-pvl.nanoteq.co.za [163.195.219.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA20176 for ; Mon, 5 May 1997 23:48:08 -0700 (PDT) Received: from pc-pvl.nanoteq.co.za (localhost.nanoteq.co.za [127.0.0.1]) by pc-pvl.nanoteq.co.za (8.8.5/8.8.5) with ESMTP id IAA13502; Tue, 6 May 1997 08:47:33 GMT Message-Id: <199705060847.IAA13502@pc-pvl.nanoteq.co.za> To: Alex Povolotsky cc: security@FreeBSD.ORG Subject: Re: User since epoch??? In-reply-to: Your message of "Mon, 05 May 1997 22:19:30 +0400." <199705051819.WAA09603@asteroid.intermedia.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 08:47:33 +0000 From: Pierre-Andre van Leeuwen Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've just noticed WERY strange output from w: > > asteroid#/var/log/squid 202_> w > 10:18PM up 12:11, 7 users, load averages: 0.96, 1.23, 1.26 > USER TTY FROM LOGIN@ IDLE WHAT > root v1 - 1:33PM 8:43 xinit /root/.xinitrc -- /root/.xser > root p0 :0.0 5:29PM 2 irc NiteWalk irc.voicenet.com (irc- > root p1 :0.0 1:39PM 3:23 -tcsh (tcsh) > root p2 :0.0 5:38PM 1 -tcsh (tcsh) > tarkhil p3 :0.0 8:45PM 2 tin > root p4 :0.0 7:20PM - w > 5 - 01Jan70 7:48 - > > User "5" doesn't exists in /etc/passwd, nor UID 5. It doesn't have any > processes. It looks VERY much like intrusion, but I just can't understand how > can it be :-E I had more or less the same problem in X. In my case, no user other than root would show up when I run who. This happened no matter how many xterms the user had open. I did a manual reinstall of X by running the preinstall script (preinst.sh), untarring the dist and then running postinst.sh. That solved the problem for me. I recreated the problem by untarring the distribution without running the scripts, so I think that is probably what happened to you too. Maybe sysinstall stopped before running the postinst.sh script ? (I haven't had a look at the scripts though -- no time :) ) -- Pierre-Andre van Leeuwen Electronic Engineer Powered By FreeBSD ******************************** * Nanoteq (Pty) Ltd. * * Specialists in data security * * E-mail : pvl@nanoteq.com * * Ph : +27 (0)12 665-1338 * * http://www.nanoteq.co.za * ******************************** From owner-freebsd-security Tue May 6 05:41:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA08235 for security-outgoing; Tue, 6 May 1997 05:41:00 -0700 (PDT) Received: from asteroid.intermedia.ru ([194.85.158.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA08230 for ; Tue, 6 May 1997 05:40:53 -0700 (PDT) Received: from asteroid.intermedia.ru (localhost.intermedia.ru [127.0.0.1]) by asteroid.intermedia.ru (8.8.5/8.8.5) with ESMTP id QAA11813 for ; Tue, 6 May 1997 16:45:21 +0400 (MSD) Message-Id: <199705061245.QAA11813@asteroid.intermedia.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: security@freebsd.org Subject: Firewall and IRC Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 16:45:17 +0400 From: Alex Povolotsky Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I'm trying to make well-built firewall allowing DCC gets and puts. I don't know much about IRC protocol, can anyone help me with ready-made recepie? Alex. From owner-freebsd-security Wed May 7 14:53:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19901 for security-outgoing; Wed, 7 May 1997 14:53:19 -0700 (PDT) Received: from air.infinetgroup.com (air.infinetgroup.com [207.23.43.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA19895; Wed, 7 May 1997 14:53:17 -0700 (PDT) Received: from localhost (lenc@localhost) by air.infinetgroup.com (8.8.5/8.8.4) with SMTP id OAA19168; Wed, 7 May 1997 14:52:30 -0700 (PDT) Date: Wed, 7 May 1997 14:52:30 -0700 (PDT) From: Leonard Chua To: freebsd-isp@freebsd.org, freebsd-security@freebsd.org Subject: CERT Advisory CA-97.13 - Vulnerability in xlock (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hope I'm not wasting bandwidth. But having at least a dozen xterms and other windows open, I use xlock a lot. Surely someone else out there does the same. better safe than sorry. :) ============================================================================= CERT* Advisory CA-97.13 Original issue date: May 7, 1997 Last revised: -- Topic: Vulnerability in xlock - ----------------------------------------------------------------------------- The CERT Coordination Center has received reports that a buffer overflow condition exists in some implementations of xlock. This vulnerability makes it possible for local users (users with access to an account on the system) to execute arbitrary programs as a privileged user. Exploitation information involving this vulnerability has been made publicly available. If your system is vulnerable, the CERT/CC team recommends installing a patch from your vendor. If you are not certain whether your system is vulnerable or if you know that your system is vulnerable and you cannot add a patch immediately, we urge you to apply the workaround described in Section III.B. We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. - ----------------------------------------------------------------------------- I. Description xlock is a program that allows a user to "lock" an X terminal. A buffer overflow condition exists in some implementations of xlock. It is possible attain unauthorized access to a system by engineering a particular environment and calling a vulnerable version of xlock that has setuid or setgid bits set. Information about vulnerable versions must be obtained from vendors. Some vendor information can be found in Appendix A of this advisory. Exploitation information involving this vulnerability has been made publicly available. Note that this problem is different from that discussed in CERT Advisory CA-97.11.libXt. II. Impact Local users are able to execute arbitrary programs as a privileged user without authorization. III. Solution Install a patch from your vendor as described in Solution A. If you are not certain whether your system is vulnerable or if you know that your system is vulnerable and you cannot install a patch immediately, we recommend Solution B. A. Obtain and install a patch for this problem. Below is a list of vendors who have provided information about xlock. Details are in Appendix A of this advisory; we will update the appendix as we receive more information. If your vendor's name is not on this list, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Berkeley Software Design, Inc. (BSDI) Cray Research - A Silicon Graphics Company Data General Corporation Digital Equipment Corporation FreeBSD, Inc. Hewlett-Packard Company IBM Corporation LINUX NEC Corporation The Open Group [This group distributes the publicly available software that was formerly distributed by X Consortium] Solbourne Sun Microsystems, Inc. B. We recommend the following workaround if you are not certain whether your system is vulnerable or if you know that your system is vulnerable and you cannot install a patch immediately. 1. Find and disable any copies of xlock that exist on your system and that have the setuid or setgid bits set. 2. Install a version of xlock known to be immune to this vulnerablility. One such supported tool is xlockmore. The latest version of this tool is 4.02, and you should ensure that this is the version you are using. This utility can be obtained from the following site: ftp://ftp.x.org/contrib/applications/xlockmore-4.02.tar.gz MD5 (xlockmore-4.02.tar.gz) = c158e6b4b99b3cff4b52b39219dbfe0e You can also obtain this version from mirror sites. A list of these sites will be displayed if you are not able to access the above archive due to load. ........................................................................... Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. (snip) FreeBSD, Inc. ============= The xlockmore version we ship in our ports collection is vulnerable in all shipped releases. The port in FreeBSD-current is fixed. Solution is to install the latest xlockmore version (4.02). (more snip) - ----------------------------------------------------------------------------- The CERT Coordination Center thanks David Hedley for reporting the original problem and Kaleb Keithley at The Open Group for his support in the development of this advisory. - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/). CERT/CC Contact Information - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- * Registered U.S. Patent and Trademark Office. Copyright 1997 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. The CERT Coordination Center is part of the Software Engineering Institute (SEI). The SEI is sponsored by the U.S. Department of Defense. - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.13.xlock http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM3DOFnVP+x0t4w7BAQH9MwQAwULlCDTqDbW+CiS0/Z36BtGf6Eqzx43B pEt72rQlQbw2AqRnHeq85dzVUB4eKmL0T//bGYyo0sCt+8nlFaS3cNYh0cyl3jdu JPDVoNhWB7v2+8nHvAEDz2UdomNVaxXDFvAbZ9JvEk/Ex6aFiXtl4qXdjxtcC4ze kGKLcu0+LzE= =nF5B -----END PGP SIGNATURE----- From owner-freebsd-security Wed May 7 15:02:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20418 for security-outgoing; Wed, 7 May 1997 15:02:17 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20409 for ; Wed, 7 May 1997 15:02:12 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.7.6/8.7.3) id AAA25994; Thu, 8 May 1997 00:01:31 +0200 (MET DST) Date: Thu, 8 May 1997 00:01:31 +0200 (MET DST) Message-Id: <199705072201.AAA25994@bitbox.follo.net> From: Eivind Eklund To: Alex Povolotsky CC: security@FreeBSD.ORG In-reply-to: Alex Povolotsky's message of Tue, 06 May 1997 16:45:17 +0400 Subject: Re: Firewall and IRC References: <199705061245.QAA11813@asteroid.intermedia.ru> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hello! > > I'm trying to make well-built firewall allowing DCC gets and puts. I don't > know much about IRC protocol, can anyone help me with ready-made recepie? natd and PPP+pktAlias support it. You can look at the code there; it works, though it is a bit of a kludge. There is no actual standard for DCC - everything is defined as 'the way ircII works'. There are some documents about the protocol at ftp.funet.fi, but they're somewhat dated. (And no, I don't know of any other proxies that support it, though there probable are some.) Eivind.