From owner-freebsd-security@FreeBSD.ORG Mon Nov 15 06:56:43 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2649616A4CE for ; Mon, 15 Nov 2004 06:56:43 +0000 (GMT) Received: from smtpclu-2.eunet.yu (smtpclu-2.eunet.yu [194.247.192.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C480943D39 for ; Mon, 15 Nov 2004 06:56:41 +0000 (GMT) (envelope-from kolicz@EUnet.yu) Received: from faust.net (P-2.122.EUnet.yu [213.240.2.122]) by smtpclu-2.eunet.yu (8.12.11/8.12.11) with ESMTP id iAF6ubr7002924 for ; Mon, 15 Nov 2004 07:56:38 +0100 Received: by faust.net (Postfix, from userid 1001) id 8EE5760E3; Mon, 15 Nov 2004 07:55:24 +0100 (CET) Date: Mon, 15 Nov 2004 07:55:24 +0100 From: Zoran Kolic To: freebsd-security@freebsd.org Message-ID: <20041115065524.GA972@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scan: EUnet-AVAS-Milter X-AVAS-Virus-Status: clean X-Spam-Checker: EUnet-AVAS-Milter X-AVAS-Spam-Score: -1.2 X-AVAS-Spam-Symbols: AWL BAYES_44 Subject: ipfw logging X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 06:56:43 -0000 Hi all! After installing 5.3 I've noticed some change in firewall logging. Prior (on 5.2) rules gave me what I needed: trimed to 3 of the same connection. Every new connection on the same rule gave new log line up to 3. I have in kernel: FIREWALL FIREWALL_VERBOSE FIREWALL_VERBOSE_LIMIT=3 Now, all connections on the same rule are trimed to 3. Is it possib- le on 5.3 to have all connections logged, but no more than 3 of the same? Just a little annoyance... I'd rather see what was blocked. New is even line: "ipfw: limit 3 reached on entry 1500" Can I do something to have old way of logging back? Best regards ZK From owner-freebsd-security@FreeBSD.ORG Mon Nov 15 08:11:24 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0E2416A4CE; Mon, 15 Nov 2004 08:11:24 +0000 (GMT) Received: from nord.interexc.com (nord.interexc.com [193.108.123.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 034B943D5D; Mon, 15 Nov 2004 08:11:22 +0000 (GMT) (envelope-from gruand@nord.interexc.com) Received: from nord.interexc.com (localhost.interexc.com [127.0.0.1]) by nord.interexc.com (8.12.10/8.12.10) with ESMTP id iAF8BIl7023755; Mon, 15 Nov 2004 10:11:18 +0200 (EET) (envelope-from gruand@nord.interexc.com) Received: (from gruand@localhost) by nord.interexc.com (8.12.10/8.12.10/Submit) id iAF8BIXf023754; Mon, 15 Nov 2004 10:11:18 +0200 (EET) (envelope-from gruand) Date: Mon, 15 Nov 2004 10:11:18 +0200 From: Andrei Grudiy To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20041115081118.GD5411@interexc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Mon, 15 Nov 2004 14:08:20 +0000 Subject: X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 08:11:24 -0000 freebsd-questions@freebsd.org Cc: Bcc:gruand Subject: Re: 100.chksetuid in /etc/periodic/security resets the mashine Reply-To: In-Reply-To: <20041112173824.GT26202@horsey.gshapiro.net> Hello, kolleages! I have a problem. When I (or system) start the script 100.chksetuid in /etc/periodic/security my machine resets. The machine: Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.82-MHz 686-class CPU) System version: FreeBSD 4.10-STABLE #0: Mon Nov 8 06:50:54 PST 2004 I will glad to have help. Thank you in advance. -- Andrei Grudiy. Ukraine. From owner-freebsd-security@FreeBSD.ORG Mon Nov 15 08:49:58 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB76516A4CE; Mon, 15 Nov 2004 08:49:58 +0000 (GMT) Received: from nord.interexc.com (nord.interexc.com [193.108.123.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D919443D49; Mon, 15 Nov 2004 08:49:57 +0000 (GMT) (envelope-from gruand@nord.interexc.com) Received: from nord.interexc.com (localhost.interexc.com [127.0.0.1]) by nord.interexc.com (8.12.10/8.12.10) with ESMTP id iAF8nul7024620; Mon, 15 Nov 2004 10:49:56 +0200 (EET) (envelope-from gruand@nord.interexc.com) Received: (from gruand@localhost) by nord.interexc.com (8.12.10/8.12.10/Submit) id iAF8nufN024619; Mon, 15 Nov 2004 10:49:56 +0200 (EET) (envelope-from gruand) Date: Mon, 15 Nov 2004 10:49:56 +0200 From: Andrei Grudiy To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20041115084956.GA24138@interexc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Mon, 15 Nov 2004 14:08:20 +0000 cc: freebsd-questions@freebsd.org Subject: 100.chksetuid in /etc/periodic/security resets the mashine X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 08:49:59 -0000 Hello, kolleages! I have a problem. When I (or system) start the script 100.chksetuid in /etc/periodic/security my machine resets. The machine: Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.82-MHz 686-class CPU) System version: FreeBSD 4.10-STABLE #0: Mon Nov 8 06:50:54 PST 2004 I will glad to have help. Thank you in advance. -- Andrei Grudiy. Ukraine. From owner-freebsd-security@FreeBSD.ORG Tue Nov 16 23:20:38 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7162616A4CE for ; Tue, 16 Nov 2004 23:20:38 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C69443D41 for ; Tue, 16 Nov 2004 23:20:37 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CUCcm-00007a-00 for ; Wed, 17 Nov 2004 00:20:36 +0100 Received: from p5480be50.dip.t-dialin.net ([84.128.190.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Nov 2004 00:20:36 +0100 Received: from dornseif by p5480be50.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Nov 2004 00:20:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-security@freebsd.org From: Maximillian Dornseif Date: Tue, 16 Nov 2004 21:30:09 +0100 Lines: 200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p5480be50.dip.t-dialin.net User-Agent: Unison/1.0.2a Sender: news cc: freebsd-firewire@freebsd.org Subject: FireWire Security issues X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2004 23:20:38 -0000 Hello, looking into the issue described in the advisory below I wonder how to tackle this issues. Primarily I ask myself * is there any reason not to filter all physical memory access by default * what would be the appropriate way to change the filter set? a sysctl? Regards Maximillian Dornseif FireWire/IEEE 1394 direct memory access - CAN-2004-1038 Advisory URL: http://pacsec.jp/advisories.html Subject: Potential system compromise by connected FireWire devices CVE #: CAN-2004-1038 Affected: So far all tested Operating Systems with FireWire support Summary: -------- The FireWire/IEEE 1394 specification allows client devices to directly access host memory, bypassing operating system limitations. A malicious client device can read and modify sensitive memory, causing privilege escalation, information leakage and system compromise. Any system with sensitive information or in an unsecured physical location, esp. public access systems, should re-evaluate their system security and consider additional physical security measures if they are equipped with "FireWire" ports. These ports are also called "iLink" on some Sony models. Overview: --------- In the presentation, "0wned by an iPod" which Maximilian Dornseif from Laboratory for Dependable Distributed Systems at RWTH Aachen University held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12, several new techniques involving the IEEE 1394 interface commonly found on laptops, desktops, and some servers were demonstrated. These techniques could be used in both malicious and beneficial applications. The beneficial applications are in the areas of system forensics and external debugging. The malicious applications are that anyone with physical access to the FireWire port could tamper with system operation and compromise security without measures such as power cycling or rebooting. Systems that counted on physical access limitation such as blocking access to reset and power switches and other measures to limit compromise though such procedures as rebooting, need to re-examine their security. As usual, physical access to a computer usually implies the ability for compromise - however, with this new technique, merely plugging in a malicious FireWire client device with special software could be enough to compromise a target. It becomes easier to violate security if the combination of physical access and FireWire interfaces are available. Security policies and procedures should be re-evaluated and consider this new information where needed. Details: -------- Firewire/1394 host adapters which comply to the OHCI specification allow remote devices to initiate direct DMA based memory access to the host computers main memory. This access takes place completely without involvement of the operating system on the host computer. While OHCI supplies certain methods to allow the filtering of such direct memory access requests, most operating systems do not use this filters or do not provide a way for the user to set such filters. This access can be used to read arbitrary memory from a system connected via FireWire and also to modify arbitrary memory contents. Applications of this capability include capture of screen contents, modification of screen contents, induced system crashes, escalation of process privileges and disabling of password queries. A simple application demonstrating screen blanking would look like this: #!/usr/bin/env python # Blank the medium third of a remote computer's screen via FireWire. # Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/ # http://md.hudora.de/presentations/#firewire-pacsec for further # detail. # --Maximillian Dornseif # Take care - this file uses hard coded addresses for just # everything. You will at least have to change values in the addrs # dictionary to suit your own equipment. import sys, time import fw # import simple mapping of Apples FireWire API to Python # module available at http://c0re.23.nu/c0de/pyfw/ # this structure encodes FireWire GUID, start of the actual screen memory # resolution and bits per pixel # example values for a Dell Latitude X 200 running FreeBSD 5.3 addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), } # enumerate devices on the FireWire bus and iterate over them for device in fw.scanbus(): print "Found device %r" % (device.guid) if device.guid not in addrs: print "don't now where to look on that machine, add it in the sourcecode" continue else: base, xres, yres, bpp = addrs[device.guid] # we just delete the medium third of the screen for demonstration purposes pos = base + (xres*bpp*(yres/3)) # iterate over screen lines and overwrite them with \0 while pos < base + (xres*bpp*(yres/3)*2): print "\r-> clearing %08x ..." % (pos), device.write(pos, "\0"*(xres*bpp)), sys.stdout.flush() pos += xres*bpp print done Systems Affected: ----------------- We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and 10.3.4 and Knoppix 3.6. All of them allowed memory access and had no obvious way to disable this functionality. We observed that Windows 2000 Professional crashed whenever an Apple Macintosh Computer running MacOS X was connected. Other operating systems where not tested. Any operating system and any hardware with FireWire interfaces should be considered vulnerable as long as statement from the vendor on OHCI filters or similar means of access control are available. Even if the operating system in question does not support the interface, compromise may still be possible if the hardware is powered. Fix: ---- On some systems that require untrusted/unauthenticated physical access by strangers and still require restricted operations, removal of wire headers connecting external case FireWire jacks may provide some limited remigration. On laptops epoxy may be used to permanently disable the external jack if such loss of functionality can be tolerated. The primary precaution is that employees should be warned that they should not plug unknown/untrusted FireWire devices into computers containing sensitive information. Operating system vendors should supply users with a way to control OHCI filters. Default configurations should deny all memory access via FireWire. Credits: -------- * Firestarter by Quinn "The Eskimo!" for demonstrating the potential of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html * Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his revealing post "FireWire for kernel hackers" - http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers * * Kerneltrap for pointing us to FreeBSD FireWire drivers - http://kerneltrap.org/node/view/145 Contact: -------- Maximillian Dornseif Laboratory for Dependable Distributed Systems RWTH Aachen University, Germany email: dornseif@informatik.rwth-aachen.de Phone: +49-241-80-21431 Web: http://md.hudora.de/ History: -------- - 2004-10-26 initial disclosure - 2004-11-15 updated to contain executive sumary, more details, example code, history and credits section - 2004-11-16 CAN-2004-1038 has been assigned to this issue From owner-freebsd-security@FreeBSD.ORG Wed Nov 17 01:40:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DCF816A4CE; Wed, 17 Nov 2004 01:40:44 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF8FA43D60; Wed, 17 Nov 2004 01:40:43 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 48F7D65211; Wed, 17 Nov 2004 01:40:42 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36056-02; Wed, 17 Nov 2004 01:40:41 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 18410651EB; Wed, 17 Nov 2004 01:40:41 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 36BFD66A3; Tue, 16 Nov 2004 17:40:37 -0800 (PST) Date: Tue, 16 Nov 2004 17:40:37 -0800 From: Bruce M Simpson To: Maximillian Dornseif Message-ID: <20041117014037.GP1468@empiric.icir.org> Mail-Followup-To: Maximillian Dornseif , freebsd-security@freebsd.org, freebsd-firewire@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: cc: freebsd-security@freebsd.org cc: freebsd-firewire@freebsd.org Subject: Re: FireWire Security issues X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 01:40:45 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2004 at 09:30:09PM +0100, Maximillian Dornseif wrote: > looking into the issue described in the advisory below I wonder how to=20 > tackle this issues. Primarily > I ask myself >=20 > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl? This is totally not news, this has been discussed in various circles for the past 5 years, though it's nice to see someone presenting an old attack in a new way. You can only filter the accesses by implementing filter logic in the PCI bridge to main memory to deny the accesses, or the PCI bus arbiter, or failing that, the FireWire to PCI host controller itself. The CPU and operating system are not able to intervene here in any way. Regards, BMS --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBmqwUueUpAYYNtTsRApZrAJ9DJzC1b6kBlojXohCfLQOxULm5xgCfUvfI eSN+nOup7hadrXtW0h/oe7c= =mdS6 -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-security@FreeBSD.ORG Wed Nov 17 01:52:36 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D97116A4CE; Wed, 17 Nov 2004 01:52:36 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1585843D54; Wed, 17 Nov 2004 01:52:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D18957A41E; Tue, 16 Nov 2004 17:52:35 -0800 (PST) Message-ID: <419AAEE3.9020900@elischer.org> Date: Tue, 16 Nov 2004 17:52:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maximillian Dornseif References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Nov 2004 13:46:05 +0000 cc: freebsd-security@freebsd.org cc: freebsd-firewire@freebsd.org Subject: Re: FireWire Security issues X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 01:52:36 -0000 Hi.! yes we've been aware of this problem for a year or so :-) I guess we need to get the filters done.. We do of course use firewire for remote kernel debugging with great success so we need to be able to turn it off sometimes :-) Maximillian Dornseif wrote: > Hello, > > looking into the issue described in the advisory below I wonder how to > tackle this issues. Primarily > I ask myself > > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl? > > Regards > > Maximillian Dornseif > > > > FireWire/IEEE 1394 direct memory access - CAN-2004-1038 > > Advisory URL: http://pacsec.jp/advisories.html > > Subject: Potential system compromise by connected FireWire devices > CVE #: CAN-2004-1038 > Affected: So far all tested Operating Systems with FireWire support > > Summary: > -------- > > The FireWire/IEEE 1394 specification allows client devices to directly > access host > memory, bypassing operating system limitations. A malicious client device > can read and modify sensitive memory, causing privilege escalation, > information leakage and system compromise. Any system with sensitive > information or in an unsecured physical location, esp. public access > systems, should re-evaluate their system security and consider additional > physical security measures if they are equipped with "FireWire" ports. > These ports are also called "iLink" on some Sony models. > > > Overview: > --------- > > In the presentation, "0wned by an iPod" which Maximilian Dornseif from > Laboratory for Dependable Distributed Systems at RWTH Aachen University > held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12, > several new techniques involving the IEEE 1394 interface commonly > found on laptops, desktops, and some servers were demonstrated. > > These techniques could be used in both malicious and beneficial > applications. > The beneficial applications are in the areas of system forensics and > external debugging. The malicious applications are that anyone with > physical access to the FireWire port could tamper with system operation > and compromise security without measures such as power cycling or > rebooting. > > Systems that counted on physical access limitation such as blocking > access > to reset and power switches and other measures to limit compromise though > such procedures as rebooting, need to re-examine their security. > > As usual, physical access to a computer usually implies the ability > for compromise - however, with this new technique, merely plugging > in a malicious FireWire client device with special software > could be enough to compromise a target. It becomes easier to > violate security if the combination of physical access and FireWire > interfaces are available. > > Security policies and procedures should be re-evaluated > and consider this new information where needed. > > > Details: > -------- > > Firewire/1394 host adapters which comply to the OHCI specification > allow remote devices to initiate direct DMA based memory access to the > host computers main memory. This access takes place completely without > involvement of the operating system on the host computer. While > OHCI supplies certain methods to allow the filtering of such direct > memory access requests, most operating systems do not use this filters > or do not provide a way for the user to set such filters. > > This access can be used to read arbitrary memory from a system connected > via FireWire and also to modify arbitrary memory contents. Applications > of this capability include capture of screen > contents, modification of screen contents, induced system crashes, > escalation of process privileges and disabling of password queries. > > A simple application demonstrating screen blanking would look like > this: > > #!/usr/bin/env python > > # Blank the medium third of a remote computer's screen via FireWire. > > # Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/ > # http://md.hudora.de/presentations/#firewire-pacsec for further > # detail. > # --Maximillian Dornseif > > # Take care - this file uses hard coded addresses for just > # everything. You will at least have to change values in the addrs > # dictionary to suit your own equipment. > > import sys, time > import fw # import simple mapping of Apples FireWire API to > Python > # module available at http://c0re.23.nu/c0de/pyfw/ > > # this structure encodes FireWire GUID, start of the actual screen memory > # resolution and bits per pixel > # example values for a Dell Latitude X 200 running FreeBSD 5.3 > addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), } > > # enumerate devices on the FireWire bus and iterate over them > for device in fw.scanbus(): > print "Found device %r" % (device.guid) > if device.guid not in addrs: > print "don't now where to look on that machine, add it in the > sourcecode" > continue > else: > base, xres, yres, bpp = addrs[device.guid] > > # we just delete the medium third of the screen for > demonstration purposes > pos = base + (xres*bpp*(yres/3)) > # iterate over screen lines and overwrite them with \0 > while pos < base + (xres*bpp*(yres/3)*2): > print "\r-> clearing %08x ..." % (pos), > device.write(pos, "\0"*(xres*bpp)), > sys.stdout.flush() > pos += xres*bpp > print done > > > > Systems Affected: > ----------------- > > We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and > 10.3.4 and Knoppix 3.6. All of them allowed memory access and had no > obvious way to disable this functionality. We observed that Windows > 2000 Professional crashed whenever an Apple Macintosh Computer running > MacOS X was connected. Other operating systems where not tested. > > Any operating system and any hardware with FireWire interfaces should > be considered vulnerable as long as statement from the vendor on OHCI > filters or similar means of access control are available. Even if the > operating system in question does not support the interface, compromise > may still be possible if the hardware is powered. > > > Fix: > ---- > > On some systems that require untrusted/unauthenticated physical > access by strangers and still require restricted operations, removal > of wire headers connecting external case FireWire jacks may provide > some limited remigration. > > On laptops epoxy may be used to permanently disable the external jack > if such loss of functionality can be tolerated. > > The primary precaution is that employees should be warned that they > should not plug unknown/untrusted FireWire devices into computers > containing sensitive information. > > Operating system vendors should supply users with a way to control > OHCI filters. Default configurations should deny all memory access via > FireWire. > > > Credits: > -------- > > * Firestarter by Quinn "The Eskimo!" for demonstrating the potential > of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html > * Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his > revealing post "FireWire for kernel hackers" - > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers > > * > * Kerneltrap for pointing us to FreeBSD FireWire drivers > - http://kerneltrap.org/node/view/145 > > > Contact: > -------- > > Maximillian Dornseif > Laboratory for Dependable Distributed Systems > RWTH Aachen University, Germany > email: dornseif@informatik.rwth-aachen.de > Phone: +49-241-80-21431 > Web: http://md.hudora.de/ > > History: > -------- > > - 2004-10-26 initial disclosure > - 2004-11-15 updated to contain executive sumary, more details, > example code, history and credits section > - 2004-11-16 CAN-2004-1038 has been assigned to this issue > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Nov 17 15:12:44 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32FC616A4CE for ; Wed, 17 Nov 2004 15:12:44 +0000 (GMT) Received: from silver.teardrop.org (silver.teardrop.org [66.150.202.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B6A43D39 for ; Wed, 17 Nov 2004 15:12:43 +0000 (GMT) (envelope-from snow@teardrop.org) Received: by silver.teardrop.org (Postfix, from userid 100) id 21EBA26C10; Wed, 17 Nov 2004 10:12:43 -0500 (EST) Date: Wed, 17 Nov 2004 10:12:42 -0500 From: James Snow To: Zoran Kolic Message-ID: <20041117151242.GB36240@teardrop.org> References: <20041115065524.GA972@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041115065524.GA972@faust.net> User-Agent: Mutt/1.4.1i cc: freebsd-security@freebsd.org Subject: Re: ipfw logging X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 15:12:44 -0000 On Mon, Nov 15, 2004 at 07:55:24AM +0100, Zoran Kolic wrote: > Hi all! > After installing 5.3 I've noticed > some change in firewall logging. > Prior (on 5.2) rules gave me what > I needed: trimed to 3 of the same > connection. Every new connection > on the same rule gave new log line > up to 3. I have in kernel: > FIREWALL > FIREWALL_VERBOSE > FIREWALL_VERBOSE_LIMIT=3 > Now, all connections on the same > rule are trimed to 3. Is it possib- > le on 5.3 to have all connections > logged, but no more than 3 of the > same? > Just a little annoyance... I'd > rather see what was blocked. New > is even line: > "ipfw: limit 3 reached on entry 1500" > Can I do something to have old way > of logging back? > Best regards This may or may not help you with your situation but I found it to be a considerable step up from setting these options in the kernel: As of 5.3 (or perhaps earlier - I first noticed it in 5.3) you can edit net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit via sysctl. Perhaps you'll have some luck fiddling with the value of net.inet.ip.fw.verbose_limit. Hope that helps. -Snow From owner-freebsd-security@FreeBSD.ORG Wed Nov 17 15:28:05 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDFBF16A4CE for ; Wed, 17 Nov 2004 15:28:05 +0000 (GMT) Received: from sollube.sarenet.es (sollube.sarenet.es [192.148.167.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE38F43D41 for ; Wed, 17 Nov 2004 15:28:05 +0000 (GMT) (envelope-from borjamar@sarenet.es) Received: from [127.0.0.1] (borja.sarenet.es [192.148.167.77]) by sollube.sarenet.es (Postfix) with ESMTP id 3E4EAED3; Wed, 17 Nov 2004 16:28:03 +0100 (CET) In-Reply-To: <419AAEE3.9020900@elischer.org> References: <419AAEE3.9020900@elischer.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4511D7AF-38AD-11D9-872F-000393C94468@sarenet.es> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Wed, 17 Nov 2004 16:28:02 +0100 To: Julian Elischer X-Mailer: Apple Mail (2.619) cc: freebsd-security@freebsd.org Subject: Re: FireWire Security issues X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 15:28:06 -0000 > yes we've been aware of this problem for a year or so :-) > I guess we need to get the filters done.. > We do of course use firewire for remote kernel debugging with great > success so we > need to be able to turn it off sometimes :-) Anyway, Firewire isn't Ethernet. A rogue device connected to an SCSI port (or an USB port) could sniff traffic sent to other devices, isn't it? It's a matter of how closely-coupled do you consider the interface; an Ethernet is more loosely coupled than a Firewire. You assume than an Ethernet may carry dangerous traffic, but, do you assume the same for a SCSI, a USB or a Firewire port, I mean, the kind of interface you use for hard disks, etc? BTW, provided that USB ports are connected in parallel... a rogue USB device could sniff a user's keyboard activity or even generate rogue keyboard activity, isn't it? Borja. From owner-freebsd-security@FreeBSD.ORG Wed Nov 17 20:56:28 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91C1816A4CE for ; Wed, 17 Nov 2004 20:56:28 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A50043D41 for ; Wed, 17 Nov 2004 20:56:28 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iAHKvbXI009255; Wed, 17 Nov 2004 12:57:37 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAHKvbOH009254; Wed, 17 Nov 2004 12:57:37 -0800 Date: Wed, 17 Nov 2004 12:57:37 -0800 From: Brooks Davis To: Borja Marcos Message-ID: <20041117205737.GA8233@odin.ac.hmc.edu> References: <419AAEE3.9020900@elischer.org> <4511D7AF-38AD-11D9-872F-000393C94468@sarenet.es> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <4511D7AF-38AD-11D9-872F-000393C94468@sarenet.es> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-security@freebsd.org cc: Julian Elischer Subject: Re: FireWire Security issues X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 20:56:28 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 04:28:02PM +0100, Borja Marcos wrote: > >yes we've been aware of this problem for a year or so :-) > >I guess we need to get the filters done.. > >We do of course use firewire for remote kernel debugging with great=20 > >success so we > >need to be able to turn it off sometimes :-) >=20 > Anyway, Firewire isn't Ethernet. A rogue device connected to an SCSI=20 > port (or an USB port) could sniff traffic sent to other devices, isn't= =20 > it? It's a matter of how closely-coupled do you consider the interface;= =20 > an Ethernet is more loosely coupled than a Firewire. You assume than an= =20 > Ethernet may carry dangerous traffic, but, do you assume the same for a= =20 > SCSI, a USB or a Firewire port, I mean, the kind of interface you use=20 > for hard disks, etc? >=20 > BTW, provided that USB ports are connected in parallel... a rogue=20 > USB device could sniff a user's keyboard activity or even generate rogue= =20 > keyboard activity, isn't it? Firewire presents much more risk then most other busses because it provides direct access to the address space of the host machine. The means you can read or modify everything include kernel code and data. That said, this is really useful for debugging. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBm7tBXY6L6fI4GtQRAq2DAKCvhlgmSBLM2gcA6jsOU5IwVB6wOgCg2YIz rECMAcCK9A6NfWDdWydgWhA= =7p9v -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-security@FreeBSD.ORG Thu Nov 18 12:23:35 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAE2A16A4D0; Thu, 18 Nov 2004 12:23:35 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA77B43D4C; Thu, 18 Nov 2004 12:23:34 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: by smtp.des.no (Pony Express, from userid 666) id E51575315; Thu, 18 Nov 2004 13:23:32 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 1CA975311; Thu, 18 Nov 2004 13:22:53 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 2E856B878; Thu, 18 Nov 2004 13:22:53 +0100 (CET) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Message-Id: <20041118122253.2E856B878@dwp.des.no> Date: Thu, 18 Nov 2004 13:22:53 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: s X-Spam-Status: No, hits=1.8 required=5.0 tests=ADDR_FREE autolearn=no version=2.64 Subject: FreeBSD Security Advisory FreeBSD-SA-04:16.fetch X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 12:23:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:16.fetch Security Advisory The FreeBSD Project Topic: Overflow error in fetch Category: core Module: fetch Announced: 2004-11-18 Credits: Colin Percival Affects: All FreeBSD versions. Corrected: 2004-11-18 12:02:13 UTC (RELENG_5, 5.3-STABLE) 2004-11-18 12:03:05 UTC (RELENG_5_3, 5.3-RELEASE-p1) 2004-11-18 12:04:29 UTC (RELENG_5_2, 5.2.1-RELEASE-p12) 2004-11-18 12:05:36 UTC (RELENG_5_1, 5.1-RELEASE-p18) 2004-11-18 12:05:50 UTC (RELENG_5_0, 5.0-RELEASE-p22) 2004-11-18 12:02:29 UTC (RELENG_4, 4.10-STABLE) 2004-11-18 12:06:06 UTC (RELENG_4_10, 4.10-RELEASE-p4) 2004-11-18 12:06:22 UTC (RELENG_4_9, 4.9-RELEASE-p13) 2004-11-18 12:06:36 UTC (RELENG_4_8, 4.8-RELEASE-p26) 2004-11-18 12:06:52 UTC (RELENG_4_7, 4.7-RELEASE-p28) FreeBSD only: YES For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The fetch(1) utility is a tool for fetching files via FTP, HTTP, and HTTPS. II. Problem Description An integer overflow condition in the processing of HTTP headers can result in a buffer overflow. III. Impact A malicious server or CGI script can respond to an HTTP or HTTPS request in such a manner as to cause arbitrary portions of the client's memory to be overwritten, allowing for arbitrary code execution. IV. Workaround There is no known workaround for the affected application, although the ftp(1) application in the FreeBSD base system, and several applications in the FreeBSD Ports collection provide similar functionality and could be used in place of fetch(1). V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_3, RELENG_5_2, RELENG_4_10, or RELENG_4_8 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.8, 4.10, 5.2, and 5.3 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch # ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/usr.bin/fetch # make obj && make depend && make && make install 3) IMPORTANT NOTE to users of FreeBSD Update: FreeBSD Update (security/freebsd-update in the FreeBSD Ports collection) is a binary security update system for the FreeBSD base system. It is not supported or endorsed by the FreeBSD Security team, but its author has requested that the following note be included in this advisory: FreeBSD Update uses the fetch(1) utility for downloading security updates to the FreeBSD base system. While these updates are cryptographically signed, and FreeBSD Update is therefore immune from most attacks, it is exposed to this vulnerability since the files must be fetched before their integrity can be verified. As a workaround, FreeBSD Update can be made to use the ftp(1) utility for downloading updates as follows: # sed -i.bak -e 's/fetch -qo/ftp -o/' /usr/local/sbin/freebsd-update # freebsd-update fetch # mv /usr/local/sbin/freebsd-update.bak /usr/local/sbin/freebsd-update # freebsd-update install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/usr.bin/fetch/fetch.c 1.10.2.28 RELENG_4_10 src/UPDATING 1.73.2.90.2.5 src/sys/conf/newvers.sh 1.44.2.34.2.6 src/usr.bin/fetch/fetch.c 1.10.2.23.2.1 RELENG_4_9 src/UPDATING 1.73.2.89.2.14 src/sys/conf/newvers.sh 1.44.2.32.2.14 src/usr.bin/fetch/fetch.c 1.10.2.21.2.1 RELENG_4_8 src/UPDATING 1.73.2.80.2.29 src/sys/conf/newvers.sh 1.44.2.29.2.27 src/usr.bin/fetch/fetch.c 1.10.2.20.2.1 RELENG_4_7 src/UPDATING 1.73.2.74.2.32 src/sys/conf/newvers.sh 1.44.2.26.2.30 src/usr.bin/fetch/fetch.c 1.10.2.18.2.1 RELENG_5 src/usr.bin/fetch/fetch.c 1.72.2.2 RELENG_5_3 src/UPDATING 1.342.2.13.2.4 src/sys/conf/newvers.sh 1.62.2.15.2.6 src/usr.bin/fetch/fetch.c 1.72.2.1.2.1 RELENG_5_2 src/UPDATING 1.282.2.20 src/sys/conf/newvers.sh 1.56.2.19 src/usr.bin/fetch/fetch.c 1.62.4.1 RELENG_5_1 src/UPDATING 1.251.2.20 src/sys/conf/newvers.sh 1.50.2.20 src/usr.bin/fetch/fetch.c 1.62.2.1 RELENG_5_0 src/UPDATING 1.229.2.28 src/sys/conf/newvers.sh 1.48.2.23 src/usr.bin/fetch/fetch.c 1.58.2.1 - ------------------------------------------------------------------------- VII. References -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBnJIEFdaIBMps37IRAm1/AKCISgScX7iQV6689Mm0jVk15pa0EgCgj1Pj WSxoiyw5dAEC6PcSpMSIgZQ= =Ikr3 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri Nov 19 20:41:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4059D16A4CE for ; Fri, 19 Nov 2004 20:41:59 +0000 (GMT) Received: from imsmta1.indosat.net.id (corp-in.indosat.net.id [202.155.50.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A0743D2D for ; Fri, 19 Nov 2004 20:41:58 +0000 (GMT) (envelope-from bcs2005@bellua.com) Received: from dis.indosat.com ([219.83.16.139]) by imsmta1.indosat.net.id (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0I7G0017X1LV5W@imsmta1.indosat.net.id> for freebsd-security@freebsd.org; Sat, 20 Nov 2004 03:44:19 +0700 (JVT) Received: (qmail 3844 invoked from network); Sat, 20 Nov 2004 03:42:02 +0700 Received: from rostra.wlan.bellua.com (HELO ?192.168.1.101?) (192.168.1.101) by dis.bellua.com with RC4-SHA encrypted SMTP; Sat, 20 Nov 2004 03:42:02 +0700 Date: Sat, 20 Nov 2004 03:41:49 +0700 From: "Anthony.zboralski" To: freebsd-security@freebsd.org Message-id: <6F993008-3A6B-11D9-8E62-000A95B1B62E@bellua.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Subject: Call for papers: Bellua Cyber Security Asia 2005 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 20:41:59 -0000 Bellua Cyber Security Asia 2005 - http://www.bellua.com/bcs2005 Call for Papers and Workshops http://www.bellua.com/bcs2005/asia05.cfp.html From 21st - 24th March the largest information security conference in Asia will take place in Jakarta, Indonesia at the Hotel Borobudur. * 21-22 March 2005: Workshops * 23-24 March 2005: Conference Bellua will bring together over 20 researchers and practitioners from numerous disciplines to discuss present and future information security issues through an intensive series of workshops, presentations, technical sessions and demonstrations. The partial list of speakers include Ralph Logan, Adam O'Donnel, David Maynor [ISS X-Force], The Grugq, Jim Geovedi [HERT], Fetri Miftach and John Grygorcewicz. Over 30 workshops will be offered and taught by the most respected experts in the field. Ethical hacking & security contests will let novices develop their skills and challenge experts in their favorite arenas, allowing all a chance to win prizes. The program committe invites proposals for paper presentations, demonstrations and poster contributions on any topic relevant to cyber security and hacking. The conference talks will be spread across 2 concurrent tracks focusing on both business and technical aspects of information security. Your submission should include: 1. Name, title, address, email and phone number 2. Draft of the proposed presentation (in PDF, PowerPoint or Keynote format), proof of concept for tools and exploits, etc. 3. Short biography, qualification, occupation, achievement and affiliations (limit 150 words). 4. Summary or abstract for your presentation (limit 150 words) 5. Time (40-60 minutes). Include time for discussion and questions 6. Technical requirements (video, internet, wireless, audio, etc.) * Each speaker will receive an honorarium, hotel accommodation, and reimbursement of travel expenses. * Posters contributors will receive one complimentary conference pass. * Please read the detailed CFP at the following URL: http://www.bellua.com/bcs2005/asia05.cfp.html Please send your proposal to cfp2005@bellua.com as soon as possible and no later than 20 December 2005. Call for Workshops proposal This is also a call for workshops. One of the objectives of this meeting is to allow researchers to gain a background in areas that they may know little about. Towards that end a number of Workshops are planned. * Again please read the detailed CFP for more information: http://www.bellua.com/bcs2005/asia05.cfp.html Please send the workshop proposal to cfp2005@bellua.com as soon as possible and no later than 20 December 2005. Phone (GMT+7): +62 815 910 2495 Thanks & regards, 1. Name, title, address, email and phone number 2. Draft of the proposed presentation (in PDF, PowerPoint or Keynote format), proof of concept for tools and exploits, etc. 3. Short biography, qualification, occupation, achievement and affiliations (limit 150 words). 4. Summary or abstract for your presentation (limit 150 words) 5. Time (40-60 minutes). Include time for discussion and questions 6. Technical requirements (video, internet, wireless, audio, etc.) * Each speaker will receive an honorarium, hotel accommodation, and reimbursement of travel expenses. * Posters contributors will receive one complimentary conference pass. * Please read the detailed CFP at the following URL: http://www.bellua.com/bcs2005/asia05.cfp.html Please send your proposal to cfp2005@bellua.com as soon as possible and no later than 20 December 2005. Call for Workshops proposal This is also a call for workshops. One of the objectives of this meeting is to allow researchers to gain a background in areas that they may know little about. Towards that end a number of Workshops are planned. * Again please read the detailed CFP for more information: http://www.bellua.com/bcs2005/asia05.cfp.html Please send the workshop proposal to cfp2005@bellua.com as soon as possible and no later than 20 December 2005. Phone: +62 815 910 2495 (WIT - GMT+7) Thanks & regards, Anthony Zboralski Bellua Asia Pacific - http://www.bellua.com/bcs2005 -- Anthony C. Zboralski PT Bellua Asia Pacific - http://www.bellua.com Bumi Daya Plaza 18th Floor, jl. Iman Bonjol No.61 Jakarta 10310 Indonesia. Phone: +62213918330 HP:+628159102495 65b1d8c7 - 6c0b b76a 51ef bfa6 c03b 97c8 af75 420c 65b1 d8c7 From owner-freebsd-security@FreeBSD.ORG Sat Nov 20 18:29:03 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31BCA16A4CE for ; Sat, 20 Nov 2004 18:29:03 +0000 (GMT) Received: from mail1.acecape.com (mail1.acecape.com [66.114.74.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A825543D31 for ; Sat, 20 Nov 2004 18:29:02 +0000 (GMT) (envelope-from lists@natserv.com) Received: from zoraida.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mail1.acecape.com (8.12.11/8.12.11) with ESMTP id iAKIT2Og028380 for ; Sat, 20 Nov 2004 13:29:02 -0500 Date: Sat, 20 Nov 2004 13:32:15 -0500 (EST) From: Francisco Reyes X-X-Sender: fran@zoraida.natserv.net To: FreeBSD Security List Message-ID: <20041120133048.N7533@zoraida.natserv.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Importing into rc.firewal rules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 18:29:03 -0000 I have a grown list of IPs that I am "deny ip from ###.### to any". Infected machines, hackers, etc.. Is there a way to have this list outside of rc.firewall and just read it in? From owner-freebsd-security@FreeBSD.ORG Sat Nov 20 20:09:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB916A4CE for ; Sat, 20 Nov 2004 20:09:07 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956E343D55 for ; Sat, 20 Nov 2004 20:09:06 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAKK926i008777; Sat, 20 Nov 2004 21:09:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Francisco Reyes From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 20 Nov 2004 13:32:15 EST." <20041120133048.N7533@zoraida.natserv.net> Date: Sat, 20 Nov 2004 21:09:02 +0100 Message-ID: <8776.1100981342@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: FreeBSD Security List Subject: Re: Importing into rc.firewal rules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 20:09:07 -0000 In message <20041120133048.N7533@zoraida.natserv.net>, Francisco Reyes writes: >I have a grown list of IPs that I am "deny ip from ###.### to any". >Infected machines, hackers, etc.. If the list is long it may be almost as good, if not better, to use blackhole routes for it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Sat Nov 20 20:15:33 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856E616A4CE for ; Sat, 20 Nov 2004 20:15:33 +0000 (GMT) Received: from smtp.infracaninophile.co.uk (happy-idiot-talk.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id A95AD43D54 for ; Sat, 20 Nov 2004 20:15:32 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1])iAKKFQVe001081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Nov 2004 20:15:26 GMT (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)iAKKFQkH001080; Sat, 20 Nov 2004 20:15:26 GMT (envelope-from matthew) Date: Sat, 20 Nov 2004 20:15:26 +0000 From: Matthew Seaman To: Francisco Reyes Message-ID: <20041120201526.GB793@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: Francisco Reyes , FreeBSD Security List References: <20041120133048.N7533@zoraida.natserv.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <20041120133048.N7533@zoraida.natserv.net> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (smtp.infracaninophile.co.uk [IPv6:::1]); Sat, 20 Nov 2004 20:15:26 +0000 (GMT) X-Virus-Scanned: ClamAV 0.80/596/Sat Nov 20 10:53:39 2004 clamav-milter version 0.80j on smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on happy-idiot-talk.infracaninophile.co.uk cc: FreeBSD Security List Subject: Re: Importing into rc.firewal rules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 20:15:33 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 20, 2004 at 01:32:15PM -0500, Francisco Reyes wrote: > I have a grown list of IPs that I am "deny ip from ###.### to any". > Infected machines, hackers, etc.. >=20 > Is there a way to have this list outside of rc.firewall and just read it= =20 > in? Sure. If you set 'firewall_type' in /etc/rc.conf to the name of a file (eg. /etc/rules.ipfw), then record your firewall ruleset as a series of 'add rule' commands inside that file, it will be read straight into ipfw(8) -- eg: # /sbin/ipfw /etc/rules.ipfw where the initial contents of the rules file could be generated from the currently loaded ruleset by: # /sbin/ipfw list | sed -e 's,^,add ,' Additionally you can use the '-p preproc' flag to pass the rules file through a preprocessor, such as m4(1) which potentially allows you to insert blocks of rules by including other files. but that requires having quite a bit of m4-fu. Alternatively, if you want to manage your list of ad-hoc deny rules separately to your standard rule set, you can just run ipfw(8) against a set of 'add' rules whenever you need to make changes. If you make use of the ipfw set command, you will be easily able to manipulate your ad-hoc rules without trashing your regular ruleset. The ipfw set functionality is available by default in RELENG_5, but it is an extension that has to be explicitly turned on in RELENG_4 -- see the section "USING IPFW2 IN FreeBSD-STABLE" within the ipfw(8) man page. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBn6XeiD657aJF7eIRAn2eAKCxhz4/qDwMEmNM0ug15UNOnuuBAwCgrt0+ o4HaMbdNEsWVkV2l9zvQxyM= =liHt -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- From owner-freebsd-security@FreeBSD.ORG Sat Nov 20 20:48:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A3C16A4CE for ; Sat, 20 Nov 2004 20:48:23 +0000 (GMT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10BDD43D53 for ; Sat, 20 Nov 2004 20:48:23 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.1/8.13.1) with ESMTP id iAKKmMY6023504 for ; Sat, 20 Nov 2004 12:48:22 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.1/8.13.1/Submit) id iAKKmMpf023503 for freebsd-security@freebsd.org; Sat, 20 Nov 2004 12:48:22 -0800 (PST) (envelope-from david) Date: Sat, 20 Nov 2004 12:48:22 -0800 (PST) From: David Wolfskill Message-Id: <200411202048.iAKKmMpf023503@bunrab.catwhisker.org> To: freebsd-security@freebsd.org In-Reply-To: <20041120133048.N7533@zoraida.natserv.net> Subject: Re: Importing into rc.firewal rules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 20:48:23 -0000 >Date: Sat, 20 Nov 2004 13:32:15 -0500 (EST) >From: Francisco Reyes >I have a grown list of IPs that I am "deny ip from ###.### to any". >Infected machines, hackers, etc.. OK.... >Is there a way to have this list outside of rc.firewall and just read it >in? Sure, if you modify rc.firewall or use a different mechanism to construct the rules. The supplied rc.firewall is a shell script; see ". file" in man sh for one way to read the contents of another file into a shell script. You could also generate the ipfw comamnds via some other (combination of) (scripting) language(s), including Perl or m4 -- as long as each such component you use is available at the time it is first invoked (rather early in the boot process). A lot is likely to depend on how dynamic the "grown list" is. Peace, david -- David H. Wolfskill david@catwhisker.org I resent spammers because spam is a DoS attack on my time. See http://www.catwhisker.org/~david/publickey.gpg for public key.