Are there any known vulnerabilities in portmap (redhat''s portmap-4.0-7b)? I''ve been receiving a lot of attempts to access the portmap port on some linuxppc machines I administer by various machines which clearly have no business with mine, and I wonder if this is an attempt to break in to my machines. I''ve searched some archives, but I haven''t yet found any known vulnerabilities in portmap that are likely to lead to any compromise of system security. If this is indeed a hack attempt (I believe it is), then this suggests that (a) there''s some well-known vulnerability that I have been unable to find out about, or (b) this is a new exploit. I haven''t yet looked at the source to see if there are any obvious problems with portmap (buffer overflows, etc.), but I suspect that there may be. -sq
Some versions of portmap would allow users to read/modify their table or would forward requests as the local system. You might just be getting attempts to try to exploit these holes. I would probably disable the portmap daemon if you don''t need it. Reading the readme that comes with the package also gives more info on the vulnerabilities that may be present. On 5 Dec 1998, Sam Quigley wrote:> > Are there any known vulnerabilities in portmap (redhat''s > portmap-4.0-7b)? I''ve been receiving a lot of attempts to access the > portmap port on some linuxppc machines I administer by various > machines which clearly have no business with mine, and I wonder if > this is an attempt to break in to my machines.
Sam Quigley:> > Are there any known vulnerabilities in portmap (redhat''s > portmap-4.0-7b)? I''ve been receiving a lot of attempts to access the > portmap port on some linuxppc machines I administer by various > machines which clearly have no business with mine, and I wonder if > this is an attempt to break in to my machines.Reportedly, there''s an automated tool that looks for vulnerable RPC daemons. The portmapper is a dictionary service. RPC daemons register with the portmapper. That''s how the attacker finds them. Wietse
Sam Quigley <osquigle@cs.uchicago.edu> writes:> Are there any known vulnerabilities in portmap (redhat''s > portmap-4.0-7b)? I''ve been receiving a lot of attempts to access the > portmap port on some linuxppc machines I administer by various > machines which clearly have no business with mine, and I wonder if > this is an attempt to break in to my machines....> I haven''t yet looked at the source to see if there are any obvious > problems with portmap (buffer overflows, etc.), but I suspect that > there may be. > > -sqI actually now have reason to believe that these probes were part of a search to find machines running mountd, in an attempt to exploit the recently-publicized bugs in that code. portmap itself doesn''t seem to have been the target of the attack, although on my machines that was how the attack manifested itself. So this note becomes, rather, a warning to others that people are actively attempting to exploit the mountd vulnerabilities: be careful. -sq
Christopher Lindsey wrote:> > Some versions of portmap would allow users to read/modify > > their table or would forward requests as the local system. You > > might just be getting attempts to try to exploit these holes. I > > would probably disable the portmap daemon if you don''t need it. Reading > > the readme that comes with the package also gives more info on the > > vulnerabilities that may be present. > > And of course if you must run portmap, use TCP wrappers to limit > it to a certain range of hosts. Assuming that hosts.deny hasActually, portmapper cannot run "behind" tcp wrappers. It opens its port and waits for connections. However, it seems that modern portmappers are linked with the library from tcpwrappers, so that it takes the same config files as the tcpwrappers do. Nifty!> ALL:ALL > > You can add an entry like > > portmap:199.198.24.0/255.255.255.0 > > (assuming you''re at redhat.com and want to limit RPC services to that > IP block)... > > rpc.mountd can also be limited, but I don''t know if that support > is in the default RedHat binaries. You can always grab the source > from > > ftp://linux.mathematik.tu-darmstadt.de/pub/linux/people/okir/ > > Chris >Roger. -- My pet light bulb is a year old today. \_________ R.E.Wolff@BitWizard.nl That''s 5.9*10^12 miles. Your mileage will NOT vary.\__Phone: +31-15-2137555 --(time <-> distance can be converted: lightspeed)-- \____ fax: ..-2138217 We write Linux device drivers for any device you may have! \_______________
On 9 Dec 1998 R.E.Wolff@BitWizard.nl wrote:> Christopher Lindsey wrote: > > And of course if you must run portmap, use TCP wrappers to limit > > it to a certain range of hosts. Assuming that hosts.deny has > > Actually, portmapper cannot run "behind" tcp wrappers. It opens > its port and waits for connections. However, it seems that modern > portmappers are linked with the library from tcpwrappers, so that > it takes the same config files as the tcpwrappers do. Nifty! ><-snip->> > rpc.mountd can also be limited, but I don''t know if that support > > is in the default RedHat binaries. You can always grab the source > > from > > > > ftp://linux.mathematik.tu-darmstadt.de/pub/linux/people/okir/Another solution is to compile the kernel with IP firewalling and do the filtering at the kernel level. This solution will be port- specific rather than application-specific, but it will work with anything - whether or not it''s wrapper-aware. -ps Paul Schmidt < >< PSchmidt at Custom dot Net Bloomfield, IN USA Linux 2.0.36 web: viaduct.custom.net/pschmidt
On 9 Dec 1998 BigJason@tamu.edu wrote:> Does anyone know what ports to restrict? I tried doing the below > as part of a script, but the NFS mount on $B stops working. > Any ideas? I wish I could find a list of ports for each service, > especially the RPC based ones. > > A="192.168.1.1" > B="192.161.1.2" > > # Deny NFS to everyone > $IPFWADM -I -a deny -P udp -D $A 111 > $IPFWADM -I -a deny -P udp -D $A 635 > $IPFWADM -I -a deny -P udp -D $A 2049 > $IPFWADM -I -a deny -P tcp -D $A 111 > $IPFWADM -I -a deny -P tcp -D $A 635 > > # Only allow B to mount NFS shares > $IPFWADM -I -a accept -P udp -S $B -D $A 111 > $IPFWADM -I -a accept -P udp -S $B -D $A 635 > $IPFWADM -I -a accept -P udp -S $B -D $A 2049 > $IPFWADM -I -a accept -P tcp -S $B -D $A 111 > $IPFWADM -I -a accept -P tcp -S $B -D $A 635The -a command in ipfwadm adds the rule to the end of the list. Since the firewalling code exits (whether pass or fail) on the first rule that matches, the 'deny to everyone' locked out the desired host. You need the host-by-host allow entries to be before the deny entries. At my office ({something}.mil) I block outside UDP to any ports below 1024 (Except on the name server, which allows 53, of course). This is in addition to most of my boxes being behind both a firewall and a filtering router. Similarly, all of my boxes except a very few specifically allowed to be accessed from the outside (with OPIE passwords, etc - not straight telnet!) are blocked for all privileged (low-numbered) port TCP accesses, and the rest are blocked for non-essential privileged ports. Yes, I *am* paranoid. Getting hacked is too much paperwork. (By outside access, I mean access from any address not within the office network - including other addresses on the installation, which are outside of my office's filtering router but still within the installation's firewall. I told you, I'm paranoid.) -ps -- Paul Schmidt < >< PSchmidt at Custom dot Net Bloomfield, IN USA Linux 2.0.36 web: viaduct.custom.net/pschmidt
In mail.linux.security cfb <cfb@ocn21.kdd-ok.ne.jp> wrote: : How many processes does something like ssmtp kick off? Not enough to be : significant, plus you won't risk having your filesystem fill up. Just The mail needs to go to a spool. The spool needs to be saved to a disk. The disk is finite. Words like "not enough to be significant" can get you in trouble very quickly in security. :) -- -Matt Drown -- Privacy, Anonyminity, & Security -- DataHaven Project panzer@dhp.com -- Shell and Web accounts -- http://www.dhp.com/
-----Original Message----- From: cfb [mailto:cfb@ocn21.kdd-ok.ne.jp] Sent: Sunday, December 13, 1998 5:16 AM To: Matt Subject: [linux-security] Re: portmap vulnerability?>... or did I just miss something in the man page? >Might this be a handy way to detect port scans or spoofed packets (if >connections are being initiated at ports that don't respond/handshake, >what else could it be (disregarding udp, of course)?)? Maybe that's a >bit beyond the current scope of wrappers, but it would be nice. Oh >well, more work for someone else...Hmm... speaking of putting unused ports to work to detect port scans -- here's a cute piece of software that does just that + a bit more: http://www.psionic.com/abacus/abacus.html Take a look at the "Sentry" software. Besides detecting TCP & UDP port scans, it has the ability immediately add the offending host to hosts.deny, as well as adding a bogus route back to them in the routing table... effectively making you disappear. I've run it for about two months now on a server that gets sniffed at a lot. It works. I can think of a couple of ways someone could turn this software against you ("scanning" you with packets with a spoofed source IP that matches a legitimate host you haven't defined to ignore -- thus breaking the routing), but In Real Life, it has done very well. Mark [mod: Message body reformatted for clarity. -- REW] [mod: This is also a controversial tool. Mark knows the disatvantages and he mentions them. What works for him may work for you. Maybe not. So lets not discuss "security polcies" again OK? -- REW]