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: 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 INTERFACE -p TCP -s ! LOCALLAN -d EXTERNAL IP 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
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: 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]
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: gnupg problem
Previously Thomas Bushnell, BSG wrote: Ok, that's a fine reason. But then the working mailcrypt needs to be installed, or the security fix has only been half-done. There is a fixed mailcrypt in proposed-updates. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Thomas Bushnell, BSG wrote: Ok, that's a fine reason. But then the working mailcrypt needs to be installed, or the security fix has only been half-done. There is a fixed mailcrypt in proposed-updates. That's great, but it doesn't help. The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Previously Thomas Bushnell, BSG wrote: The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. I see this differently: we had a security problem in gnupg, which we fixed. This unfortunately broke the version of mailcrypt that was was in contrib, so not even a proper part of the Debian potato release itself. Its maintainer did upload a new version of mailcrypt to fix that problem which you can grab from proposed-updates until the next stable revision. Installing mailcrypt on security.debian.org would immediately suggest that mailcrypt itself has a security problem, which is not true. It's a bit of a catch 22. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- 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 08:56:03AM +0200, Philipp Schulte wrote: 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? chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: gnupg problem
On Mon, Jun 18, 2001 at 01:04:51AM -0700, Thomas Bushnell, BSG wrote: The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. gnupg is installable, if you remove mailcrypt. ;-) not ideal but thats the way the way the cookie crumbles. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: rlinetd security
On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote: 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? first you should ask yourself why you even need echo, daytime, discard, chargen and such. i don't think ive ever found anyone who actually did need all of those. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: rlinetd security
On Mon, 18 Jun 2001, Ethan Benson wrote: On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote: 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? first you should ask yourself why you even need echo, daytime, discard, chargen and such. i don't think ive ever found anyone who actually did need all of those. Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. Thanks, Sebastiaan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote: Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. if you don't know why your running them you don't need them. simple as that. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. Does LIDS change the behaviour of the cap or are they claiming something wrong? BTW: Are there any proof of concept for this vulnerability? Regards, Phil -- 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 12:43:41PM +0200, Philipp Schulte wrote: On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. Does LIDS change the behaviour of the cap or are they claiming something wrong? they do make all sorts of change to the kernel since the current capability bounding set isn't complete enough to accomplish anything that can't be trivally undone by moving stuff around the filesystem and rebooting once. the trouble with lids, or more so the ideas they go with is you break your system so badly that it becomes impossible to administer, certianly impossible to admin remotely. the cost is too high IMO. BTW: Are there any proof of concept for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. for the former not that i know of, but if i were better at C i think i could put one together in an hour or less, here is the explanation: http://www.netcom.com/~spoon/lcap/bugtraq.txt -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote: On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. Well, somebody should tell them ;) BTW: Are there any proof of concept for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. Yes, I would be really interested in this script. Do you have an URL or could send it to me? Some of our servers use lcap and some files are +i or +a. So far I thought that CAP_SYS_RAWIO would prevent some of the mentioned problems but obviously I was wrong. Thanks for the information, Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: rlinetd security
That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Pat Moffitt MIS Administrator Western Recreational Vehicles, Inc. -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED]] Sent: Monday, June 18, 2001 1:57 AM To: [EMAIL PROTECTED] Subject: Re: rlinetd security On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote: Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. if you don't know why your running them you don't need them. simple as that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Pat Moffitt [EMAIL PROTECTED] writes: That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Ethan is correct. Start from `the more ports you leave open, the greater chance you have of being cracked' and work up. ISTR the standard inetd services including discard, echo, sysstat, netstat et all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Again, if you don't know why you need it, you don't need it. ~Tim -- 17:16:07 up 3 days, 21:20, 16 users, load average: 0.13, 0.09, 0.02 [EMAIL PROTECTED] |Sometimes you're the pigeon, http://piglet.is.dreaming.org |Sometimes you're the statue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote: On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: ... install some special binaries to which you grant many permissions. 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. Well, if the 'apt-get update apt-get upgrade' wrapper doesn't take any input and resets the environment (is there anything else it should take care of?) then even if called by the cracker it wouldn't do anything else than upgrade the system the same way upgrades were happening anyway before the breakin. (Ok, there may be an issue with the changing inode numbers lids is depending upon and which would not get updated immediately after upgrading software.) And/or if I install a special shell binary that has capabilities to access the whole filesystem, but exits immediately unless called by sshd, then system administrators still can just login as root and do what they are used to do, without risking a hacker using the same tool because he (probably) didn't use sshd to gain access to the machine. (Of course, this requires 1. sshd not having a problem, and 2. making sure depending files like /etc/shadow, pam etc are protected, but that's what lids people propagate anyway). Am I wrong? Of course if lids in fact can't deny access to disk devices then probably all is lost... Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On 18 Jun 2001, Tim Haynes wrote: Pat Moffitt [EMAIL PROTECTED] writes: That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Ethan is correct. Start from `the more ports you leave open, the greater chance you have of being cracked' and work up. ISTR the standard inetd services including discard, echo, sysstat, netstat et all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Thanks, Sebastiaan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Sebastiaan [EMAIL PROTECTED] writes: [snip] Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Good questions. a) echo is just there to duplicate everything you send back at you. discard is just there to dump everything in the sink. chargen is to give a continual stream of output, eg bandwidth testing daytime is to give another box a snapshot of the time on here - a crude ancient horrible way to sync boxes netstat is to give a view of `netstat' over the 'net - remote admin? b) they shouldn't be. You'll have to check if they still appear by default in unstable; I should hope they don't. (There's been discussion of this before if you trawl some archives somewhere.) It's possible to use them all legitimately - e.g. the daytime thing might be if someone has a legacy setup on their LAN and relied on it for time sync, the chargen/echo/discard things could well be useful for getting streams of data and network monitoring, etc. However, they really shouldn't be enabled by default. ~Tim -- All I see, All I know |[EMAIL PROTECTED] Is touching the sacred earth|http://spodzone.org.uk/ And warming the hallowed ground | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote: b) they shouldn't be. You'll have to check if they still appear by default in unstable; I should hope they don't. (There's been discussion of this before if you trawl some archives somewhere.) It's possible to use them all legitimately - e.g. the daytime thing might be if someone has a legacy setup on their LAN and relied on it for time sync, the chargen/echo/discard things could well be useful for getting streams of data and network monitoring, etc. However, they really shouldn't be enabled by default. Why not? You've not given any reason at all. Do you know of any malicious behavior that is made possible by leaving the services turned on? The potential exists to use the chargen feature as a part of a DoS attack, but I've not heard of it ever being used as it's not particularly effective unless you have many many machines available, and even then there are much more effective weapons. And what about the rest of the ports? How are they dangerous? I've never heard of an exploit involving any of them. Really I'm just playing devil's advocate here. I don't care if they're turned off or not. I've just never seen any evidence that there's any reason for concern over them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html PGP signature
Re: gnupg problem
Wichert Akkerman [EMAIL PROTECTED] writes: Installing mailcrypt on security.debian.org would immediately suggest that mailcrypt itself has a security problem, which is not true. It's a bit of a catch 22. Well, this is a general problem then, which the security team should think about. The fact that mailcrypt is in contrib means it's a little less important in this particular case, but nontheless, it's a real problem. Debian is about a *distribution* and not a random assemblage of .deb's. The security team exists to support the rapid response to security needs for the *distribution*, and not just one package. So my premise is that a user who tracks stable and security should benefit from security fixes. When the security team does what was done with gnupg, the *distribution* has not gotten decent security support, even if one package has. Perhaps one solution is to split the security archive into two pieces; one for the actual packages that have security holes, and another for other packages that must be installed on a stable system in order to take advantage or otherwise use fully the former. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Ethan Benson [EMAIL PROTECTED] writes: gnupg is installable, if you remove mailcrypt. ;-) As explained in my previous mail, that is only adequate if the security team exists to support security in packages, but not the distribution as a whole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
I'm not adding anything new to this thread, only reiterating for those who seem to have missed previous reiterations: 'The more ports you leave open, the greater chance you have of being cracked.' 'If you don't know why you need it, you don't need it.' It seems reasonable that the default installation should try to make itself useful to the average target user. Now, by a show of hands (rather than a string of replies), how many of us have sat down at our newly-installed machines and said All right, time to get my discard service on! Let's follow that up with a little chargen, while we're at it! They may be legitimate services with legitimate uses, but are not needed in the normal case, and as such, should not be activated in the default case. The argument below is pretty bad. Have you ever heard of anybody actually getting impaled by holding a sword poised at his belly and walking into grand central station at 5:00pm going 'scuse me, pardon me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it? Our hypothetical late friend didn't need to be doing it, and he shouldn't have been doing it. ...which brings me to my next point: just because I've never heard of such a ridiculous demise actually occuring doesn't rule out the possibility that it has. And just because you haven't heard of exploits involving these services doesn't mean they haven't been around. Again, a reiteration of wiser words earlier in the thread: the standard inetd services including discard, echo, sysstat, netstat et al all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Vineet * Noah Meyerhans ([EMAIL PROTECTED]) [010618 10:51]: Why not? You've not given any reason at all. Do you know of any malicious behavior that is made possible by leaving the services turned on? The potential exists to use the chargen feature as a part of a DoS attack, but I've not heard of it ever being used as it's not particularly effective unless you have many many machines available, and even then there are much more effective weapons. And what about the rest of the ports? How are they dangerous? I've never heard of an exploit involving any of them. Really I'm just playing devil's advocate here. I don't care if they're turned off or not. I've just never seen any evidence that there's any reason for concern over them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html PGP signature
No Subject
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Noah Meyerhans [EMAIL PROTECTED] writes:
On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
b) they shouldn't be. You'll have to check if they still appear by
default
[snip]
Why not? You've not given any reason at all. Do you know of any malicious
behavior that is made possible by leaving the services turned on?
I don't need to, as my point earlier included `you don't know there won't
be a vulnerability tomorrow'.
But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
whenever. I wouldn't want someone to know exactly what time my boxes
thought it was.
The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not particularly
effective unless you have many many machines available, and even then
there are much more effective weapons.
http://www.sans.org/infosecFAQ/malicious/naptha.htm, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?
Really I'm just playing devil's advocate here. I don't care if they're
turned off or not. I've just never seen any evidence that there's any
reason for concern over them.
There doesn't have to be a reason for concern for you to not want them
available. I don't want anyone so much as fingerprinting my box (given that
nmap relies mostly on TCP responses to guage OS), let alone doing anything
really interesting with it.
~Tim
--
The light of the world keeps shining, |[EMAIL PROTECTED]
Bright in the primal glow |http://spodzone.org.uk/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
The argument below is pretty bad. Have you ever heard of anybody
actually getting impaled by holding a sword poised at his belly and
walking into grand central station at 5:00pm going 'scuse me, pardon
me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it?
Our hypothetical late friend didn't need to be doing it, and he
shouldn't have been doing it.
Huh? You've acknowledged that there may be legitimate uses for the
simple services that you may be ignorant of. I don't think there is any
legitimate gain to be had be running around a crowded area with a blade
against your belly.
the standard inetd services including discard, echo, sysstat,
netstat et al all *have* *had* their known vulnerabilities before now.
All long-since patched, but that's not to say there won't be another
tomorrow.
Have you looked at their code? I can assure you that there is no
potential for remote exploit in
void
discard_stream(int s, struct servtab *sep)
{
char buffer[BUFSIZE];
setproctitle(sep-se_service, s);
while ((errno = 0, read(s, buffer, sizeof(buffer)) 0) ||
errno == EINTR)
;
exit(0);
}
Or how 'bout this:
/* Return human-readable time of day */
void
daytime_stream(int s, struct servtab *sep)
{
char buffer[256];
time_t clocc;
(void)sep;
clocc = time(NULL);
snprintf(buffer, sizeof(buffer), %.24s\r\n, ctime(clocc));
write(s, buffer, strlen(buffer));
}
These services are so simple that any moderately knowledgeable coder can
ensure that there is no risk to leaving the services turned on.
noah
--
___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
PGP signature
Re: rlinetd security
On Mon, Jun 18, 2001 at 07:25:37PM +0100, Tim Haynes wrote:
But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
whenever. I wouldn't want someone to know exactly what time my boxes
thought it was.
So I assume you stay very clear of any kind of time synchronization
(ntpd and the like). In order for things like Kerberos to work (BTW, I
am a kerberos user) the client machines have to be very closely
synchronized with the authentication server. NTP is how this is done.
Giving out your time via either the daytime or time simple service is
not giving out any info that's not already available to anybody who
cares to look.
The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not particularly
effective unless you have many many machines available, and even then
there are much more effective weapons.
http://www.sans.org/infosecFAQ/malicious/naptha.htm, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?
Yes, but you know what? 'ping -f' works just as good, if not better.
Do you have ICMP filtered at your router?
--
___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
PGP signature
RE: rlinetd security
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Haynes Sent: Monday, June 18, 2001 10:35 AM To: Sebastiaan Cc: Tim Haynes; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: rlinetd security Sebastiaan [EMAIL PROTECTED] writes: [snip] Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Good questions. a) echo is just there to duplicate everything you send back at you. discard is just there to dump everything in the sink. chargen is to give a continual stream of output, eg bandwidth testing daytime is to give another box a snapshot of the time on here - a crude ancient horrible way to sync boxes netstat is to give a view of `netstat' over the 'net - remote admin? [snip] Now that answers some questions. Much better. At least when I turn them off I will have a clue about what might break. BTW, my philosophy on disabling unknown services/ports has been to disable it and see if anything breaks. If something breaks, then figure out what to do about it. But, this can be a tough philosophy on production machines. (No, I don't have machines that I can test with here. Nor do I have the time to set them up.) The concept of 'if you don't know why your running them you don't need them.' may be good advice but doesn't help those of use that are trying to understand Security. Pat Moffitt MIS Administrator Western Recreational Vehicles, Inc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote: The argument below is pretty bad. Have you ever heard of anybody actually getting impaled by holding a sword poised at his belly and walking into grand central station at 5:00pm going 'scuse me, pardon me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it? Our hypothetical late friend didn't need to be doing it, and he shouldn't have been doing it. Huh? You've acknowledged that there may be legitimate uses for the simple services that you may be ignorant of. I don't think there is any legitimate gain to be had be running around a crowded area with a blade against your belly. The point is that these things can be used for good or evil. If you're not going to use it for good, whether someone else can or not, a nasty chap can still use it for evil. You realise rpc.statd has its uses, as does ftpd? Is that some reason to enable them `just in case somebody wants to use them for legitimate reasons'? the standard inetd services including discard, echo, sysstat, netstat et al all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Have you looked at their code? I can assure you that there is no potential for remote exploit in void discard_stream(int s, struct servtab *sep) [snip] These services are so simple that any moderately knowledgeable coder can ensure that there is no risk to leaving the services turned on. There isn't? What about in your choice of C-library, then, have you audited that? While you're here, what tweaks are going to be made to these functions next week? The principle is still the same. It's not enough to ask whether you need it or not and assume something can be left on if you don't know any better; if another vulnerability comes out you have to check one more thing to see whether it's relevant or not, which is a waste of time, at best, and an omitted necessary update to an unused service (unused, until someone scans you for it, that is) at worst. Incidentally, in your dismissal of exploits for these things, you're neglecting another scenario: black-hat *does* manage to crack another box in the organization, and points multiple netcats from the exploited box at someone with echo: you'll end up with enough network traffic load to cause a slow-down, and the traffic may possibly help him mask very nasty activities in the noise. ~Tim -- All I see, All I know |[EMAIL PROTECTED] Is touching the sacred earth|http://spodzone.org.uk/ And warming the hallowed ground | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Petr Cech [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: Debian is about a *distribution* and not a random assemblage of OK, distribution. That's dists/potato/main/binary-arch/Packages If that's the *only* thing that counts as the Debian distribution, then we have no security team at all! Debian ought to offer security updates for the stable distribution, but it doesn't. Instead, it is only offering security updates for the packages in the stable distribution. That's an understandable oversight, but it is an oversight, and I think it should be corrected. We are not just about packages, we are about the way they work together to form a coherent whole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
Noah L. Meyerhans [EMAIL PROTECTED] writes:
[snip]
http://www.sans.org/infosecFAQ/malicious/naptha.htm, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?
Yes, but you know what? 'ping -f' works just as good, if not better. Do
you have ICMP filtered at your router?
Some, yes.
I also worry about who's going to be able to execute `ping -f' on *my*
machines, should they make it through, and try to make it as hard as
possible.
Leaving ports open because you don't know better does not constitute making
nasty people's life harder.
~Tim
--
20:12:08 up 4 days, 16 min, 17 users, load average: 0.02, 0.04, 0.00
[EMAIL PROTECTED] |Windows 98 is year 2000-ready
http://piglet.is.dreaming.org |(seen during a recent, y2000, installation)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Debian ought to offer security updates for the stable distribution, but it doesn't. Instead, it is only offering security updates for the packages in the stable distribution. That's an understandable oversight, but it is an oversight, and I think it should be corrected. Insofar as I can make any sense of the above differentiation, does the idea `2.2r3' fit into this anywhere? We are not just about packages, we are about the way they work together to form a coherent whole. ~Tim -- 20:43:57 up 4 days, 47 min, 11 users, load average: 0.02, 0.01, 0.00 [EMAIL PROTECTED] |Can you tell me how to get, http://piglet.is.dreaming.org |How to get to Sesame Street? | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote: Well, it depends. You can never tidy up a rooted box; the same mentality sort of applies all the way down - if you're setting up a box, why worry about installing this and uninstalling that, when your original installation shouldn't have had anything enabled in the first place? (And yes, you can push that back into the distro, too.) Sure, you can have a distro that doens't install any services. Heck, consider local exploits and you may decide that login considered harmful isn't too great a stretch... :-) I have to take issue with your attempt to draw a aparallel to a rooted box. It *is* possible to cleanup the newly installed box because you can reasonably assume that it hasn't been maliciously setup to resist the cleanup. Surely software you install on production machines has its requirements either satisfied by the wonder that is apt-get, or documented properly? You can, and should, start from blank and add things as you need. Could I agree with the minimalist sentiment while yet observing that apt-get, wonderful as it is, cannot satisfy requirements that come not from packages installed on this machine, but from other machines - possibly ones that aren't even using Debian? At the same time, I would like to agree with the sentiment that has been expressed a few times. If you don't know what it's for, shut it off. I think the unstated part that some may have overlooked is that if you need something but don't know it, then you owe it to yourself (and your employers, if that's the sort of situation it is) to find out what's there. This is how sysadmins lose their hair! -- There has grown up in the minds of certain groups in this country the notion that because a man or corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. -- RAH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 08:45:12PM +0100, Tim Haynes wrote: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Debian ought to offer security updates for the stable distribution, but it doesn't. Instead, it is only offering security updates for the packages in the stable distribution. That's an understandable oversight, but it is an oversight, and I think it should be corrected. Insofar as I can make any sense of the above differentiation, does the idea `2.2r3' fit into this anywhere? Sure. That's the latest release of the distribution, with bug fixes rolled in. Many of those are security fixes. Other security fixes have been needed since release 3; because security bugs are considered more time-critical than the other sorts, they are released, and indeed we are strongly urged to install them, independently of the point release mechanism. The issue is, can a security-bug-fix release of a package which is incompatible with one or more parts of the current point release packages as a whole be good? I'm inclined to feel that this is at least a serious flaw in that security-bug-fix release, and I would hate to have to try to defend the position that it is not a release-critical grade bug. How would this sort of conflict be resolved in normal development - if this incompatibility arose in a proposed-update (non-security related), do you think that package would be accepted for the next point release? I would hope not. We are not just about packages, we are about the way they work together to form a coherent whole. What he said. Debian's biggest plus - I speak here as a sysadmin and user of the distro - has always been the much higher technical quality; having a supposed fix cause another part of Debian to break seems quite antithetical to that quality. If I wanted to roll the dice every time I installed something new I could be using RPMs. :-( :-) -- Microsoft, which used to say all the time that the software business was ruthlessly competitive, is now matched against a competitor whose model of production and distribution is so much better that Microsoft stands no chance of prevailing in the long run. They're simply trying to scare people out of dealing with a competitor they can't buy, can't intimidate and can't stop. -- Eben Moglen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rlinetd security
[EMAIL PROTECTED] (Martin Maney) writes: On Mon, Jun 18, 2001 at 08:34:11PM +0100, Tim Haynes wrote: Well, it depends. You can never tidy up a rooted box; the same mentality sort of applies all the way down - if you're setting up a box, why worry about installing this and uninstalling that, when your original installation shouldn't have had anything enabled in the first place? (And yes, you can push that back into the distro, too.) Sure, you can have a distro that doens't install any services. Heck, consider local exploits and you may decide that login considered harmful isn't too great a stretch... :-) Well, smiley noted, but the list of users who have what kind of access to the box has to be considered. I have to take issue with your attempt to draw a aparallel to a rooted box. It *is* possible to cleanup the newly installed box because you can reasonably assume that it hasn't been maliciously setup to resist the cleanup. Well, if you can assume that, sure. But the parallel really comes in saying you half-way don't know what to look for, or might miss something. That's why I'm in favour of pushing some things into the distro installation-default area. Surely software you install on production machines has its requirements either satisfied by the wonder that is apt-get, or documented properly? You can, and should, start from blank and add things as you need. Could I agree with the minimalist sentiment while yet observing that apt-get, wonderful as it is, cannot satisfy requirements that come not from packages installed on this machine, but from other machines - possibly ones that aren't even using Debian? Sure; that's where `or documented properly' comes in. At the same time, I would like to agree with the sentiment that has been expressed a few times. If you don't know what it's for, shut it off. I think the unstated part that some may have overlooked is that if you need something but don't know it, then you owe it to yourself (and your employers, if that's the sort of situation it is) to find out what's there. It's been mentioned very en-passant, as has `but I don't have the time to investigate everything', which makes my caffeine^Wblood boil. This is how sysadmins lose their hair! Tell me about it. My take on the whole thing is that you're building a test box internally first *anyway*, if you don't know exactly how to set up a live machine; then you investigate, kill off everything your reading of the manuals allows you to, on the simple grounds that you don't want it to turn around bite you later on, and you're on a test box so any breaks won't matter and you'll learn in the process. Leaving stuff open because `there aren't any known holes at the moment doesn't really wash here :( . ~Tim -- But mountains are holy places, |[EMAIL PROTECTED] And beauty is free / We can still walk |http://spodzone.org.uk/ Through the garden | Our earth was once green| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 12:11:39PM -0700 , Thomas Bushnell, BSG wrote:
Petr Cech [EMAIL PROTECTED] writes:
On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote:
Debian is about a *distribution* and not a random assemblage of
OK, distribution. That's dists/potato/main/binary-arch/Packages
If that's the *only* thing that counts as the Debian distribution,
then we have no security team at all!
you know, what I've ment. Debian *distribution* is main and non-US/main
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
* Joy notes some people think Unix is a misspelling of Unics which is a
misspelling of Emacs :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 03:41:20PM -0500 , Martin Maney wrote:
arose in a proposed-update (non-security related), do you think that package
then it wouldn't (or a fixed conflicting package would be provided). But
because we need this security update, then we need also a proposed-update
would be accepted for the next point release? I would hope not.
We are not just about packages, we are about the way they work together
to form a coherent whole.
What he said. Debian's biggest plus - I speak here as a sysadmin and user
of the distro - has always been the much higher technical quality; having a
supposed fix cause another part of Debian to break seems quite
antithetical to that quality.
1) don't fix = not an option
2) fork = really no
3) fix and fix the breakage = we have this
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
woot What do you mean it's not packaged in Debian?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Petr Cech [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 12:11:39PM -0700 , Thomas Bushnell, BSG wrote: Petr Cech [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote: Debian is about a *distribution* and not a random assemblage of OK, distribution. That's dists/potato/main/binary-arch/Packages If that's the *only* thing that counts as the Debian distribution, then we have no security team at all! you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 10:48:27PM +0200, Petr Cech wrote: you know, what I've ment. Debian *distribution* is main and non-US/main Is that policy or your opinion? Last time I looked, there were still those pesky other sections on the servers, in the bug system, and so forth. -- You arguably have quite a few inalienable rights, but being taken seriously isn't one of them. Neither is being respected. -- Rick Moen linuxmafia.com/~rick/faq/ -- 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 06:41:59PM +0200, Christian Jaeger wrote: Well, if the 'apt-get update apt-get upgrade' wrapper doesn't take any input and resets the environment (is there anything else it should take care of?) then even if called by the cracker it wouldn't do anything else than upgrade the system the same way upgrades were happening anyway before the breakin. (Ok, there may be an issue with the changing inode numbers lids is depending upon and which would not get updated immediately after upgrading software.) what if the attacker can poisen your DNS, or routing tables? then he can trick apt into downloading his 37337 `security update' (more like unsecurity update heh) And/or if I install a special shell binary that has capabilities to access the whole filesystem, but exits immediately unless called by sshd, then system administrators still can just login as root and do what they are used to do, without risking a hacker using the same tool because he (probably) didn't use sshd to gain access to the machine. (Of course, this requires 1. sshd not having a problem, and 2. making sure depending files like /etc/shadow, pam etc are protected, but that's what lids people propagate anyway). Am I wrong? get root, run passwd root, ssh in. Of course if lids in fact can't deny access to disk devices then probably all is lost... lids can, it adds new capabilities or else modifies one of the existing ones. (at least last i read the FAQ that seemed to be implyed). -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: rlinetd security
On Mon, Jun 18, 2001 at 09:06:07AM -0700, Pat Moffitt wrote: That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. if you don't understand such issues you have no business with the root password. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. only if you insist on remaining ignorant. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: rlinetd security
On Mon, Jun 18, 2001 at 01:48:50PM -0400, Noah Meyerhans wrote: Why not? You've not given any reason at all. Do you know of any malicious behavior that is made possible by leaving the services turned on? The potential exists to use the chargen feature as a part of a DoS attack, but I've not heard of it ever being used as it's not particularly effective unless you have many many machines available, and even then there are much more effective weapons. And what about the rest of the ports? How are they dangerous? I've never heard of an exploit involving any of them. play a spoofing trick to attach the victims chargen port to its echo port. i don't know if that is still possible, in the olden days it was, had quite ammusing result too. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: gnupg problem
On Mon, Jun 18, 2001 at 02:30:19PM -0700, Thomas Bushnell, BSG wrote: you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases? security.debian.org mailcrypt is not in debian, its in contrib. niether contrib or non-free are part of debian. if gnupg broke deps on a another package in main i think you would have a point, but it broke something outside the distribution which is beyond the concerns of the security team, they only need to care about the distribution which is main and non-US/main. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: gnupg problem
On Mon, Jun 18, 2001 at 06:37:00PM -0500, Martin Maney wrote: On Mon, Jun 18, 2001 at 10:48:27PM +0200, Petr Cech wrote: you know, what I've ment. Debian *distribution* is main and non-US/main Is that policy or your opinion? Last time I looked, there were still those pesky other sections on the servers, in the bug system, and so forth. it is policy, just because they are on debian servers does not make them part of the debian distribution. non-free and contrib are NOT parts of debian. this is really fairly well known... -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: gnupg problem
Ethan Benson [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 02:30:19PM -0700, Thomas Bushnell, BSG wrote: you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases? security.debian.org mailcrypt is not in debian, its in contrib. niether contrib or non-free are part of debian. if gnupg broke deps on a another package in main i think you would have a point, but it broke something outside the distribution which is beyond the concerns of the security team, they only need to care about the distribution which is main and non-US/main. I think we have a point here too... I mean, let's actually do the best we can, instead of doing as little as possible. In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
Hello, In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main. A reading of the Debian Social Contract (section 5) contains the following concerning contrib and non-free... The software in these directories is not part of the Debian system, although it has been configured for use with Debian. One of the things that I find admirable about the Debian people is that they draw a very clear and crisp line as to what they consider acceptable to include in their distribution. Any compromise with those principles should be avoided. Mailcrypt isn't part of Debian, so it's not the responciblity of the security team. Regards, Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnupg problem
On Mon, Jun 18, 2001 at 06:10:12PM -0700, Thomas Bushnell, BSG wrote: Ethan Benson [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 02:30:19PM -0700, Thomas Bushnell, BSG wrote: you know, what I've ment. Debian *distribution* is main and non-US/main Thene where are the security releases? security.debian.org mailcrypt is not in debian, its in contrib. niether contrib or non-free are part of debian. if gnupg broke deps on a another package in main i think you would have a point, but it broke something outside the distribution which is beyond the concerns of the security team, they only need to care about the distribution which is main and non-US/main. I think we have a point here too... I mean, let's actually do the best we can, instead of doing as little as possible. In fact, the only reason mailcrypt is in contrib is that it adapts to the patent-restricted versions of gpg/pgp software. As far as its use with gpg, it belongs in main. If mailcrypt can be installed and do useful stuff without any packages from non-free installed, then it should itself be in main, shouldn't it? What would happen in a similar situation where all packages involved were already in main? Someone else pointed out that we should think about the general case of this problem, and have a way to deal with it. The fact that mailcrypt is currently in contrib lets us sort of wriggle out of the problem, in this specific instance of the problem. Does proposed-updates get merged when new sub-releases (e.g. r3) are made? If so, then putting packages there does it. If not, then the updated packages that the new security-fix package depends on must become part of potato somehow. IMHO, security fixes should still go into security.d.o ASAP, without waiting for packages that depend on them to be updated, but those packages _do_ need to be updated. -- #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: rlinetd security
On Mon, Jun 18, 2001 at 07:15:55PM +0200, Sebastiaan wrote: I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? All those internal services are for testing/debugging, except for the time service, which is used by rdate. If you don't run around playing with netcat, you _don't_ need them. The turn it off if you don't need it rule applies to services you don't know about. If you don't know if something will break if you turn it off, turn it off and see if something breaks. If nothing breaks, leave it off. -- #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 07:55:40PM -0800, Ethan Benson wrote: a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. well nearly... at least you can prevent new or unknown process/files from acessing stuff. If there is an exploit for an existing piece of software you are back at square one. The advantage is extremely granular control: a program at a specific inode can be given capabilities while everything else has them refused. the disadvantage is that you end up with a million little holes (complexity) fortunately the files that have these added capabilities are also protected (from trojaning - buffer overruns etc still work) 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. yes it is possible with lids, but it is a _lot_ harder: processes can be hidden. binaries RO (trojaning is difficult) logs append /etc/somefile can only be read when you allow it. system adminsitrator == root cracker == root cracker==root sysadmin==root+LIDS_password if someone can sniff me typing in my lids password (encrypted in the kernel) then I am stuffed. In short Lids can be a pain to set up, but would also be a pain to crack, especially if the cracker doesn't know exactly which rules I have set up. a good cracker could do it. btw I notice that they are still working on fork bomb protection. that would be nice :) -- -- 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 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
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: 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: 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: Are these breakin attempts?
add the line /sbin/ipchains -A input -i INTERFACE -p TCP -s ! LOCALLAN -d EXTERNAL IP 111 -l -j DENY to block the rpc statd attacks from your external network - Original Message - From: Christian Jaeger [EMAIL PROTECTED] To: debian-security@lists.debian.org 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
[no subject]
unsubscribe
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/ pgpvJEbYjdjjQ.pgp Description: PGP signature
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 INTERFACE -p TCP -s ! LOCALLAN -d EXTERNAL IP 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/ pgp53lHokZtT1.pgp Description: PGP signature
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
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
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
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.
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.
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.
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/
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.
Re: rlinetd security
this stuff can also be controlled using hosts.deny and hosts.allow. so then any inetd prog will do! On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote: 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] -- Jason Thomas Phone: +61 2 6257 7111 System Administrator - UID 0 Fax:+61 2 6257 7311 tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ pgpacqYephpWx.pgp Description: PGP signature
Re: gnupg problem
Previously Thomas Bushnell, BSG wrote: Ok, that's a fine reason. But then the working mailcrypt needs to be installed, or the security fix has only been half-done. There is a fixed mailcrypt in proposed-updates. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: gnupg problem
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Thomas Bushnell, BSG wrote: Ok, that's a fine reason. But then the working mailcrypt needs to be installed, or the security fix has only been half-done. There is a fixed mailcrypt in proposed-updates. That's great, but it doesn't help. The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. Thomas
Re: gnupg problem
Previously Thomas Bushnell, BSG wrote: The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. I see this differently: we had a security problem in gnupg, which we fixed. This unfortunately broke the version of mailcrypt that was was in contrib, so not even a proper part of the Debian potato release itself. Its maintainer did upload a new version of mailcrypt to fix that problem which you can grab from proposed-updates until the next stable revision. Installing mailcrypt on security.debian.org would immediately suggest that mailcrypt itself has a security problem, which is not true. It's a bit of a catch 22. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 08:56:03AM +0200, Philipp Schulte wrote: 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? chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpIl5hUKla3K.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 04:02:08AM -0300, Peter Cordes wrote: 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. it could be a separate file, encrpyted (like gpg private keys) and even kept on a floppy somewhere. 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. yup exactly. starting with the signing and IO protecting would be a very good start. yup 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... whats annoying is BSD already has this, and has for quite some time. at bootup of a standard Free,Net, or OpenBSD box the securelevel is raised to 1, which denies root the ability to remove system immutable flags, it also denies root the ability to write to raw block devices for the mounted filesystems, but not to the whole disk device, so he could still hack the filesystem, its just a tad harder. raising the securelevel to 2 denies access to all disk block devices, whole and partitions mounted or not. (among other things like sealing firewall rules and such). iirc the 2.0 linux kernel had a securelevel which was about equivilent to BSD securelevels. 2.2 removed it since `capabilities make securelevel obsolete' well not quite heh. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHHDqyI50Su.pgp Description: PGP signature
Re: gnupg problem
On Mon, Jun 18, 2001 at 01:04:51AM -0700, Thomas Bushnell, BSG wrote: The *security* team exists to make security updates to the current stable release. Currently there is *not* an installable update for gnupg. The only way (that I can think of right now) for fixing this is to put the new mailcrypt into security.debian.org. gnupg is installable, if you remove mailcrypt. ;-) not ideal but thats the way the way the cookie crumbles. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpz9tXjQfqnp.pgp Description: PGP signature
Re: rlinetd security
Jason Thomas [EMAIL PROTECTED] writes upside-down:
this stuff can also be controlled using hosts.deny and hosts.allow. so
then any inetd prog will do!
No it can't. There's a difference between not listening on the interface at
all, and filtering it out by allowing them to connect to the port first and
only later saying `I don't like the look of your IP#'.
If nothing else, you *should* use rlinetd or xinetd or similar to control
the binding *as well as* tightening down hosts.{allow,deny}.
~Tim
--
09:43:56 up 3 days, 13:48, 16 users, load average: 0.00, 0.00, 0.00
[EMAIL PROTECTED] |Ideologies come, ideologies go
http://piglet.is.dreaming.org |A waste of words, and endless flow
Re: rlinetd security
On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote: 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? first you should ask yourself why you even need echo, daytime, discard, chargen and such. i don't think ive ever found anyone who actually did need all of those. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpEVAZUCzbSk.pgp Description: PGP signature
Re: rlinetd security
On Mon, 18 Jun 2001, Ethan Benson wrote: On Mon, Jun 18, 2001 at 09:21:56AM +0200, Sebastiaan wrote: 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? first you should ask yourself why you even need echo, daytime, discard, chargen and such. i don't think ive ever found anyone who actually did need all of those. Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. Thanks, Sebastiaan
Re: rlinetd security
On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote: Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. if you don't know why your running them you don't need them. simple as that. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp5Z9Fm0eHOU.pgp Description: PGP signature
Re: rlinetd security
Ethan Benson [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote: Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. if you don't know why your running them you don't need them. simple as that. Word of warning to Sebastian: I've missed the start of this thread, obviously, but how much do you trust your LAN? If it's a home affair, don't worry so much; if it's a corporate LAN, you'll always have *insiders* sniffing networks, remembering your passwords, being sacked and feeling disenchanted with you. Avoid ftp telnet, and any other plain-text protocol, as much as humanly possible. (We don't run them in-house here, on the grounds that we find ssh scp rsync *more convenient* anyway. Maybe that's just us... ;) ~Tim -- 10:08:32 up 3 days, 14:12, 11 users, load average: 0.04, 0.03, 0.00 [EMAIL PROTECTED] |Roobarb and Custard let fly http://piglet.is.dreaming.org |with their secret weapon.
RE: strange flickering ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there are known bugs like this in nmap. But this should only apear when using nmap local. Michael Schwarzbach +--+ | /\ | | \ / | | X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL | | / \ | `~~' -Original Message- From: John Ferlito [mailto:[EMAIL PROTECTED] Sent: Montag, 18. Juni 2001 09:21 To: Sebastiaan Cc: [EMAIL PROTECTED]; debian-security@lists.debian.org Subject: 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] -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOy3PWAUqVktPGYHYEQJhuwCgsyj+4xlsY4NXApioM6oQ40fCWW8AoOMW SdtJmumTCipJ8HfmQGIuaLDQ =S+q1 -END PGP SIGNATURE-
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. Does LIDS change the behaviour of the cap or are they claiming something wrong? BTW: Are there any proof of concept for this vulnerability? Regards, Phil
(no subject)
unsubscribe
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote: chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is removed from the bounding set. however that does not prevent root from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO. there is no capability that allows you to deny root access to the raw block devices, so removing the immutable bit is trivially easy. Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. Does LIDS change the behaviour of the cap or are they claiming something wrong? they do make all sorts of change to the kernel since the current capability bounding set isn't complete enough to accomplish anything that can't be trivally undone by moving stuff around the filesystem and rebooting once. the trouble with lids, or more so the ideas they go with is you break your system so badly that it becomes impossible to administer, certianly impossible to admin remotely. the cost is too high IMO. BTW: Are there any proof of concept for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. for the former not that i know of, but if i were better at C i think i could put one together in an hour or less, here is the explanation: http://www.netcom.com/~spoon/lcap/bugtraq.txt -- Ethan Benson http://www.alaska.net/~erbenson/ pgpGI22VOG8ID.pgp Description: PGP signature
Re: A question about Knark and modules
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote: On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote: Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html is claiming that CAP_SYS_RAWIO allows access to raw block devices. they are mistaken. Well, somebody should tell them ;) BTW: Are there any proof of concept for this vulnerability? which? the /dev/mem restoration of the capability bounding set, or removing chattr +i even when CAP_LINUX_IMMUTABLE is removed? for the latter i have a script that does it. Yes, I would be really interested in this script. Do you have an URL or could send it to me? Some of our servers use lcap and some files are +i or +a. So far I thought that CAP_SYS_RAWIO would prevent some of the mentioned problems but obviously I was wrong. Thanks for the information, Phil
RE: rlinetd security
That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Pat Moffitt MIS Administrator Western Recreational Vehicles, Inc. -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2001 1:57 AM To: debian-security@lists.debian.org Subject: Re: rlinetd security On Mon, Jun 18, 2001 at 10:53:06AM +0200, Sebastiaan wrote: Yes, that is a good question. I do not know where most of them are used for, but because they are always installed, I assumed that these are needed for correct system operation. But even if I would disable these ports, I still want to use ftp, smtp and telnet only for my local network. if you don't know why your running them you don't need them. simple as that.
Re: rlinetd security
Pat Moffitt [EMAIL PROTECTED] writes: That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Ethan is correct. Start from `the more ports you leave open, the greater chance you have of being cracked' and work up. ISTR the standard inetd services including discard, echo, sysstat, netstat et all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Again, if you don't know why you need it, you don't need it. ~Tim -- 17:16:07 up 3 days, 21:20, 16 users, load average: 0.13, 0.09, 0.02 [EMAIL PROTECTED] |Sometimes you're the pigeon, http://piglet.is.dreaming.org |Sometimes you're the statue.
Re: A question about Knark and modules
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote: On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote: ... install some special binaries to which you grant many permissions. 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. Well, if the 'apt-get update apt-get upgrade' wrapper doesn't take any input and resets the environment (is there anything else it should take care of?) then even if called by the cracker it wouldn't do anything else than upgrade the system the same way upgrades were happening anyway before the breakin. (Ok, there may be an issue with the changing inode numbers lids is depending upon and which would not get updated immediately after upgrading software.) And/or if I install a special shell binary that has capabilities to access the whole filesystem, but exits immediately unless called by sshd, then system administrators still can just login as root and do what they are used to do, without risking a hacker using the same tool because he (probably) didn't use sshd to gain access to the machine. (Of course, this requires 1. sshd not having a problem, and 2. making sure depending files like /etc/shadow, pam etc are protected, but that's what lids people propagate anyway). Am I wrong? Of course if lids in fact can't deny access to disk devices then probably all is lost... Christian.
Re: rlinetd security
On 18 Jun 2001, Tim Haynes wrote: Pat Moffitt [EMAIL PROTECTED] writes: That makes a lot of assumptions about my (or anyone else) understanding of the system. For example, I have no clue what discard is used for. So, how do I know if I have a package installed that will not work properly if I disable that port. Yes, I should go and research the issue but I only have some much time in the day. Therefor, many of us are forced to make the same assumptions (valid or not) such as Sebastiaan's. Ethan is correct. Start from `the more ports you leave open, the greater chance you have of being cracked' and work up. ISTR the standard inetd services including discard, echo, sysstat, netstat et all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Thanks, Sebastiaan
Re: rlinetd security
Sebastiaan [EMAIL PROTECTED] writes: [snip] Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Good questions. a) echo is just there to duplicate everything you send back at you. discard is just there to dump everything in the sink. chargen is to give a continual stream of output, eg bandwidth testing daytime is to give another box a snapshot of the time on here - a crude ancient horrible way to sync boxes netstat is to give a view of `netstat' over the 'net - remote admin? b) they shouldn't be. You'll have to check if they still appear by default in unstable; I should hope they don't. (There's been discussion of this before if you trawl some archives somewhere.) It's possible to use them all legitimately - e.g. the daytime thing might be if someone has a legacy setup on their LAN and relied on it for time sync, the chargen/echo/discard things could well be useful for getting streams of data and network monitoring, etc. However, they really shouldn't be enabled by default. ~Tim -- All I see, All I know |[EMAIL PROTECTED] Is touching the sacred earth|http://spodzone.org.uk/ And warming the hallowed ground |
Re: rlinetd security
On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote: b) they shouldn't be. You'll have to check if they still appear by default in unstable; I should hope they don't. (There's been discussion of this before if you trawl some archives somewhere.) It's possible to use them all legitimately - e.g. the daytime thing might be if someone has a legacy setup on their LAN and relied on it for time sync, the chargen/echo/discard things could well be useful for getting streams of data and network monitoring, etc. However, they really shouldn't be enabled by default. Why not? You've not given any reason at all. Do you know of any malicious behavior that is made possible by leaving the services turned on? The potential exists to use the chargen feature as a part of a DoS attack, but I've not heard of it ever being used as it's not particularly effective unless you have many many machines available, and even then there are much more effective weapons. And what about the rest of the ports? How are they dangerous? I've never heard of an exploit involving any of them. Really I'm just playing devil's advocate here. I don't care if they're turned off or not. I've just never seen any evidence that there's any reason for concern over them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgp1434Zdbbvy.pgp Description: PGP signature
Re: gnupg problem
Wichert Akkerman [EMAIL PROTECTED] writes: Installing mailcrypt on security.debian.org would immediately suggest that mailcrypt itself has a security problem, which is not true. It's a bit of a catch 22. Well, this is a general problem then, which the security team should think about. The fact that mailcrypt is in contrib means it's a little less important in this particular case, but nontheless, it's a real problem. Debian is about a *distribution* and not a random assemblage of .deb's. The security team exists to support the rapid response to security needs for the *distribution*, and not just one package. So my premise is that a user who tracks stable and security should benefit from security fixes. When the security team does what was done with gnupg, the *distribution* has not gotten decent security support, even if one package has. Perhaps one solution is to split the security archive into two pieces; one for the actual packages that have security holes, and another for other packages that must be installed on a stable system in order to take advantage or otherwise use fully the former. Thomas
Re: gnupg problem
Ethan Benson [EMAIL PROTECTED] writes: gnupg is installable, if you remove mailcrypt. ;-) As explained in my previous mail, that is only adequate if the security team exists to support security in packages, but not the distribution as a whole.
Re: rlinetd security
I'm not adding anything new to this thread, only reiterating for those who seem to have missed previous reiterations: 'The more ports you leave open, the greater chance you have of being cracked.' 'If you don't know why you need it, you don't need it.' It seems reasonable that the default installation should try to make itself useful to the average target user. Now, by a show of hands (rather than a string of replies), how many of us have sat down at our newly-installed machines and said All right, time to get my discard service on! Let's follow that up with a little chargen, while we're at it! They may be legitimate services with legitimate uses, but are not needed in the normal case, and as such, should not be activated in the default case. The argument below is pretty bad. Have you ever heard of anybody actually getting impaled by holding a sword poised at his belly and walking into grand central station at 5:00pm going 'scuse me, pardon me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it? Our hypothetical late friend didn't need to be doing it, and he shouldn't have been doing it. ...which brings me to my next point: just because I've never heard of such a ridiculous demise actually occuring doesn't rule out the possibility that it has. And just because you haven't heard of exploits involving these services doesn't mean they haven't been around. Again, a reiteration of wiser words earlier in the thread: the standard inetd services including discard, echo, sysstat, netstat et al all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Vineet * Noah Meyerhans ([EMAIL PROTECTED]) [010618 10:51]: Why not? You've not given any reason at all. Do you know of any malicious behavior that is made possible by leaving the services turned on? The potential exists to use the chargen feature as a part of a DoS attack, but I've not heard of it ever being used as it's not particularly effective unless you have many many machines available, and even then there are much more effective weapons. And what about the rest of the ports? How are they dangerous? I've never heard of an exploit involving any of them. Really I'm just playing devil's advocate here. I don't care if they're turned off or not. I've just never seen any evidence that there's any reason for concern over them. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpo1zzoxfxVx.pgp Description: PGP signature
[no subject]
unsubscribe
Re: rlinetd security
Noah Meyerhans [EMAIL PROTECTED] writes:
On Mon, Jun 18, 2001 at 06:35:03PM +0100, Tim Haynes wrote:
b) they shouldn't be. You'll have to check if they still appear by
default
[snip]
Why not? You've not given any reason at all. Do you know of any malicious
behavior that is made possible by leaving the services turned on?
I don't need to, as my point earlier included `you don't know there won't
be a vulnerability tomorrow'.
But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
whenever. I wouldn't want someone to know exactly what time my boxes
thought it was.
The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not particularly
effective unless you have many many machines available, and even then
there are much more effective weapons.
http://www.sans.org/infosecFAQ/malicious/naptha.htm, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?
Really I'm just playing devil's advocate here. I don't care if they're
turned off or not. I've just never seen any evidence that there's any
reason for concern over them.
There doesn't have to be a reason for concern for you to not want them
available. I don't want anyone so much as fingerprinting my box (given that
nmap relies mostly on TCP responses to guage OS), let alone doing anything
really interesting with it.
~Tim
--
The light of the world keeps shining, |[EMAIL PROTECTED]
Bright in the primal glow |http://spodzone.org.uk/
Re: rlinetd security
On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote:
The argument below is pretty bad. Have you ever heard of anybody
actually getting impaled by holding a sword poised at his belly and
walking into grand central station at 5:00pm going 'scuse me, pardon
me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it?
Our hypothetical late friend didn't need to be doing it, and he
shouldn't have been doing it.
Huh? You've acknowledged that there may be legitimate uses for the
simple services that you may be ignorant of. I don't think there is any
legitimate gain to be had be running around a crowded area with a blade
against your belly.
the standard inetd services including discard, echo, sysstat,
netstat et al all *have* *had* their known vulnerabilities before now.
All long-since patched, but that's not to say there won't be another
tomorrow.
Have you looked at their code? I can assure you that there is no
potential for remote exploit in
void
discard_stream(int s, struct servtab *sep)
{
char buffer[BUFSIZE];
setproctitle(sep-se_service, s);
while ((errno = 0, read(s, buffer, sizeof(buffer)) 0) ||
errno == EINTR)
;
exit(0);
}
Or how 'bout this:
/* Return human-readable time of day */
void
daytime_stream(int s, struct servtab *sep)
{
char buffer[256];
time_t clocc;
(void)sep;
clocc = time(NULL);
snprintf(buffer, sizeof(buffer), %.24s\r\n, ctime(clocc));
write(s, buffer, strlen(buffer));
}
These services are so simple that any moderately knowledgeable coder can
ensure that there is no risk to leaving the services turned on.
noah
--
___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
pgp4hkG0LGaVt.pgp
Description: PGP signature
Re: gnupg problem
On Mon, Jun 18, 2001 at 10:55:04AM -0700 , Thomas Bushnell, BSG wrote:
Debian is about a *distribution* and not a random assemblage of
OK, distribution. That's dists/potato/main/binary-arch/Packages
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Try: cat /dev/urandom | perl
Re: rlinetd security
On Mon, Jun 18, 2001 at 07:25:37PM +0100, Tim Haynes wrote:
But that said, I gather leaking one's timestamp is not a good thing
(leaking *anything* is not really any good). I'm no Kerberos user, but I
heard you can do time-dependent auth in that a given ticket is good until
whenever. I wouldn't want someone to know exactly what time my boxes
thought it was.
So I assume you stay very clear of any kind of time synchronization
(ntpd and the like). In order for things like Kerberos to work (BTW, I
am a kerberos user) the client machines have to be very closely
synchronized with the authentication server. NTP is how this is done.
Giving out your time via either the daytime or time simple service is
not giving out any info that's not already available to anybody who
cares to look.
The potential exists to use the chargen feature as a part of a DoS
attack, but I've not heard of it ever being used as it's not particularly
effective unless you have many many machines available, and even then
there are much more effective weapons.
http://www.sans.org/infosecFAQ/malicious/naptha.htm, btw. Why bother
hooking /dev/{zero,null} onto the net with netcat when you can cause a fair
bit of traffic with standard services that do much the same thing?
Yes, but you know what? 'ping -f' works just as good, if not better.
Do you have ICMP filtered at your router?
--
___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
pgpHBQyrZ4Pyt.pgp
Description: PGP signature
RE: rlinetd security
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Haynes Sent: Monday, June 18, 2001 10:35 AM To: Sebastiaan Cc: Tim Haynes; [EMAIL PROTECTED]; debian-security@lists.debian.org Subject: Re: rlinetd security Sebastiaan [EMAIL PROTECTED] writes: [snip] Again, if you don't know why you need it, you don't need it. I know you are right, but I have become curious now: if everyone says that you do not need them, then where are they used for? And why are they still installed by default? Good questions. a) echo is just there to duplicate everything you send back at you. discard is just there to dump everything in the sink. chargen is to give a continual stream of output, eg bandwidth testing daytime is to give another box a snapshot of the time on here - a crude ancient horrible way to sync boxes netstat is to give a view of `netstat' over the 'net - remote admin? [snip] Now that answers some questions. Much better. At least when I turn them off I will have a clue about what might break. BTW, my philosophy on disabling unknown services/ports has been to disable it and see if anything breaks. If something breaks, then figure out what to do about it. But, this can be a tough philosophy on production machines. (No, I don't have machines that I can test with here. Nor do I have the time to set them up.) The concept of 'if you don't know why your running them you don't need them.' may be good advice but doesn't help those of use that are trying to understand Security. Pat Moffitt MIS Administrator Western Recreational Vehicles, Inc.
Re: rlinetd security
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jun 18, 2001 at 11:08:49AM -0700, Vineet Kumar wrote: The argument below is pretty bad. Have you ever heard of anybody actually getting impaled by holding a sword poised at his belly and walking into grand central station at 5:00pm going 'scuse me, pardon me, 'scuse me, pardon *GGUAGHGH!*? I sure haven't. So why not do it? Our hypothetical late friend didn't need to be doing it, and he shouldn't have been doing it. Huh? You've acknowledged that there may be legitimate uses for the simple services that you may be ignorant of. I don't think there is any legitimate gain to be had be running around a crowded area with a blade against your belly. The point is that these things can be used for good or evil. If you're not going to use it for good, whether someone else can or not, a nasty chap can still use it for evil. You realise rpc.statd has its uses, as does ftpd? Is that some reason to enable them `just in case somebody wants to use them for legitimate reasons'? the standard inetd services including discard, echo, sysstat, netstat et al all *have* *had* their known vulnerabilities before now. All long-since patched, but that's not to say there won't be another tomorrow. Have you looked at their code? I can assure you that there is no potential for remote exploit in void discard_stream(int s, struct servtab *sep) [snip] These services are so simple that any moderately knowledgeable coder can ensure that there is no risk to leaving the services turned on. There isn't? What about in your choice of C-library, then, have you audited that? While you're here, what tweaks are going to be made to these functions next week? The principle is still the same. It's not enough to ask whether you need it or not and assume something can be left on if you don't know any better; if another vulnerability comes out you have to check one more thing to see whether it's relevant or not, which is a waste of time, at best, and an omitted necessary update to an unused service (unused, until someone scans you for it, that is) at worst. Incidentally, in your dismissal of exploits for these things, you're neglecting another scenario: black-hat *does* manage to crack another box in the organization, and points multiple netcats from the exploited box at someone with echo: you'll end up with enough network traffic load to cause a slow-down, and the traffic may possibly help him mask very nasty activities in the noise. ~Tim -- All I see, All I know |[EMAIL PROTECTED] Is touching the sacred earth|http://spodzone.org.uk/ And warming the hallowed ground |
