[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use IPSEC as SSH replacement
First, to Perry...
> > I had originally hoped, in fact, that IPSec would make tools like SSH
> > unnecessary by providing upper layer tools sufficient information that
> > they could simply ask the identity of the other side of any TCP
> > session from the security layer and not need to manage any
> > cryptography on their own at all. Sadly, things have not thus far
> > worked out this way, but it is not an unreasonable goal for people to
> > be striving for.
It is not an unreasonable goal. And BTW, these are the sort of requirements
IPsec extensions to a socket API require. The various sputterings (many of
them mine) about such APIs have tried to make sure that gets taken into
account.
Now on to Scott...
> It seems that one of the greatest impediments to this is the perceived
> vulnerability of the channel between the application and the ipsec
> layer.
Whose perceptions are these?
> I've been giving this a lot of thought lately due to the
> implications this vulnerability has for using ipsec to secure the
> (remote) configuration of ipsec-enabled devices. The argument I've heard
> most often is that in this and many other cases, there is a requirement
> for securing the data all the way to the (configuring) application, and
> that our current implementations don't fulfill this requirement. The
> diagram below illustrates:
>
> +-------------------------------------------------+
> | User Space |
> | +-------------+ +--------------+ |
> | | configuring | | rogue | |
> | | (or other) | | |
> | | application | | application,| |
> | +-----------|-+ | | |
> +--------------------|-------| code, +-----+
> | Kernel Space +--|-------+ | |
> | | ~ driver, etc. | |
> | +--|-------+--------------+ |
> | +--|-------------------------+ |
> | | V IPSEC Layer | |
> | +----------------------------+ |
> +-------------------------------------------------+
>
> In general, the user application seems to be vulnerable to the rogue
> application in several ways: (1) unencrypted data may be inspected prior
> to arriving in and after leaving the application, (2) unencrypted data
> may be inspected within the user app's runtime memory, (3) any
> additional (second factor) software authentication mechanism utilized by
> the user application is subject to compromise via the same avenues.
(1) can be implemented by a rogue run-time library. Especially on dynamic
loading/linking systems (including the product I work on), this may be a
problem. Keep in mind, however, that such dynamic libraries are part of
your trusted computing base. Writing to these libraries requires "root"
privilege, or some finer grained "system admin" privilege on a MLS
system.
(2) Is only a problem if the adversary has access to the application's
address space. Proper enforcement of process address space privilege (in
my world, this is enforced by procfs, i.e. /proc) should prevent this.
(3) See (1) and (2).
<SNIP!>
> problem, it does not address the general case you refer to above, i.e.
> securing user sessions on systems in arbitrary environments. This is an
> interesting problem which may not have a solution outside of the
> smartcard class.
As Perry as pointed out already, if your kernel has been compromised, you're
in a world of hurt. Or as we say here while explaining such vulnerabilities,
"If root is compromised, all bets are off!"
You make an eloquent case, Scott, for why OSes eventually need to migrate
toward an MLS model with mandatory access control.
Assuming you can trust your TCB, however, the "IPsec layer" can provide
valuable information to an application with decent socket API extensions.
Dan
References: