From owner-freebsd-security Sat Mar 25 12:52:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from ionet.net (mail.ionet.net [206.41.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 014E537B951 for ; Sat, 25 Mar 2000 12:52:12 -0800 (PST) (envelope-from ssamalin@ionet.net) Received: from ionet.net (ip2.bedford4.ma.pub-ip.psi.net [38.32.73.2]) by ionet.net (8.9.1a/8.9.1) with ESMTP id OAA09594 for ; Sat, 25 Mar 2000 14:52:22 -0600 (CST) Message-ID: <38DD2730.A977A6D0@ionet.net> Date: Sat, 25 Mar 2000 15:53:04 -0500 From: Sam Samalin X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: security-digest V4 #592 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe freebsd-security security-digest wrote: > security-digest Saturday, March 25 2000 Volume 04 : Number 592 > > In this issue: > Re: New article > Re: New article > Re: New article > Re: New article > Re: New article > shell issue > Re: shell issue > Re: shell issue > Deny based on IP - TCP Wrapper > Re: Deny based on IP - TCP Wrapper > Re: New article > Re: New article > Publishing Firewall Logs > > ---------------------------------------------------------------------- > > Date: Fri, 24 Mar 2000 00:58:22 -0500 > From: Will Andrews > Subject: Re: New article > > On Thu, Mar 23, 2000 at 05:41:05PM -0800, Kris Kennaway wrote: > > This is why one of the first steps in securing that box should be to give > > the modules the noschg flag. Hmm, probably this should be done by > > default, like we noschg the kernel at install-time. > > ITYM "schg". I know the kernel is installed "schg", dunno about modules. > I don't use those things anyway. :-) > > - -- > Will Andrews > GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- > ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ > G++>+++ e->++++ h! r-->+++ y? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Thu, 23 Mar 2000 23:18:40 -0800 (PST) > From: Kris Kennaway > Subject: Re: New article > > On Fri, 24 Mar 2000, Will Andrews wrote: > > > ITYM "schg". I know the kernel is installed "schg", dunno about modules. > > I don't use those things anyway. :-) > > Oops, you are of course correct :) > > Kris > > - ---- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 12:36:12 +0000 > From: Brian Somers > Subject: Re: New article > > > On Fri, 24 Mar 2000, Olaf Hoyer wrote: > > > > > Question: Is a loadable kernel module not a potential security risk? > > > > Only if your machine is insecurely configured. > > > > > Imagine some attacker exchanging some kernel module against own code, and > > > causing that module to be loaded (say, some driver for access to certain > > > filesystems, or zip drive etc...), or waiting for the module to be loaded > > > (say, for regular, scheduled activities like backups or batch jobs or so) > > > > This is why one of the first steps in securing that box should be to give > > the modules the noschg flag. Hmm, probably this should be done by > > default, like we noschg the kernel at install-time. > > The same should be done to the directory itself. Ditto for /bin, > /usr/bin, /sbin, /usr/sbin etc - in fact, anything that's in roots > path. > > And what about /etc/{*passwd,*pwd.db} ? Methinks this is a large > can of worms ! > > > Kris > > > > ---- > > In God we Trust -- all others must submit an X.509 certificate. > > -- Charles Forsythe > - -- > Brian > > Don't _EVER_ lose your sense of humour ! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 15:02:35 +0100 > From: Olaf Hoyer > Subject: Re: New article > > > >> I mean, if some module (which runs on a deeper, priviliged mode) has some > >> malicous code in it, or simply is buggy, and is loaded during runtime, it > >> could cause a box to simply crash. > > > >What's the difference between a buggy module loaded at runtime, and one > >compiled in the kernel? > If you do it yourself-nothing. > If someone other is doing/causing this, there is some annoyance. > > > > >As for malicious code... what are you doing loading such a module??? :-) > > > >> Imagine some attacker exchanging some kernel module against own code, and > >> causing that module to be loaded (say, some driver for access to certain > >> filesystems, or zip drive etc...), or waiting for the module to be loaded > >> (say, for regular, scheduled activities like backups or batch jobs or so) > > > >So??? If the hacker compromised root, he can just replace the whole > >kernel if he wants. *IF ROOT WAS COMPROMISED, THE GAME IS OVER ALREADY*. > >Really. No, I mean it. There is no such thing as "making things easier" > >once root was compromised. You lost, and any attempt to "make things > >difficult" is an exercise in self-delusion. > > Fully agreed. If an attacker has gained root, then its game over. > > My point was aimed at the possibility, that (most probably in misconfigured > systems) an attacker could exchange existing kernel modules against > malicious ones, given the case that writing/changing rights to that > directory are not banned for everyone except root. > > I also had in mind, that there is no 100% security, and that there always > are bugs, some daemons with some superior access rights, and perhaps some > users except root, that al least have some access under certain > circumstances, i.e. backup operators. (Ok, thats more likely for NT, I know) > > I also know, that most security holes come from human failure or foolishness. > I wanted to point out, that there is/could be some very _remote_ > possibility that such a mechanism could be used, if someone is creative > enough, and the system unsecure enough. > > Problem is, that you not intend in all cases to crash the server. This can > be done with other, easier methods. > > > Imagine some code, that spies out your data, and transmits copies over the net? > Device drivers (say, for SCSI/tape drives etc) are perfect for that. > The driver has to sniff for some code snippets, and trensfer that chunk of > data to some remote location... > > > Yes, I know, that this would be a theoretical, constructed example, that > you could neglect in todays scenery. But what about in some years? > > Lets move that to -security, if further discussion is desired. > > Regards > Olaf Hoyer > - -------- > Olaf Hoyer www.nightfire.de mailto:Olaf.Hoyer@nightfire.de > FreeBSD- Turning PC's into workstations ICQ:22838075 > > Liebe und Hass sind nicht blind, aber geblendet vom Feuer, > dass sie selber mit sich tragen. (Nietzsche) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 16:41:46 +0100 > From: Harold Gutch > Subject: Re: New article > > On Fri, Mar 24, 2000 at 05:46:27PM +0900, Daniel C. Sobral wrote: > > Olaf Hoyer wrote: > > > Imagine some attacker exchanging some kernel module against own code, and > > > causing that module to be loaded (say, some driver for access to certain > > > filesystems, or zip drive etc...), or waiting for the module to be loaded > > > (say, for regular, scheduled activities like backups or batch jobs or so) > > > > So??? If the hacker compromised root, he can just replace the whole > > kernel if he wants. *IF ROOT WAS COMPROMISED, THE GAME IS OVER ALREADY*. > > Really. No, I mean it. There is no such thing as "making things easier" > > once root was compromised. You lost, and any attempt to "make things > > difficult" is an exercise in self-delusion. > > I'd say that depends on how paranoid you were when chflag-ing > various files and directories, like /kernel, /boot, /etc/rc.*, > /lkm etc.. Of course that won't buy you anything unless you're > running in secure level 1 or higher. security(7) is a nice > introduction to this. > I have to agree though that I wouldn't trust a (root-)compromised > machine anymore and would re-install it. Nevertheless I still > somehow doubt that an attacker could inject arbitrary code into > the kernel on an otherwise correctly configured box, which then > also implies "chflags -R /usr/src/sys schg" for example (and I'm > sure I've forgotten a couple of other things here as well). > > bye, > Harold > > - -- > Someone should do a study to find out how many human life spans have > been lost waiting for NT to reboot. > Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 18:35:47 +0200 (EET) > From: Dungeonkeeper > Subject: shell issue > > Hi there, > > First of all: I want to apologise for my poor english. > > Today me and a few friends of mine discussed the shells' (well, shell is > actualy one of: sh/bash/csh/tcsh... not tested for ksh) command line expansion > routines, mainly because of a problem discovered by one of my friends. I'm not > sure if this is something new... So, let me explain what he found. It seems > that the shell wants to allocate enough memory to hold the entire command line > when expanding all of the arguments and we can force it to allocate hudge > ammount of memory with a tricky command like this: > > carnivoro# /bin/csh -c `cat /dev/urandom` > > (I use tcsh here (the carnivoro# prompt), but the same thing happens when > testing with sh/bash/tcsh) In this situation, the shell tries to allocate enough > memory to hold what it > reads from /dev/urandom, because it must be passed as a command line argument > to /bin/csh ( actually, any command will be ok ). So, the shell eats more and > more memory (on my machine (3.4-STABLE) - 251 MB) before the kernel decided to > take some action (like killing some processes... started by other users? > system services? or... in my case... crash :). My friend said that he sent a > mail to bugtraq describing this problem. Those who are interested can read it. > > I believe that the shells have a maximum command lenght, so... I'm trying now > to make the shell use the same command lenght when expanding such commands. I > think this is the best way to avoid this problem. Any ideas? > > Best regards: zethix > > What is worth doing is worth the trouble of asking somebody to do. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 11:43:35 -0600 > From: Dan Nelson > Subject: Re: shell issue > > In the last episode (Mar 24), Dungeonkeeper said: > > I believe that the shells have a maximum command lenght, so... I'm > > trying now to make the shell use the same command lenght when > > expanding such commands. I think this is the best way to avoid this > > problem. Any ideas? > > The kernel has a maximum command-line length, but it that only gets > checked when an external executable is run. Something like > > echo `cat /dev/urandom` > > would still work, since echo is usually a shell builtin command. > > The better way to stop malicious people from using up all your memory > is to specify a datasize limit in /etc/login.conf . > > - -- > Dan Nelson > dnelson@emsphone.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 10:04:25 -0800 (PST) > From: Matthew Dillon > Subject: Re: shell issue > > :Hi there, > : > :First of all: I want to apologise for my poor english. > : > :Today me and a few friends of mine discussed the shells' (well, shell is > :actualy one of: sh/bash/csh/tcsh... not tested for ksh) command line expansion > :routines, mainly because of a problem discovered by one of my friends. I'm not > :sure if this is something new... So, let me explain what he found. It seems > :that the shell wants to allocate enough memory to hold the entire command line > :when expanding all of the arguments and we can force it to allocate hudge > :ammount of memory with a tricky command like this: > : > :carnivoro# /bin/csh -c `cat /dev/urandom` > > You can trivially write any program to allocate memory continuously. > This isn't really a security problem with shells. If you want to cap > memory useage you can set a datasize limit. It doesn't cap everything > (i.e. it doesn't cap mmap() use), but it does cover the most common > mistakes that users make. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 18:19:41 -0500 (EST) > From: Michael DeMutis > Subject: Deny based on IP - TCP Wrapper > > I went to the ports collection and tried to install the TCP Wrapper. > > tristo# make install > ===> tcp_wrappers-7.6 is forbidden: tcp_wrappers is in the base system. > tristo# > > It says it is in the base system. > > If that is the case, then how do I enable its use? > > I'd like to block telnet access based on IP. > > - -mike > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 16:17:44 -0600 > From: Brad Guillory > Subject: Re: Deny based on IP - TCP Wrapper > > You should look in man under hosts_options(5) and the files > /etc/hosts.allow. > > The /etc/hosts.deny file is no longer used so if someone point you there > just ignore them ;-). Check out the man pages though or if you are > impatient there is probably enough info in the hosts.allow file > to get going. > > Have fun, BMG > > On Fri, Mar 24, 2000 at 06:19:41PM -0500, Michael DeMutis wrote: > > > > I went to the ports collection and tried to install the TCP Wrapper. > > > > tristo# make install > > ===> tcp_wrappers-7.6 is forbidden: tcp_wrappers is in the base system. > > tristo# > > > > It says it is in the base system. > > > > If that is the case, then how do I enable its use? > > > > I'd like to block telnet access based on IP. > > > > -mike > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > - -- > __O > _-\<,_ Why drive when you can bike? > (_)/ (_) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 20:38:18 -0700 > From: Warner Losh > Subject: Re: New article > > In message <200003241236.MAA02043@hak.lan.Awfulhak.org> Brian Somers writes: > : The same should be done to the directory itself. Ditto for /bin, > : /usr/bin, /sbin, /usr/sbin etc - in fact, anything that's in roots > : path. > > And /usr/lib, and all the files in the above directories (since they > can still be changed via hard links). And all the config files that > are in /etc or /usr/local/etc. Anything that is touched before the > security level is raised needs to be protected as well. Don't forget > all modules. Oh, /usr/local/sbin also appears in the default path. > Directories created under the /usr/local mountmount might be a good > way to drive a wedge in. Also under /usr to a lessor extent. > ccdconfig is run if /etc/ccd.conf exists, but the path has it first, > so it isn't too bad. /etc/rc.conf and /etc/defaults/rc.conf are good > ones to attack as well. Well, all the /etc/rc* files. > > If one could create a /sbin/rpc.umntall, then it would be run instead > of rpc.umntall. Well, there are others too. > > : And what about /etc/{*passwd,*pwd.db} ? Methinks this is a large > : can of worms ! > > Can't do those and still expect users to be able to change their > passwords. > > Big big can of words... > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Fri, 24 Mar 2000 20:41:18 -0700 > From: Warner Losh > Subject: Re: New article > > In message <20000324164146.A18107@foobar.franken.de> Harold Gutch writes: > : I'd say that depends on how paranoid you were when chflag-ing > : various files and directories, like /kernel, /boot, /etc/rc.*, > : /lkm etc.. Of course that won't buy you anything unless you're > : running in secure level 1 or higher. security(7) is a nice > : introduction to this. > > Of course it won't buy you anything. Full stop. Much of the boot > process executes at secure level 0, which means if you can compromize > even one file in the boot chain, you'll be able to do anything you > want. > > : I have to agree though that I wouldn't trust a (root-)compromised > : machine anymore and would re-install it. Nevertheless I still > : somehow doubt that an attacker could inject arbitrary code into > : the kernel on an otherwise correctly configured box, which then > : also implies "chflags -R /usr/src/sys schg" for example (and I'm > : sure I've forgotten a couple of other things here as well). > > Don't put source on secure machines. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > Date: Sat, 25 Mar 2000 10:31:10 -0800 > From: "John Fitzgibbon" > Subject: Publishing Firewall Logs > > I decided to start publishing my firewall logs on the web > http://63.194.217.126/logs/ > > My thinking is that to identify the root, (excuse the pun), source of > distributed attacks, administrators need access to a broad set of logs. If > you can identify IP addresses that were banging on a lot of doors, (or > banging on a particular door), prior to an attack, you should be able to > narrow the search. My firewall box doesn't have anything much running on it > and I don't use it to store anything sensitive, so I thought, "why not make > the logs available?". I'm aware of the obvious counter-argument that any > information you make available creates a risk. > > This is basically what I'm looking for feedback on -- Is this information > useful? Is this a dumb idea? What specific vulnerabilities am I creating? > > John Fitzgibbon. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > ------------------------------ > > End of security-digest V4 #592 > ****************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message