Date: Sat, 25 Mar 2000 15:53:04 -0500 From: Sam Samalin <ssamalin@ionet.net> To: security@FreeBSD.ORG Subject: Re: security-digest V4 #592 Message-ID: <38DD2730.A977A6D0@ionet.net> References: <bulk.35559.20000325103353@hub.freebsd.org>
index | next in thread | previous in thread | raw e-mail
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 <andrews@technologist.com>
> 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 <andrews@technologist.com>
> 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 <kris@FreeBSD.org>
> 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 <forsythe@alum.mit.edu>
>
> 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 <brian@Awfulhak.org>
> 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 <forsythe@alum.mit.edu>
> - --
> Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
> <http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
> 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 <ohoyer@fbwi.fh-wilhelmshaven.de>
> Subject: Re: New article
>
> <snip>
> >> 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.
>
> <paranoia>
> 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...
> </paranoia>
>
> 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 <logix@foobar.franken.de>
> 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 <zethix@sofiaonline.com>
> 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 <dnelson@emsphone.com>
> 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 <dillon@apollo.backplane.com>
> 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 <mike@2Gen.net>
> 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 <round@baileylink.net>
> 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 <imp@village.org>
> 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 <imp@village.org>
> 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" <fitz@jfitz.com>
> 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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38DD2730.A977A6D0>