OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: Proxy 2.0 secure? (AG vs. SPF)

Re: Proxy 2.0 secure? (AG vs. SPF)

Paul D. Robertson (probertsclark.net)
Fri, 3 Jul 1998 11:19:35 -0400 (EDT)

On Wed, 1 Jul 1998, Ryan Russell wrote:

> >Except that most people configure them to have their on-board management
> >interface features or other native stack based services (such as VPNs in
> >one exceedingly popular implementation) available, making both *them*
> >_and_ their "protectees" vulnerable to transport and internetwork layer
> >attacks.
>
> Not sure I'm following you... I think you saying that some SPF vendors
> have "the worst of both worlds" where they use SPF to gateway some
> things, and AG for others? You'll get no arguement from me that most
> SPF vendors on the market now are very sloppy. It makes it hard
> to argue in favor of the SPF concept when most of the commercial
> SPF vendors do the *minimum* they need to to get things to pass.

Not quite. Even in pure SPF mode, VPNs, remote management consoles,
etc. use the host IP stack of the gateway, which is supposedly
vulnerable to the same types of attack that the AG's stack is. You
can't not have a stack on the SPF if you want to do some things. In
those cases, it's not really an AG, it's just a server.

> >It doesn't mean that someone can't (a) write a better stack for an
> >application layer gateway, or (b) write an applicaiton layer gateway
> >that does its stack stuff inside user space on a B2 OS either, no?
>
> I guess that means that for an AG vendor to be able to truly do a good
> job, they HAVE to write their own IP stack. I don't know enough about
> the B2 OS requirements to speak to that... but if the IP stack itself
> still runs in something like a kernel, it doesn't help for low level
> attacks.

Yes, it can help. a bug running in a non-privileged context is much less
serious than one running in such a context. FWIW, it doesn't mean the
vendor has to write their own stack, it means that the stack has to have
an ammmount of trust. Under B2, if the stack is part of the evalueation
it's got a higher level of trust than your generic IP stack from anyone
else. Under B2, it also plays well with the other components of the
TCB, so you can ensure that, for instance, only workstation Z can
remotely access firewall A. Actually, the Linux user mode network
drivers look rather interesting in this regard as well.

> What would really need to happen would be for the IP stack to run
> in user space of a restricted user, as well as the AG code. That
> means that the OS itself isn't handing out sockets, which is...
> well, I guess that is my earlier definition of an SPF.

Most SPFs have only a single context, so your definition doesn't seem to
bear out what the market has engineered.

>
> >Well, I'm not sure you need complete trust. Trust for lack of bugs
> >which would cause an intrusion, certainly. Trust against easy SNPA's,
> >probably, trust against fragmentation bugs, sure. Trust against DOS
> >attacks when IP itself is subject to them doesn't seem overly reasonable
> >in an absolute sense.
>
> SNPA? Define, please.

Sequence Number Prediction Attack.

> In reality, you can't completely trust anything, even if you
> write it yourself. Realisically, what you do is watch the lists for
> problem reports, and patch things quickly, AG or SPF.
>
> >At which point SPF gains nothing over a stable IP stack, since you're
> >into the same ammount of complexity as an AG, and T&V of said
> >implementation gets significantly more difficult. State tables that
> >include layer 3/4 information start getting pretty unwieldy to verify.
>
> As I've pointed out in a seperate note which probably hasn't hit the list
> yet,
> you can get a little extra info about the packet that came in with
> the SPF implementation than you can with the AG implementation.
> I get a lot of people claiming that tables that maintain transport info
> are too hard. I haven't written an IP stack, but isn't that what they do?

For some transports they do, for others they don't. An SPF has to
maintain it for all transports, even those which don't have state
information, which means guessing when things are over. Also, when you
throw in the application layer code, your state tables will become a
real mess. I think it's easy to infer how difficult it is to test
things by the state of SPFs on the market.

