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

["Paul D. Robertson" <proberts () clark net>]

On Fri, 3 Jul 1998, Ryan Russell wrote:

> > 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.
>
> There are VPN implementations that don't rely on the host IP
> stack.  Management functions could be done via SPF without
> using the host IP stack, too.  It wouldn't be tha hard to use
> the SPF VPN code to verify the connection, and then just
> extract the data portion of the packets, UDP sytle.

At this point, you've recreated the functionality of the stack, why is 
this recreation any less bug ridden, or more functional than the 
original stack you're replacing?

> > 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,
>
> If the vendor wants to be able to verify all of the security aspects
> of their gateway, they have to write the stack themselves, or
> get the source and verify it themselves, making any needed changes,
> or trusting it for that reason.  I said it for that reason, not for any
> kind
> of B2 reason, which I am, again, ignorant about.

The best thing about B2 is that the source is audited line-by-line.  The 
next best is that the code is designed to play nicely with the 
authentication and authorization mechanisms built into the OS.  This 
means you can limit the Mandatory Access Control label and capability 
that a packet has, which limits the things it can access.  Eg. If you 
don't want packets from interface A to be able to access anything but 
Web Proxy 1, then it is so.  No matter what bugs there are in the packet 
handing, stack, or proxy.  

> > Most SPFs have only a single context, so your definition doesn't seem to
> > bear out what the market has engineered.
>
> I don't know of any implementation of the kind of SPF I'd like to see.
>
> > > 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.
>
> FW-1 uses timers.  Obviously, you'd want to know the protocol
> so know when the conversation was over, if it's possible
> with that protocol.

Obviously, this means that the protection isn't complete, and can't be 
made to be so, unlike an application layer gateway.

> > 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.
>
> Only if you handle application logic as a state machine.  This would
> be pretty easy with some protocols, and obviously not for
> others.  Application logic doesn't have to be written like a
> state machine to sit on an SPF.

Once again, unless you are going to write completely new application 
logic, you'll have to recode sockets, either way, you're introducing 
more space for bugs.

> > 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.
>
> I assume that IP stacks are hard to verify (I haven't done it
> before.)  I assume this because of all the IP stack problems
> that crop up.

There really haven't been a large number of problems, one frag problem 
(manifested three ways), and SYN floods are the most recent, FO=1 stuff 
a while back, but overall stacks have done rather well considering most 
date from way back when.

> > > 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.
>
> If you limit yourself to the sockets interface, you lose the ability
> to get the lower-layer information you might want to know about
> in a security context.  It would be reasonable to have more that
> one API into the lower part of the SPF.  One that lets you write more
> informed application protocol handling code, and one that
> lets you re-compile sockets proxies, so you can make it
> act like an IP stack.

Again, more room for error, this new code won't magically be bug-free.  
Also, I'm not sure that the types of attacks that manifest themselves at 
the lower layers need to go to the application proxy, I think they can 
be dealt with independently.

