On Thu, 09 Aug 2001 15:30:52 CDT, Jesse Pollard <pollardat_private> said: Ummm... telnet is a bad example (see below). And unless you're only trying to address one *very* small part of a total picture here, you're not really buying much - a large chunk of exploits (for example, CGI script hacks) attack after your code would have been done with it. I'm not clear - is the intent here "build a sandboxed tcpwrapper"? If so, what do you do about things like Apache or Sendmail that do their own listen() but use libwrap.a for some front-ending? > The experiment is to completely isolate the network connection from being > able to do anything if it gets compromized. Any attempt to perform > disallowed system calls would terminate the process. This of course only protects the connection before authentication. You're still wide open to session hijacking/packet insertion hacks AFTER the authentication is finished, unless you use some crypto to secure the connection first. If the attacker can sniff the connection anywhere along the way (you aren't using 802.11 anyplace, are you? ;), he can watch the telnet start, get a handle on the seq numbers in use, DDOS some router along the way, and inject some packets. By the time the user realizes that it's not just a router hiccup, the damage is done... Of course, that makes your authentication helper more complicated, as it has to set up a crypto tunnel - which leaves you holding the bag on how to hand off a already-in-progress encrypted session. ;) No, I'm not saying it's a DUMB idea - I'm just wondering if some other better approach is called for. The Linux box I'm on right now doesn't have any inetd-managed listen()s active.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
This archive was generated by hypermail 2b30 : Thu Aug 09 2001 - 13:53:41 PDT