> >If you already know what to strip off. It tends to look like "anything
> >wich is explictly denied" as a stance, rather than "anything which is
> >explicitly allowed".
>
> Current SPF vendors do it the wrong way, described above. AGs
> are in the same position, though. Well, their IP stack they sit
> on, really. They've just gone through the iterations needed over the years
> to figure out what to pass and what not to pass. The question to ask is
> whether that logic learned from 20 years of doing decent IP stacks
> can be translated to SPFs. I haven't written either, so I'm not
> qualified to comment.
>
> >I'd take the former over the latter any day, since the IP handler can't
> >have worked out attacks at the application layer, wheras the IP stack on
> >an AG is about security of the gateway, not its charges.
>
> I'm trying to show that an SPF IP handler can be equivalent to an
> OS IP stack. You can take a good HTTP proxy and slap it on
> top of an SPF IP handler to the same effect.

And I'm saying that the complexity of doing so without using a stack is
enourmous, and very difficult to verify, especially in the interface to
the application layer, sequencing, fragmentation handling, and
extensions to new protocols. At this point, building packet filtering
in front of an IP stack, to me, makes much more sense and is
significantly easier to verify, and verification is very important in
security.

> >At which point, being an AG gives it no real advantage, and you're still
> >minus application layer protections unless you intend to keep
> >application layer state which won't be as easy to verify as the
> >application itself.
>
> Depends on how you want to track application layer state. Using
> a "stateful packet filter" doesn't mean you have to interface with
> it with a state machine. On the other hand, you could if you wanted.

Well, if you're going to magically re-create the Berkely sockets
interface, and full functionality in your SPF, you're going to end up
with an IP stack, at which point, you'll have gained not a lot, except a
great understanding of IP stacks IMO.

> This, of course assumes (a) the SPF is well-written, and (b) the SPF
> >doesn't need the same services to be as well written. That means
> >console or TTY-only access to the SPF, and no VPNs over IP, since both
> >of those need to participate as an application layer service on the
> >SPF. Given both written to the same quality, I'll take the AG any day.
> >Given a chance to verify a design and implementation, I'd much rather
> >pour over the AG code, even if it does look like http-gw ;)
>
> How about an example? Cisco routers can do VPNs. Cisco
> routers can now do secure TTY access. Would you consider

Cisco routers have an IP stack. That's why you can telnet to them.
For the purposes of that, SNMP mangagement, and VPNs, they are a server,

> those to be more like SPFs, or AGs? I suspect Cisco is
> not going to let you review their source-code, though.

I suspect that if I had a need to look at Cisco's source code, it would
be a few NDAs and a trip to California to review their source code. If
not, I'd be going to a different vendor. I rarely have difficulty
getting vendors to play nicely, it's something that I require when I do
vendor selection.

> >More comprehensive layer 2/3 security, sure, but application layer
> >exploits are still the most popular, and it's very difficult to protect
> >at the application layer in an SPF. Heck, it's been plain amusing
> >watching the SPF folks just try to block javascript.
>
> Slap your favorite HTTP AG code on top of your SPF IP handler.

I've yet to see an SPF with accept(), listen(), connect(), etc. Once
again, I'd really like to see articulated what the gains of such would
be over adding filtering in front of an IP stack. I don't see any, and
indeed, I think it's a detriment to come from the other end of the field.

> >The question remains if the lower level data poses the same kind of risk
> >and if the stack can't evolve to mitigate that risk. If it can, and I
> >for one am convinced that it can, then I don't think you're getting any
> >value for the complexity of an SPF versus the same quality AG, though
> >the percieved need for new protocols may make the market go more towards
> >SPFs, I don't think security properties will be the driving force.
>
> an OS IP stack has the same challenge as an SPF IP handler of needing
> to do good data validation, and be able to handle new attacks, hopefully.
> Realistically, either will fail to anticipate something, and hopefully your
> vendor reacts quickly with a patch. A possible security advantage of
> an SPF is that it's not part of the kernel, and can live in user space.