> > 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,
>
> It has an IP stack, but does it use it for the VPN?  (I don't know,
> I'll check next time I set up an IOS VPN.)

I'm not 100% sure if it does for VPN work, it certianly does for telnet 
and SNMP.  FW1 uses the host stack for VPNs, remote access, and SNMP.  

> > 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.
>
> As mentioned above, this lets you have one "IP stack" instead
> of two... i.e. just SPF IP stack, instead of SPF and real IP stack.

Filters in front of an IP stack don't make for two stacks, they just 
limit what gets passed to the stack.

> > 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.
>
> They have to be root in order to "own" the NIC.  I imagine this could
> be fixed.

Once again, why not take the lower barrier and run IP in user space, 
this is a trivial change, not that there's anything particularly much to 
gain unless you're worried about intrusions via the IP stack, and even 
then an intrusion is an intrusion.  Obviously, I'm still not buying the 
predicate that this new piece of complex software is bug and intrusion 
free, and since most intrusions are via a Web server running in the user 
space, I don't think it solves the main problem.

> > 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.
>
> As long as it's just DoS attacks, and you don't mind going down when
> new attacks come out, that isn't a problem.

You're assuming there's an infinite number of attacks that can be 
perpatrated on the lower layers.  There aren't a heck of a lot of places 
that stacks can mess up, so far they've *all* been in IP fragment 
reassembly and TCP buffer code.  That's two places, and given the quite 
complex attacks folks seem to have tried, I think it's pretty much 
throwing out the baby with the bathwater to discard the stack at this 
point.  YPMV.  I also don't see how this new "thing that replaces a 
stack" will not have the same problem with new attacks, since it has to 
handle the packet reassembly itself.  Another thing we seem to have 
skipped is the whole URG pointer problem, which was a perfectly 
legitimately formed packet not being handled by the end station code 
correctly.  No packet filter could pre-protect from that, yet every 
non-affected proxy (that is, proxy on a stack without the problem, or 
more plainly every non-MS stack in existance) did.  How will your SPF 
handle this without pre-existing knowlege of the attack?

> > 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.
>
> Bandwidth attacks can't be defended against on the far end-point.
> SYN attacks are a result of bad IP stack design decisions, and can
> be defended against at the far end-point.  They're not really the
> same class of attack.

I beg to differ, they are exactly the same class of attack.  More 
packets than resources to handle the packets coming from upstream.

> > 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.
>
> As I said, most OSes didn't really fix the problem.  I assume that they
> didn't because they're either lazy, or its too hard.  So, those vendors
> aren't really suitable to have as your IP stack vendors.  As usual,
> Linux is the exception to the sloppy unix vendor.  (Everybody relax..
> I'm taking jabs at Sun, HP, etc..  not everyone's favorite flavor of
> *bsd, etc... :)

It's obvious (to me) that you need to have some measure of trust in the 
gateway's native services unless you're disabling them.  It's possible 
to tune away the SYN flood problem on most modern hardware, while it 
doesn't "fix" the problem, it makes it so that the problem never 
mainifests itself.  

> > 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.
>
> AGs always rebuild frags in one way, correct?  They don't have
> to know about each inside stack, correct?  Then SPFs just
> need to have the same behaviour.  If rebuilding frags in a particular
> way can take out some inside host, the AGs suffer the same, correct?

The difference is that AG's reassemble frags, this would mean that SPFs 
would have to reassemble frags, and of course, that means things like 
being coded to make themselves not vulnerable to SYN floods, which they 
can't alleviate because they're not the ones sending out RSTs with the 
downstream's address.  It's difficult to keep both ends sync'ed if 
you're not an endpoint and you need to generate traffic to safeguard the 
conversation.  This is particularly true of attacks against currently 
established connections.

> > 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.
>
> Yes.. then the OS isn't allocating, and "using" the IP stack for itself,
> so the gateway isn't vulnerable, and the inside machines have
> the same amount of protection.  See my earlier definition of
> an SPF.

But it's possible to do this without any kind of packet filtering, the 
fact that it's not done is mostly because it doesn't sovle much.

> > Since there isn't yet an SPF solution which truly applies its state
> > protection mechanisms to everything it passes, the discussion is rather
> > academic,
>
> Yes, I'm trying to have a theoretical discussion.  I use commercial
> products as examples to help clarify things (hopefully.)
>
> > 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.
>
> Yup.  An excellent HTTP proxy doesn't help all that much if
> you need to pass 100 other protocols, and you end up having
> to packet filter on the AG gateway.  At that point you'd probably
> want an SPF for that.

No, I'd want proxies for the other 100 protocols, or a new set of users ;)

> > 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.
>
> While we know from Computer Science classes it's certainly
> possible to do the whole thing in a state machine, we could
> probably also guess that it wouldn't be much fun.  In practical terms,
> you'd want the app logic from a traditional HTTP proxy, with hooks added in
> to take advantage of the SPF information underneath.

But a traditional HTTP proxy doesn't need to know it's been FIN scanned, and
really doesn't benifit from that information, unless I'm missing 
something very basic here?  Yes, the machine wants to know, but the proxy?

> > 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.
>
> I know of at least one example of a really problem with an IP stack.
> It's not pushing code unto the remote machine, but it's an interesting
> example anyway.  Up until the most recent versions, Sun's IP stack
> from MS-DOS (called something like PC-NFS?) had a really interesting
> side-effect.  If you sent it a really large ping, like in the 64K
> neighborhood,
> the last bit of the pick replys wouldn't match what was originally sent.
> The
> guy who noticed this broke out a sniffer, and loooked at the last packet
> to see what was different.  He found the username and password
> (in cleartext) of the user who was logged-in on the remote machine.
> This was an all-in-one IP stack, so ping was handled by the stack itself.
> Don't run your AG on this stack :)

Ah, I'd forgotten the big packet stuff.  That's trivially fixed, and I'm 
surprised that Sun hasn't also learned to clear the buffers out.  One of 
the nice things about B2 is no object reuse all the way through the OS.  
Bet you can't tell what my latest toy is huh? ;)

> > 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.
>
> I can't really speak to implementation difficulty until/unless I write one
> someday.  You don't have to use a state machine to write an SPF.
> You seem to imply that ripping IP out of the kernel into userland
> wouldn't be too hard, and I claim that's a type of SPF.  The advantage
> is that you protect the gateway AND the inside machines.

I don't see how the IP stack running in user space is SPF, and not just 
an IP stack.  I also don't think it buys automatic protection, since (a) 
intrusion attacks haven't happened via a stack, and more importantly 
don't seem likely (anyone feel free to chime in with some 
how-it-could-happen's - this is a major predicate to my thinking), and 
intrusion of user-level code is how most machines are initially 
compromised these days.    

> > 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
> > recreate that stack.
>
> Yes, they suck.  Well, to be fair, I only have personal knowledge of
> FW-1 sucking.  I don't know enough about PIX except aparantly
> their VPN sucks.  I don't know if the Linux SPF-like packages
> suck, but if it's discovered that they do, I assume it will be fixed within
> a day or two.

Well, we can agree on most of the above at least.

> > 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.
>
> If all your protocols ride on TCP that might be ok.

Well, all of mine except one currently do, and that one has an 
application layer gateway.  Once again, a true application layer gateway 
can keep state for UDP, et al., so I don't see the argument there.

I haven't thunked this much since Win32 came out ;)

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