rlinetd security
Hello, I found out that rlinetd seems like a great replacement for inetd, because it lets you choose which services may be available for the outside world and which only for the inner network. So, standard services like echo, daytime, chargen, ftp, etc. are only available for the LAN, while it is not possible to connect to these ports from the internet. But, how secure is this? Is it really what it seems? Thanks in advance, Sebastiaan -- NT is the OS of the future. The main engine is the 16-bit Subsystem (also called MS-DOS Subsystem). Above that, there is the windoze 95/98 16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a *real* 32-bit system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange flickering ports
On Mon, Jun 18, 2001 at 09:14:54AM +0200, Sebastiaan wrote: > >Hi... > > > >I have a box with something listening to "flickering" ports. nmap > >reports various random ports open from run to run. I can't telnet to > >them and ID w/ netstat, because they're gone the instant nmap finds > >them. > Hi, > > I have this regularily too. I would like to see this explained, but > perhaps it is just an error in nmap? I've seen this too. My inital guess was that these were incoming ftp ports from active ftp sessions but that didn't really make sense on this particular box. Then I think I upgraded nmap and the problem seemed to go away. > > Greetz, > Sebastiaan > > > > > -- > NT is the OS of the future. The main engine is the 16-bit Subsystem > (also called MS-DOS Subsystem). Above that, there is the windoze 95/98 > 16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a > *real* 32-bit system. > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- John Ferlito Senior Engineer - Bulletproof Networks ph: +61 (0) 410 519 382 http://www.bulletproof.net.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
re: strange flickering ports
>Hi... > >I have a box with something listening to "flickering" ports. nmap >reports various random ports open from run to run. I can't telnet to >them and ID w/ netstat, because they're gone the instant nmap finds >them. Hi, I have this regularily too. I would like to see this explained, but perhaps it is just an error in nmap? Greetz, Sebastiaan -- NT is the OS of the future. The main engine is the 16-bit Subsystem (also called MS-DOS Subsystem). Above that, there is the windoze 95/98 16-bit Subsystem. Anyone can see that 16+16=32, so windoze NT is a *real* 32-bit system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Tim Potter <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG writes: > > > In this case, there needs to be a non-older version of mailcrypt > > available for potato. I don't know why conflicts were added to > > mailcrypt (nothing I noticed in either the public or private security > > lists mentioned it, AFAICT). But assuming the conflicts are needed, > > the security team needs to upload a working recent mailcrypt to the > > security.debian.org archive. > > I expect it is because the mailcrypt module can't seem to parse > the output of gpg versions > 1.0.4 when trying to decrypt > messages. From memory, the output format for --list-secret-keys > has been changed. Ok, that's a fine reason. But then the working mailcrypt needs to be installed, or the security fix has only been half-done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Thomas Bushnell BSG writes: > In this case, there needs to be a non-older version of mailcrypt > available for potato. I don't know why conflicts were added to > mailcrypt (nothing I noticed in either the public or private security > lists mentioned it, AFAICT). But assuming the conflicts are needed, > the security team needs to upload a working recent mailcrypt to the > security.debian.org archive. I expect it is because the mailcrypt module can't seem to parse the output of gpg versions > 1.0.4 when trying to decrypt messages. From memory, the output format for --list-secret-keys has been changed. Tim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
I like the package signing idea. That would be cool. That way, you could still load and unload modules. I like being able to do that. One obvious problem with the scheme is that an attacker could potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and sign their own module. This can be overcome if we give up the ability to compile more modules for that kernel after we finish compiling it: - Generate a key pair during kernel compilation (RSA would be a good alg. for this). - Sign the modules with one half of the key pair. - store the other half of the key pair in the kernel image. - _delete_ all traces of the key used to sign the modules. All that's needed to make this workable is to find a way to provide access to IO/device memory space for X11 without allowing read/write access to kernel memory. This can't really be all that hard. I think the kernel can tell when the memory address written to or mapped in /dev/mem is part of kernel memory by checking where the kernel is in memory. A very restrictive raw mem device that only allowed processes to map PCI memory space, or maybe just PCI memory space that PCI devices reported in their configuration info, would do the job for X11. (BTW, AGP acts like another PCI bus). Limiting things to only PCI-reported memory spaces would stop access from user space to ISA memory, but who would want to do that anyway... I like this idea. It would kick ass, so we should do it. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > > I like the package signing idea. That would be cool. That way, you > > could still load and unload modules. I like being able to do that. > > One obvious problem with the scheme is that an attacker could > > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > > sign their own module. This can be overcome if we give up the ability > > how? the kernel does not need the private key to verify the > signature. You need to keep it somewhere if you ever want to build more modules that that kernel will load. I don't know why I assumed it would be stored in the kernel image. > > replacing the kernel image and rebooting would be another way to get > around this. as would injecting code into /dev/mem. > > > to compile more modules for that kernel after we finish compiling it: > > - Generate a key pair during kernel compilation (RSA would be a good > > alg. for this). > > - Sign the modules with one half of the key pair. > > - store the other half of the key pair in the kernel image. > > - _delete_ all traces of the key used to sign the modules. > > yup > Hmm, if you compiled on a separate machine, or kept the key on a floppy, you could do make change the last step to "get all traces of the key off the 'secure' machine". > > All that's needed to make this workable is to find a way to provide > > access to IO/device memory space for X11 without allowing read/write > > access to kernel memory. This can't really be all that hard. I think > > the kernel can tell when the memory address written to or mapped in > > /dev/mem is part of kernel memory by checking where the kernel is in > > memory. A very restrictive raw mem device that only allowed processes > > to map PCI memory space, or maybe just PCI memory space that PCI > > devices reported in their configuration info, would do the job for > > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > > PCI-reported memory spaces would stop access from user space to ISA > > memory, but who would want to do that anyway... > > this would be a good idea anyway, it might reduce the possiblity of X > killing the entire box whenever it hiccups and scribbles random > memory. Yes, that's what I was thinking too. > > > I like this idea. It would kick ass, so we should do it. > > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). > > otherwise the attacker can just replace your kernel image and reboot > (which is of course fairly noticable). exactly. starting with the signing and IO protecting would be a very good start. As for secure block devs, you could have the kernel drop the ability to write to certain partitions of certain disks, or something like that. Blocking writes to mounted partitions wouldn't help for partitions that can be unmounted and remounted easily. (writes to the whole-drive block devices would have to go through the same checks, or maybe even be blocked entirely if they fell within space allocated to a partition.) If this got done, the signing idea would kick ass. As it is, it's just pretty good... -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote: > you would need to fix filesystem immutability and block device access > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there > is no way to deny root the ability to write directly to /dev/hda* and > remove the immutable bits (ive written a script to remove chattr +i > and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, > no reboot required). I thought CAP_SYS_RAWIO would take care of that issue? Is is still possible to chattr +i if CAP_SYS_RAWIO is removed? Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gnupg problem
The new gnupg made it to security.debian.org, but it includes a conflict with the only available mailcrypt: Conflicts: gpg-rsa, gpg-rsaref, mailcrypt (<= 3.5.5-6) The changelog.Debian agrees: gnupg (1.0.6-0potato1) stable; urgency=high * Upload for stable; fixes several security holes. * debian/postinst: Restore suidregister handling * debian/control: remove conflicts with suidmanager and add conflicts with older versions of mailcrypt. In this case, there needs to be a non-older version of mailcrypt available for potato. I don't know why conflicts were added to mailcrypt (nothing I noticed in either the public or private security lists mentioned it, AFAICT). But assuming the conflicts are needed, the security team needs to upload a working recent mailcrypt to the security.debian.org archive. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are these breakin attempts?
On Mon, Jun 18, 2001 at 03:46:13PM +1000, Ian Miller wrote: > add the line /sbin/ipchains -A input -i -p TCP -s ! > -d 111 -l -j DENY to block the rpc statd attacks > from your external network port 111 is portmap, not rpc.statd. all blocking portmap will do is prevent them from conveniently getting the statd port number, that doesn't stop them from finding it via nmap. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote: > I like the package signing idea. That would be cool. That way, you > could still load and unload modules. I like being able to do that. > One obvious problem with the scheme is that an attacker could > potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and > sign their own module. This can be overcome if we give up the ability how? the kernel does not need the private key to verify the signature. replacing the kernel image and rebooting would be another way to get around this. as would injecting code into /dev/mem. > to compile more modules for that kernel after we finish compiling it: > - Generate a key pair during kernel compilation (RSA would be a good > alg. for this). > - Sign the modules with one half of the key pair. > - store the other half of the key pair in the kernel image. > - _delete_ all traces of the key used to sign the modules. yup > All that's needed to make this workable is to find a way to provide > access to IO/device memory space for X11 without allowing read/write > access to kernel memory. This can't really be all that hard. I think > the kernel can tell when the memory address written to or mapped in > /dev/mem is part of kernel memory by checking where the kernel is in > memory. A very restrictive raw mem device that only allowed processes > to map PCI memory space, or maybe just PCI memory space that PCI > devices reported in their configuration info, would do the job for > X11. (BTW, AGP acts like another PCI bus). Limiting things to only > PCI-reported memory spaces would stop access from user space to ISA > memory, but who would want to do that anyway... this would be a good idea anyway, it might reduce the possiblity of X killing the entire box whenever it hiccups and scribbles random memory. > I like this idea. It would kick ass, so we should do it. you would need to fix filesystem immutability and block device access as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there is no way to deny root the ability to write directly to /dev/hda* and remove the immutable bits (ive written a script to remove chattr +i and +a even when CAP_LINUX_IMMUTABLE is removed from the bounding set, no reboot required). otherwise the attacker can just replace your kernel image and reboot (which is of course fairly noticable). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: rxvt exploit
On Sat, Jun 16, 2001 at 06:25:32AM -0800, Ethan Benson wrote: > On Sat, Jun 16, 2001 at 10:14:52AM -0400, Ehsan (Shawn) Baseri wrote: > > Just saw this, thought you guys might be interested. Not sure how > > damaging the exploit is though. > > you get gid=utmp, which lets you corrupt the utmp database. overall > not that big a deal but could cause some fair ammount of problems. I think I saw someone say a while ago that getting write access to utmp and/or wtmp was a bigger deal than it looked, because some other programs trust the structure of the file, and you could potentially exploit other programs through utmp. This is especially important if these other programs are being run by root. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Are these breakin attempts?
On Mon, Jun 18, 2001 at 03:06:14AM +0200, Christian Jaeger wrote: > Hello, > > I run a pc with potato on a cable modem line. Recently I discovered > the following in /var/log/messages: > > Jun 10 20:21:16 pflanze -- MARK -- > Jun 10 20:33:55 pflanze > Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for > ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 failed attempt to exploit an OLD hole in rpc.statd. if it had suceeded you would not have seen the format strings above (%8x%8x...) if your not using nfs remove nfs-kernel-server and nfs-common, you don't need them. if you have no other rpc services disable portmap (apt-get remove portmap in woody, in potato rm /etc/rcS.d/*portmap) and always make sure you have security.debian.org in your sources.list (uncommented) and check for updates at least once a week. you have the nfs security updates installed since the exploit failed. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpZ30biU24im.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote: > On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > > > compiling without module support would be mostly the same as just > > > > lcap CAP_SYS_MODULE > > > Fwiw, I have heard (though not tested myself) that even if you compile > your kernel _without_ loadable module support, you will still be able > to insert modules into the running kernel. well sort of. its not quite as simple as just loading the module. you have to manually insert the code into the running kernel and manually modify kernel memory through /dev/mem. > Again I have not tried this myself, but something to test for before > relying on a certain behavior. my lcap CAP_SYS_MODULE trick doesn't do you much good without disabling /dev/mem since its really quite trivial to go into /dev/mem and twiddle the bits of memory containing the capability bounding set. there is no example code to do this, but its explained on bugtraq quite some time ago. i think it could be done with only a couple lines of C. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpC0CtFtRic5.pgp Description: PGP signature
No Subject
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > Hello > > Do you know about LIDS (www.lids.org)? It also gives the ability to > play with CAP's, but seems much more sophisticated. > > I've just subscribed to this list. Has LIDS been discussed here before? a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. > correct), rather than effectively inhibiting a breakin. But even for > this purpose it seems you have to secure almost every file in your > system with ACL's (which is not very comfortable). Maybe this idea > from mine is working well: install some special binaries to which you > grant many permissions. One is an 'apt-get update/upgrade' wrapper > (so automatic security updates work), another one might be a shell > wrapper allowing system administrators to work on /etc, and so on. I > think I'll ask this on the lids list later if that's the better place > for such discussions. the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. system adminsitrator == root cracker == root you can't trust one without trusting the other. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpdRJiJHkVy6.pgp Description: PGP signature
Re: Creating a logfile for Netfilter
On Fri, Jun 15, 2001 at 08:30:37PM +0200, Jean-Marc Boursot wrote: > On Friday 15 June 2001 16:32, Stefan Srdic wrote: > > > > > > If you create a user defined chain something like the following: > > > > > > iptables -N log_droped > > > iptables -A log_droped -j LOG --log-level 1 --log-prefix > > > "droped_::" iptables -A log_droped -j DROP > > > > > > And make all your firewall rules that need to be dropped -j (jump) > > > to this chain then they will be logged at log-level 1 (Alert). > > > > > > Then, if you edit /etc/syslog.conf and append the following line: > > > kern.=alert -/var/log/firewall.log > > > (Nb. line up with tabs) > > > > > > Then syslog will log all logs at level alert to the separate file. > > > Not much else gets logged at level alert so it should be OK and not > > > upset other logging. > > Isn't there a problem? Logs at level notice (5) and below are sent to > the console. If host activity is too high, console will become unusable > (kind of DoS). Use the magic sysrequest key to change to console log level, or use setterm -msglevel. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: Are these breakin attempts?
add the line /sbin/ipchains -A input -i -p TCP -s ! -d 111 -l -j DENY to block the rpc statd attacks from your external network - Original Message - From: "Christian Jaeger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 18, 2001 11:06 AM Subject: Are these breakin attempts? Hello, I run a pc with potato on a cable modem line. Recently I discovered the following in /var/log/messages: Jun 10 20:21:16 pflanze -- MARK -- Jun 10 20:33:55 pflanze Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%1 37x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220 Jun 10 20:33:55 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 10 21:01:16 pflanze -- MARK -- Jun 11 13:41:16 pflanze -- MARK -- Jun 11 13:47:10 pflanze Jun 11 13:47:10 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%1 37x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220 Jun 11 13:47:10 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 11 14:01:16 pflanze -- MARK -- Jun 12 09:01:16 pflanze -- MARK -- Jun 12 09:09:47 pflanze Jun 12 09:09:47 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220 Jun 12 09:09:47 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 12 09:21:16 pflanze -- MARK -- Seems like a buffer overflow. (Is it happening in rpc.statd or in named or somewhere else?) I've now removed nfs-common && nfs-server. (BTW there's still running a daemon (portmap, from netbase) on the sunrpc port - I thought sunrpc is only (mainly?) for NFS?) After that I've installed ippl, which gives some interesting output as well: Jun 17 04:13:24 asp connection attempt from ACBDC962.ipt.aol.com [172.189.201.98] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 11:04:36 webcache connection attempt from ppp45-net1-idf2-bas1.isdnet.net [195.154.50.45] Jun 17 18:14:47 sunrpc connection attempt from h24-79-83-253.vc.shawcable.net [24.79.83.253] Jun 17 18:17:07 sunrpc connection attempt from skola8.zakladni-skola.cz [62.1
Re: A question about Knark and modules
I like the package signing idea. That would be cool. That way, you could still load and unload modules. I like being able to do that. One obvious problem with the scheme is that an attacker could potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and sign their own module. This can be overcome if we give up the ability to compile more modules for that kernel after we finish compiling it: - Generate a key pair during kernel compilation (RSA would be a good alg. for this). - Sign the modules with one half of the key pair. - store the other half of the key pair in the kernel image. - _delete_ all traces of the key used to sign the modules. All that's needed to make this workable is to find a way to provide access to IO/device memory space for X11 without allowing read/write access to kernel memory. This can't really be all that hard. I think the kernel can tell when the memory address written to or mapped in /dev/mem is part of kernel memory by checking where the kernel is in memory. A very restrictive raw mem device that only allowed processes to map PCI memory space, or maybe just PCI memory space that PCI devices reported in their configuration info, would do the job for X11. (BTW, AGP acts like another PCI bus). Limiting things to only PCI-reported memory spaces would stop access from user space to ISA memory, but who would want to do that anyway... I like this idea. It would kick ass, so we should do it. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rxvt exploit
On Sat, Jun 16, 2001 at 06:25:32AM -0800, Ethan Benson wrote: > On Sat, Jun 16, 2001 at 10:14:52AM -0400, Ehsan (Shawn) Baseri wrote: > > Just saw this, thought you guys might be interested. Not sure how > > damaging the exploit is though. > > you get gid=utmp, which lets you corrupt the utmp database. overall > not that big a deal but could cause some fair ammount of problems. I think I saw someone say a while ago that getting write access to utmp and/or wtmp was a bigger deal than it looked, because some other programs trust the structure of the file, and you could potentially exploit other programs through utmp. This is especially important if these other programs are being run by root. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are these breakin attempts?
On Mon, Jun 18, 2001 at 03:06:14AM +0200, Christian Jaeger wrote: > Hello, > > I run a pc with potato on a cable modem line. Recently I discovered > the following in /var/log/messages: > > Jun 10 20:21:16 pflanze -- MARK -- > Jun 10 20:33:55 pflanze > Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for > >^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 failed attempt to exploit an OLD hole in rpc.statd. if it had suceeded you would not have seen the format strings above (%8x%8x...) if your not using nfs remove nfs-kernel-server and nfs-common, you don't need them. if you have no other rpc services disable portmap (apt-get remove portmap in woody, in potato rm /etc/rcS.d/*portmap) and always make sure you have security.debian.org in your sources.list (uncommented) and check for updates at least once a week. you have the nfs security updates installed since the exploit failed. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote: > On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > > > compiling without module support would be mostly the same as just > > > > lcap CAP_SYS_MODULE > > > Fwiw, I have heard (though not tested myself) that even if you compile > your kernel _without_ loadable module support, you will still be able > to insert modules into the running kernel. well sort of. its not quite as simple as just loading the module. you have to manually insert the code into the running kernel and manually modify kernel memory through /dev/mem. > Again I have not tried this myself, but something to test for before > relying on a certain behavior. my lcap CAP_SYS_MODULE trick doesn't do you much good without disabling /dev/mem since its really quite trivial to go into /dev/mem and twiddle the bits of memory containing the capability bounding set. there is no example code to do this, but its explained on bugtraq quite some time ago. i think it could be done with only a couple lines of C. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: > Hello > > Do you know about LIDS (www.lids.org)? It also gives the ability to > play with CAP's, but seems much more sophisticated. > > I've just subscribed to this list. Has LIDS been discussed here before? a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. > correct), rather than effectively inhibiting a breakin. But even for > this purpose it seems you have to secure almost every file in your > system with ACL's (which is not very comfortable). Maybe this idea > from mine is working well: install some special binaries to which you > grant many permissions. One is an 'apt-get update/upgrade' wrapper > (so automatic security updates work), another one might be a shell > wrapper allowing system administrators to work on /etc, and so on. I > think I'll ask this on the lids list later if that's the better place > for such discussions. the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. system adminsitrator == root cracker == root you can't trust one without trusting the other. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior.
Re: Are these breakin attempts?
Yes, they are likely breakin attempts. Why in the *world* are you running rpc.statd (or portmap, or...nevermind...some people can't be helped) on a publicly accessable machine. That's flat out stupid. Ken Seefried, CISSP Christian Jaeger writes: Hello, I run a pc with potato on a cable modem line. Recently I discovered the following in /var/log/messages: Jun 10 20:21:16 pflanze -- MARK -- Jun 10 20:33:55 pflanze Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n %137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\ Jun 10 20:33:55 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 10 21:01:16 pflanze -- MARK -- Jun 11 13:41:16 pflanze -- MARK -- Jun 11 13:47:10 pflanze Jun 11 13:47:10 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n %137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\2 20\220\220\220\220\220\220\220\220\220\220\220\220\ Jun 11 13:47:10 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 11 14:01:16 pflanze -- MARK -- Jun 12 09:01:16 pflanze -- MARK -- Jun 12 09:09:47 pflanze Jun 12 09:09:47 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn\220\22 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ 220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 12 09:09:47 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 12 09:21:16 pflanze -- MARK -- Seems like a buffer overflow. (Is it happening in rpc.statd or in named or somewhere else?) I've now removed nfs-common && nfs-server. (BTW there's still running a daemon (portmap, from netbase) on the sunrpc port - I thought sunrpc is only (mainly?) for NFS?) After that I've installed ippl, which gives some interesting output as well: Jun 17 04:13:24 asp connection attempt from ACBDC962.ipt.aol.com [172.189.201.98] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 11:04:36 webcache connection attempt from ppp45-net1-idf2-bas1.isdnet.net [195.154.50.45] Jun 17 18:14:47 sunrpc connection attempt from h24-79-83-253.vc.shawcable.net [24.79.83.253] Jun 17 18:17:07 sunrpc connection attempt from skola8.zakladni-skola.cz [62.168.55.246] Jun 18 00:07:26 port 445 connection attempt from 62.2.179.7 Jun 18 00:07:26 port 445 connection attempt from [62.2.179.7] Jun 18 00:07:27 port 445 connection attempt from [62.2.179.7] Now when I think about it these will probably all be harmless (maybe others on this cable modem subnet were serving stuff when they had my ip). If yes, please apologize my anxiety. .christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating a logfile for Netfilter
On Fri, Jun 15, 2001 at 08:30:37PM +0200, Jean-Marc Boursot wrote: > On Friday 15 June 2001 16:32, Stefan Srdic wrote: > > > > > > If you create a user defined chain something like the following: > > > > > > iptables -N log_droped > > > iptables -A log_droped -j LOG --log-level 1 --log-prefix > > > "droped_::" iptables -A log_droped -j DROP > > > > > > And make all your firewall rules that need to be dropped -j (jump) > > > to this chain then they will be logged at log-level 1 (Alert). > > > > > > Then, if you edit /etc/syslog.conf and append the following line: > > > kern.=alert -/var/log/firewall.log > > > (Nb. line up with tabs) > > > > > > Then syslog will log all logs at level alert to the separate file. > > > Not much else gets logged at level alert so it should be OK and not > > > upset other logging. > > Isn't there a problem? Logs at level notice (5) and below are sent to > the console. If host activity is too high, console will become unusable > (kind of DoS). Use the magic sysrequest key to change to console log level, or use setterm -msglevel. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Are these breakin attempts?
Hello, I run a pc with potato on a cable modem line. Recently I discovered the following in /var/log/messages: Jun 10 20:21:16 pflanze -- MARK -- Jun 10 20:33:55 pflanze Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 10 20:33:55 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 10 21:01:16 pflanze -- MARK -- Jun 11 13:41:16 pflanze -- MARK -- Jun 11 13:47:10 pflanze Jun 11 13:47:10 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 11 13:47:10 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 11 14:01:16 pflanze -- MARK -- Jun 12 09:01:16 pflanze -- MARK -- Jun 12 09:09:47 pflanze Jun 12 09:09:47 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 12 09:09:47 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 12 09:21:16 pflanze -- MARK -- Seems like a buffer overflow. (Is it happening in rpc.statd or in named or somewhere else?) I've now removed nfs-common && nfs-server. (BTW there's still running a daemon (portmap, from netbase) on the sunrpc port - I thought sunrpc is only (mainly?) for NFS?) After that I've installed ippl, which gives some interesting output as well: Jun 17 04:13:24 asp connection attempt from ACBDC962.ipt.aol.com [172.189.201.98] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 11:04:36 webcache connection attempt from ppp45-net1-idf2-bas1.isdnet.net [195.154.50.45] Jun 17 18:14:47 sunrpc connection attempt from h24-79-83-253.vc.shawcable.net [24.79.83.253] Jun 17 18:17:07 sunrpc connection attempt from skola8.zakladni-skola.cz [62.168.55.246] Jun 18 00:07:26 port 445 connection attempt from 62.2.179.7 Jun 18 00:07:26 port 445 connection attempt from [62.2.179.7] Jun 18 00:07:27 port 445 connection attempt from [62.2.179.7] Now when I think about it these will probably all be harmless (maybe others on this cable modem subnet were serving stuff when they had my ip)
Re: A question about Knark and modules
Hello Do you know about LIDS (www.lids.org)? It also gives the ability to play with CAP's, but seems much more sophisticated. I've just subscribed to this list. Has LIDS been discussed here before? I'm interested in using it, but am not sure how to use it best. In fact I currently think it's best suited for just making sure tools like tripwire can operate safely (so it's helping intrusion detection, hence it's name (linux intrusion detection system) is very correct), rather than effectively inhibiting a breakin. But even for this purpose it seems you have to secure almost every file in your system with ACL's (which is not very comfortable). Maybe this idea from mine is working well: install some special binaries to which you grant many permissions. One is an 'apt-get update/upgrade' wrapper (so automatic security updates work), another one might be a shell wrapper allowing system administrators to work on /etc, and so on. I think I'll ask this on the lids list later if that's the better place for such discussions. Christian. At 3:00 Uhr +0200 17.6.2001, Ethan Benson wrote: lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are these breakin attempts?
Yes, they are likely breakin attempts. Why in the *world* are you running rpc.statd (or portmap, or...nevermind...some people can't be helped) on a publicly accessable machine. That's flat out stupid. Ken Seefried, CISSP Christian Jaeger writes: > Hello, > > I run a pc with potato on a cable modem line. Recently I discovered the > following in /var/log/messages: > > Jun 10 20:21:16 pflanze -- MARK -- > Jun 10 20:33:55 pflanze > Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for > ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n > %137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\2 > 20\220\220\220\220\220\220\220\220\220\220\220\220\ > Jun 10 20:33:55 pflanze > Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ > Jun 10 21:01:16 pflanze -- MARK -- > > Jun 11 13:41:16 pflanze -- MARK -- > Jun 11 13:47:10 pflanze > Jun 11 13:47:10 pflanze /sbin/rpc.statd[229]: gethostbyname error for > ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n > %137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\2 > 20\220\220\220\220\220\220\220\220\220\220\220\220\ > Jun 11 13:47:10 pflanze > Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ > Jun 11 14:01:16 pflanze -- MARK -- > > Jun 12 09:01:16 pflanze -- MARK -- > Jun 12 09:09:47 pflanze > Jun 12 09:09:47 pflanze /sbin/rpc.statd[229]: gethostbyname error for > ^X÷ÿ¿^X÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn\220\22 > 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\ > 220\220\220\220\220\220\220\220\220\220\220\220\220 > Jun 12 09:09:47 pflanze > Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ > Jun 12 09:21:16 pflanze -- MARK -- > > Seems like a buffer overflow. (Is it happening in rpc.statd or in named or > somewhere else?) > > I've now removed nfs-common && nfs-server. (BTW there's still running a > daemon (portmap, from netbase) on the sunrpc port - I thought sunrpc is > only (mainly?) for NFS?) > > After that I've installed ippl, which gives some interesting output as > well: > > Jun 17 04:13:24 asp connection attempt from ACBDC962.ipt.aol.com > [172.189.201.98] > Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com > [66.66.4.173] > Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com > [66.66.4.173] > > Jun 17 11:04:36 webcache connection attempt from > ppp45-net1-idf2-bas1.isdnet.net [195.154.50.45] > > Jun 17 18:14:47 sunrpc connection attempt from > h24-79-83-253.vc.shawcable.net [24.79.83.253] > Jun 17 18:17:07 sunrpc connection attempt from skola8.zakladni-skola.cz > [62.168.55.246] > > Jun 18 00:07:26 port 445 connection attempt from 62.2.179.7 > Jun 18 00:07:26 port 445 connection attempt from [62.2.179.7] > Jun 18 00:07:27 port 445 connection attempt from [62.2.179.7] > > Now when I think about it these will probably all be harmless (maybe > others on this cable modem subnet were serving stuff when they had my ip). > If yes, please apologize my anxiety. > > .christian. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Are these breakin attempts?
Hello, I run a pc with potato on a cable modem line. Recently I discovered the following in /var/log/messages: Jun 10 20:21:16 pflanze -- MARK -- Jun 10 20:33:55 pflanze Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 10 20:33:55 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 10 21:01:16 pflanze -- MARK -- Jun 11 13:41:16 pflanze -- MARK -- Jun 11 13:47:10 pflanze Jun 11 13:47:10 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 11 13:47:10 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 11 14:01:16 pflanze -- MARK -- Jun 12 09:01:16 pflanze -- MARK -- Jun 12 09:09:47 pflanze Jun 12 09:09:47 pflanze /sbin/rpc.statd[229]: gethostbyname error for ^X÷ÿ¿^X÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220 Jun 12 09:09:47 pflanze Ç^F/binÇF^D/shA0À\210F^G\211v^L\215V^P\215N^L\211ó°^KÍ\200°^AÍ\200è\177ÿÿÿ Jun 12 09:21:16 pflanze -- MARK -- Seems like a buffer overflow. (Is it happening in rpc.statd or in named or somewhere else?) I've now removed nfs-common && nfs-server. (BTW there's still running a daemon (portmap, from netbase) on the sunrpc port - I thought sunrpc is only (mainly?) for NFS?) After that I've installed ippl, which gives some interesting output as well: Jun 17 04:13:24 asp connection attempt from ACBDC962.ipt.aol.com [172.189.201.98] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 10:27:38 asp connection attempt from syr-66-66-4-173.twcny.rr.com [66.66.4.173] Jun 17 11:04:36 webcache connection attempt from ppp45-net1-idf2-bas1.isdnet.net [195.154.50.45] Jun 17 18:14:47 sunrpc connection attempt from h24-79-83-253.vc.shawcable.net [24.79.83.253] Jun 17 18:17:07 sunrpc connection attempt from skola8.zakladni-skola.cz [62.168.55.246] Jun 18 00:07:26 port 445 connection attempt from 62.2.179.7 Jun 18 00:07:26 port 445 connection attempt from [62.2.179.7] Jun 18 00:07:27 port 445 connection attempt from [62.2.179.7] Now when I think about it these will probably all be harmless (maybe others on this cable modem subnet were serving stuff when they had my ip)
Re: A question about Knark and modules
Hello Do you know about LIDS (www.lids.org)? It also gives the ability to play with CAP's, but seems much more sophisticated. I've just subscribed to this list. Has LIDS been discussed here before? I'm interested in using it, but am not sure how to use it best. In fact I currently think it's best suited for just making sure tools like tripwire can operate safely (so it's helping intrusion detection, hence it's name (linux intrusion detection system) is very correct), rather than effectively inhibiting a breakin. But even for this purpose it seems you have to secure almost every file in your system with ACL's (which is not very comfortable). Maybe this idea from mine is working well: install some special binaries to which you grant many permissions. One is an 'apt-get update/upgrade' wrapper (so automatic security updates work), another one might be a shell wrapper allowing system administrators to work on /etc, and so on. I think I'll ask this on the lids list later if that's the better place for such discussions. Christian. At 3:00 Uhr +0200 17.6.2001, Ethan Benson wrote: >lcap CAP_SYS_MODULE CAP_SYS_RAWIO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > Thanks for the input. Two points: > > 1. I coming at this problem as a laptop user so pcmcia modules must remain > and be loadable and unloadable at will - as far as I know, there is no > direct > way to compile pcmcia modules directly into the kernel like the other > drivers. your stuck then live with the risk of knark, nothing you can do about it but install security updates and be a vigilant admin unlike all the morons with root passwords. > 2. What if /dev/mem access was determined at kernel compile time as an > option? no > I'm not familiar with lcap, but I assume it disables access to /dev/mem > without > breaking anything, so why not make this risky access optional at kernel > level? access to /dev/mem, /dev/kmem, /proc/kcore and such require a capability (privilege) known as CAP_SYS_RAWIO, its not just file permissions or having uid=0. lcap removes CAP_SYS_RAWIO from the capability bounding set, which means that NO process already running or run in the future can hold that capability, without the capability the kernel denies any read or writes to these devices, even to root. as for not breaking anything, that depends, nothing breaks on my firewall which is headless and runs only a handful of processes. the only thing out of the ordinary is a warning from klogd about not being able to read /dev/kmem for whatever reason it wants to poke there, it still works. if you use X though you will be disappointed, X mucks around /dev/mem. > Concurred, however, I prefer proactive rather than reactive. The danger of > undisclosed exploits always leaves this area of doubt. If the expoilt cannot > happen in the first place, a whole generation of exploits is eliminated at > once. in this case you must make very large sacrifices to accomplish this. including giving up kernel modules and X11. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpVxvBhtF5Jq.pgp Description: PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO Thanks for the input. Two points: 1. I coming at this problem as a laptop user so pcmcia modules must remain and be loadable and unloadable at will - as far as I know, there is no direct way to compile pcmcia modules directly into the kernel like the other drivers. 2. What if /dev/mem access was determined at kernel compile time as an option? I'm not familiar with lcap, but I assume it disables access to /dev/mem without breaking anything, so why not make this risky access optional at kernel level? > i suggest installing all security updates immediatly when they arrive > and vigilent sysadmin. those will keep your box uncompromised better > then anything (except turning it off). Concurred, however, I prefer proactive rather than reactive. The danger of undisclosed exploits always leaves this area of doubt. If the expoilt cannot happen in the first place, a whole generation of exploits is eliminated at once. -- Sjarn Valkhoff
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > Thanks for the input. Two points: > > 1. I coming at this problem as a laptop user so pcmcia modules must remain > and be loadable and unloadable at will - as far as I know, there is no > direct > way to compile pcmcia modules directly into the kernel like the other > drivers. your stuck then live with the risk of knark, nothing you can do about it but install security updates and be a vigilant admin unlike all the morons with root passwords. > 2. What if /dev/mem access was determined at kernel compile time as an > option? no > I'm not familiar with lcap, but I assume it disables access to /dev/mem > without > breaking anything, so why not make this risky access optional at kernel > level? access to /dev/mem, /dev/kmem, /proc/kcore and such require a capability (privilege) known as CAP_SYS_RAWIO, its not just file permissions or having uid=0. lcap removes CAP_SYS_RAWIO from the capability bounding set, which means that NO process already running or run in the future can hold that capability, without the capability the kernel denies any read or writes to these devices, even to root. as for not breaking anything, that depends, nothing breaks on my firewall which is headless and runs only a handful of processes. the only thing out of the ordinary is a warning from klogd about not being able to read /dev/kmem for whatever reason it wants to poke there, it still works. if you use X though you will be disappointed, X mucks around /dev/mem. > Concurred, however, I prefer proactive rather than reactive. The danger of > undisclosed exploits always leaves this area of doubt. If the expoilt cannot > happen in the first place, a whole generation of exploits is eliminated at > once. in this case you must make very large sacrifices to accomplish this. including giving up kernel modules and X11. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > which will disable module loading entirely as well as access to > > /dev/mem (which can be just as dangerous as a kernel module and would > > bypass your signed module thing nicely). > > Which means: so long, X. I have a workstation and using X in, > naturally, necessary (in fact, it is paramount since 3D rendering > without Xfree4's opengl is horrible). Thus this option is out. How > about compiling the kernel without module support in the first place? > The problem of /dev/mem would remain, but if the kernel does not know > about modules, is it a problem? compiling without module support would be mostly the same as just lcap CAP_SYS_MODULE leaving /dev/mem open leaves you open regardless of how you stop module loading. i suggest installing all security updates immediatly when they arrive and vigilent sysadmin. those will keep your box uncompromised better then anything (except turning it off). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpXdAtbKcUlQ.pgp Description: PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO > which will disable module loading entirely as well as access to > /dev/mem (which can be just as dangerous as a kernel module and would > bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO Thanks for the input. Two points: 1. I coming at this problem as a laptop user so pcmcia modules must remain and be loadable and unloadable at will - as far as I know, there is no direct way to compile pcmcia modules directly into the kernel like the other drivers. 2. What if /dev/mem access was determined at kernel compile time as an option? I'm not familiar with lcap, but I assume it disables access to /dev/mem without breaking anything, so why not make this risky access optional at kernel level? > i suggest installing all security updates immediatly when they arrive > and vigilent sysadmin. those will keep your box uncompromised better > then anything (except turning it off). Concurred, however, I prefer proactive rather than reactive. The danger of undisclosed exploits always leaves this area of doubt. If the expoilt cannot happen in the first place, a whole generation of exploits is eliminated at once. -- Sjarn Valkhoff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote: > > lcap CAP_SYS_MODULE CAP_SYS_RAWIO > > which will disable module loading entirely as well as access to > > /dev/mem (which can be just as dangerous as a kernel module and would > > bypass your signed module thing nicely). > > Which means: so long, X. I have a workstation and using X in, > naturally, necessary (in fact, it is paramount since 3D rendering > without Xfree4's opengl is horrible). Thus this option is out. How > about compiling the kernel without module support in the first place? > The problem of /dev/mem would remain, but if the kernel does not know > about modules, is it a problem? compiling without module support would be mostly the same as just lcap CAP_SYS_MODULE leaving /dev/mem open leaves you open regardless of how you stop module loading. i suggest installing all security updates immediatly when they arrive and vigilent sysadmin. those will keep your box uncompromised better then anything (except turning it off). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO > which will disable module loading entirely as well as access to > /dev/mem (which can be just as dangerous as a kernel module and would > bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