Every implementation that I've seen has been either part of the kernel, or
tied to drivers running in the kernel space. Even if you were to open a
raw socket, that lives there. In some OS', you stand to take a context
switch for every packet that goes into user space, which isn't going to
do wonders for your performance.

I'm still not convinced that recreating the complete behaviour of an IP
stack just to get the code into user space is worth doing (especially
if said behaviour includes VPNs or remote access). I don't
see the risks of the IP stack in being kernel mode as that
significant. The only attack vector that seeks to stop is an attack on
the gateway itself. Since IP stack attacks have all been, and seem to
be limited to DoS attacks, they can be perpatrated just as well for code
running in a user context.

> Maybe that makes the unanticpated attack less serious. The challenge
> is to get a good SPF implementation in user space without screwing
> something up that the IP stack vendors fixed 15 years ago.

Again, doesn't it make more sense to add filtering in front of a solid
stack?

> >Much like plug-gw, it's transport layer proxying, but beyond nothing
> >wrong with fragment reassembly, I think it's rather bad to expect an SPF
> >not to do reassembly if its to have much security value at all for
> >traffic which is passed (as opposed to the value it has for blocked
> >traffic).
>
> This is a difference of definition. I can see where the idea of
> SPFs only handling one, whole packet at a time comes from.
> That's not the definition I use, and not where the market went.
>
> >DOS'ed, instead of random DOS'ing against various internal machines. I
> >know which one I'd rather (a) troubleshoot, and (b) be responsible for
> >if I had to pick. For most companies, which don't *need* the Internet
> >every day to continue operations, my guess would be that the choice
> >would be the same.
>
> A long as it's just DoS, that's fine. For an example where it's not fine,
> look at the panix.com situation when the whole SYN flooding attack
> thing began. For any commercial OS or SPF, you'd be stuck waiting
> for a patch. If you've got source, conceptually for me it's pretty easy

Well, I'll assert that IP itself, and indeed any packet based data
protocol is subject to some flood attacks as a matter of course. SYN
flooding certainly lowered the bar on a flood attack, but it didn't stop
the fact that panix.com could still be flooded off the Net. I certainly
have enough bandwidth available to flood them off the Net. Repeatedly.

> to see how to solve that problem in the SPF (that the SYN-flooded
> machine is behind.) But then, I'm a layer-1 up type of person.
> Possibly for a OS down type of person the code needed to
> fix the unix kernal would be as trivial. My understanding is that it's
> a fairly involved kernel mod. Most OSes seem to have only bumped
> the number of buffers up, not really solved the base problem.

Take a look at the Linux SYN and RST cookies for a solution. FWIW, most
of my external systems were already tuned enough to not be threatened by
SYN flooding due to their normal traffic loads. SYN flooding only
lowered the bar to floods, which are a fact of life in a packet based
network where one doesn't control all the machines.

> >The problem as I see it, is that in the world of IDS, you have to predict
> >how the host may view the packet and with N IP implementations that
> >means N+ probabilities. We go from "Is it an intrusion" to "Is it an
> >intrusion if the host is running NT?"...
>
> Thomas Ptacek has done a lot more checking into this area than
> I have, and he says that it's a really hard problem. I'll take
> his word for it until I can catch up on his paper. I'd be willing to
> believe
> that this would be hard for traditional packet filters that can't change
> the packet structure much. If an AG helps because it rebuilds
> the packet, then I ask if an SPF can't reassemble/rebuild/normalize
> packets in much the same way to get the same protection. I suppose
> neither will help if someone finds someday that a certain IP stack
> hands over root or admin if it gets a TCP connection with "xyzzy"
> anywhere in the stream.

This issue is that fragmentation reassembly is done differently in
different stacks, so your SPF would have to know how a particular host
reassembles fragments before it could protect that host if it isn't
doing frag reassembly itself (see my earlier comment on this). Of
course, if it is reassembling fragments, it has to do it one way, so
non-malicious fragments could break for some instances.

> >How does the SPF answering system calls give application layer protection?
> >How is a really well written SPF more advantageous than a really well
> >written IP stack? It would seem to me that the latter is much more
> >effective since it could be deployed on the application client and
> >server machines themselves as well.
>
> Real simple. Take the AG code, and link it with a library that
> makes it think it's running on the OS IP stack, when in reality
> it's allocating table entries from the SPF rather than sockets
> from the OS.

At which point, you have gained what exactly? Are you saying that the
OS isn't going to handle packets at all? Why not just make the network
devs user R/W and run your stack in user space as a user mode driver
then? Same gain, nowhere near as much work.

> >Not really trying to be facetious, I'm just curious as to why people
> >propose SPFs can be well written and IP stacks can't, or why there's
> >value to doing so for an SPF that wouldn't be more easily realized in an
> >IP stack.
>
> What sets me off is blanket statements like "SPFs are always less secure
> than AGs" or "State tables are too easily corrupted." People believe
> this stuff. A really good SPF can be written, and probably will someday.
> If someone wants to say that Firewall-1 shouldn't be used because
> of x,y, and z, I won't argue that. Don't get me wrong, there are some
> really good
> AGs out there, with the vendor having the exact right attitude on what to
> limit.
> Having a barrier between IP stack and AG code, with good code for each,
> is a really good model, is well understood, and is modular. I won't tell
> anyone to
> not implement the best AG on the market in favor of some SPF solution if
> the AG handles all the protocols desired.

Since there isn't yet an SPF solution which truly applies its state
protection mechanisms to everything it passes, the discussion is rather
academic, but perhaps you'd like to enumerate "handles all the protocols
desired"? For me, if a protocol isn't given some sort of transport,
internetwork, and application layer protections, it's not "handled", and
I'm not gaining significant protection over a non-stateful packet
filter.

As for the state tables, the complexity is fairly easy to figure out,
and you can do this on paper by flowcharting. Start with the first
fragment of a fragmented packet for a TCP connection for HTTP. Note the
things you can keep information on, such as frag number, size, frag offset,
sequence number, source port, dest port, source IP, dest IP, as well as
some application transport protocol information, and application layer
data information. Make a decision box for each of them, and hook it
into your flow of inspection. Then do the next few packets, keeping in
mind packets too large, fragment overlaps, and every problem you can have at
the IP layer, and the TCP layer. Now add in problems at the HTTP layer, then
at the data layer. Look at how much you have to investigate to see if
the next packet or fragment should get through. Now, take into account
that a mistake or something overlooked in any of those areas means that
an internal host is potentially compromised. Blocking Javascript on a
per-packet basis, with out-of-order packets and fragments is left as an
extra credit item.

Now, look at the AG model, where a problem means that the bastion is
potentially down. No contest.

Why down versus compromise? Because, from what I can see in the code of the
stacks I've got, the potential problems are with overwriting internal data
structures, not getting onto the stack. In the internal machine case, it may
be a DoS, or it may be an intrusion, depending on what slips by, and what it
effects. So, yes, it's my assertion that AG's are inherently more secure
than SPFs, as a design.

Implementations are another matter of course, but you seem to assert for a
perfect SPF versus an imperfect host for the AG, if you level the playing
field, an imperfect SPF risks much more, and a perfect SPF either starts
writing applicaiton layer code, or drowns in a sea of state.

For all their blusering of the benifits of SPFs, the current set of vendors
has moved rather quickly to writing application layer code to sit on their
engines. I'll also assert that it's easier to protect a stack than to
write one, and adding filtering to a stack is much easier to do than to
recreate that stack.

Whilst keeping state does add some measure of protection, it really only
brings value to non-TCP protocols, since TCP has a built in state
mechanism, and that same state can be done in the AG's code for the
application, or even a generic stateless protocol handler on a raw socket
without reinventing the wheel for the case of non-TCP protocols.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
probertsclark.net which may have no basis whatsoever in fact."
                                                                     PSB#9280

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:31 CDT