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

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

On Fri, 3 Jul 1998, Ryan Russell wrote:

> > 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?
>
> Well, as I've mentioned a few times now... It won't neccessarily be less
> buggy
> unless you take care to make it so, and it's more functional because the
> proxy
> code can have access to low-level info, it can live in userland, and it
> removes
> attacks against the gateway itself, while hopefully maintaining the same
> lvel of protection for the inside hosts.

Once again, can you provide how running in user mode stops attacks?  I'm 
sure the Web server people would be happy to hear it.

> > 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.
>
> I'm not following the logic here... source code review helps greatly, but
> it isn't foolproof, or else Linux wouldn't have problems.  I don't see how
> you can possibly claim that it is going to correctly maintain security
> despite bugs... I can see where designing independent layers can help,
> but it's not foolproof.

It's got to do with the fact that everything runs with a capability and 
MAC (as well as DAC) level.  No authority to anything really means no 
authority, not "no authority until you get root."

> > Obviously, this means that the protection isn't complete, and can't be
> > made to be so, unlike an application layer gateway.
>
> Of course it can be made so, just like an AG can.  Why can't it?

It isn't a participant in the conversation, that's why.

> > 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.
>
> Any security software does.
>
> > 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.
>
> You're leaving out things like ping-of-death, stacks that believe packets
> with a from address of one of their own address, from addresses of
> 127.x.x.x, etc... It hasn't been that problem-free.

The addressing thing wasn't all pervasive, oversized packets were.

> > 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.
>
> Yes, they could.  I think there could be some value in allowing an
> interaction, though.  Example below.  I don't know if it would be easier to
> modify an
> existing IP stack to have the IDS-like features, or whether it
> would be easier to write a new SPF.
>
> > 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.
>
> It uses the IP stack when it itself is the endpoint.  I'm pretty sure it
> doesn't when it's gatewaying, such as when it's NATting, tunnelling,
> or encrypting.  I can check that later.  I'm pretty sure FW-1 only uses
> it's own stack for the key exchange... the actual packet stream is
> handled in an SPF way.  I will verify.

Funny, they were recommending NT users block VPN stuff when the URG 
thign happened.

> > > 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.
>
> A traditional packet filter doesn't.  A full-featured SPF that can
> grab packets without the OS being able to get them darn
> near constitutes another IP stack.

I'd say that depends heavily on criteria.

> > 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.
>
> Which is it?  Is taking the IP stack to userland "a trivial change"
> or a "new piece of complex software?"  It helps greatly with the problem

My IP stack is trivial, your SPF is a new piece of complex software, 
sorry it wasn't clear.

> of intrusion into the gateway via the IP stack (if you assume that
> possibility exists at all.)  You've compromised a user program that
> has control over an inside NIC.  I think that's a better proposition than
> controlling a root equivalent that has control of an inside NIC.

In an OS with a fully implemented securelevel, perhaps, in most OS' not 
really:(

> > You're assuming there's an infinite number of attacks that can be
> > perpatrated on the lower layers.
>
> Not infinite, just a really big finite number :)  Like, to prove there
> isn't a problem (without proving the source code is correct) I'd
> want to see 2 raised to the power of the number of bits possible
> in some maximum number of packets.  A daunting proposition for
> any gateway software.

That assumes that any packet can cause a problem, where the scope of 
risk is really about sizes, fragments, and source and destinations, no?

> > 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.
>
> That's just so far... and mostly in the last two years or so.  I think
> there
> will be more.   I'm also not proposing to throw it all out... I propose to
> take
> the lessons learned, and some parts of the code, and improve
> upon it.
>
> > 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.
>
> It would need to sanity-check the data, just like stacks should/do now.

Again, wouldn't there be much more gain in sanity checking a stack, 
since that would also help the application servers and clients?

> > 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?
>
> Same way the AGs did.. don't pass any extra options unless you tell
> it to.  This is a good example because it shows a case where the
> AG can't know whether to throw an URG bit on the new packet, beacause
> it isn't allowed to know if it got one.

I'm sorry, an application *does* know that the URG flag is set in the 
conversation (how else would telnetd recognise it?), and it normally 
*doesn't* need to pass it because it's specific for the current conversation 
in most instances, and it's an endpoint, in those cases where it does 
need to pass it, it most certainly can do so.  The SPF folks have to 
know if the particular applaction needs to handle the URG pointer, in 
advance as do the AG folks, however the SPF folks don't know by default 
if it's a good or a bad thing, and hence the blockage by most current 
implementations by defaut.  Now lets say there's a similar bug in NT 5.0 
by the PUSH flag... AG wins.

> > > 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.
>
> Are we talking about different things?  Some unices had a very small number
> of buffers to that TCP connections with.. fill those up, and you can't
> start
> any new ones for a couple of minutes.  For example, a 14.4 modem user could

This, of course depends on how you tune your IP stack.  

> send 100 SYN packets to an unpatched host, within about 20 seconds.  That
> host would essentially be unreachable for a couple of minutes.  This is
> way different than needing a bigger pipe, and keeping a constant
> stream up to prevent other traffic from getting there.  What were you
> calling a SYN flood?

The same thing, I'm just able to tune how long I'm in SYN_RECEIVED, 
FIN_WAIT, FIN_WAIT2, 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.
>
> No, it doesn't really eliminate the issue.. If my back-of-the-envelope
> calculation is right... Assuming that SYN packets/frames are 64 bytes,
> or 512 bits..and one of my web servers is willing to give new connections
> 2 minutes to finish handshaking, and I've got a full DS3 at 45Mb/sec,

There's your preidcate, I don't wait two minutes, and I don't know any 
users who'd wait that long for a connect to a site.

> then my web server has to have over a million buffers.  It doesn't.

My buffer space is allocated quite large, it was necessary to handle the 
traffic load alone, not even to worry about attacks.  Your site probably 
isn't on that scale, so I understand that you've not had to go through 
the exercise prior to seeing the SYN flood attack.  We saw it from 
normal usage well before the attack was rampant.

> It's not too much work for an external box to maintain a table with
> a millon connections waiting to finish handshaking.

It's not too much for a Web server either FWIW.

> > 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,
>
> That's pretty trivial.. even FW1 handles SYN floods.

If it detects it as such, otherwise you've got the same resource issue 
in the state table.

> > which they
> > can't alleviate because they're not the ones sending out RSTs with the
> > downstream's address.
>
> I'm not following.. I'm thinking in terms of a gateway protecting web
> servers
> which would otherwise be suseptible to SYN floods... why would the
> gateway send RSTs in a context of finishing handshakes for other hosts?

Sending out RSTs is one way of alieviating SYN floods, and I mispoke, it 
certainly could do that.

 
> > No, I'd want proxies for the other 100 protocols, or a new set of users ;)
>
> Problem is, you won't get good proxies for every protocol.  Some protocols

I will for every protocol I allow.  Because that's part of my criteria 
for allowance.  If you're not as paranoid about tunneling attacks, you 
may be more liberal. 

> can't have any application knowledge because they're encrypted.  Some

If you pass encrypted traffic, you obviously aren't as worried about 
tunnels, therefore you probably won't accept my stance.  

> have to be packet filtered...essentially routed.  So, you may at some point
> have to use a packet filter.  I suppose you can always get a new set of
> users by quitting your job.

I could, I get reasonable offers constantly.  Fortunately, (or not 
depending on your view) so far I've not needed to do that, because my 
policies are well received by those who run the corporation.

> > 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?
>
> A NBT proxy might want to know when someone tried to send it a packet with
> the URG bit on.  It might also be nice, once the connection has been
> dropped,
> to log what the conversation had been up to, until that point.  There's a
> case
> where, with a regular AG, the IP stack has one piece of information, and
> the proxy has another.

Yes, and the http proxy has different info from the ftp proxy, log 
reconciliation isn't too difficult, and can easily be automated, proxies 
aren't IDS' and probably shouldn't be (fox guarding the henhouse.)

> > 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? ;)
>
> Trivially fixed, but it was there to begin with.  It's an example for
> you of something worse than a DoS, built into an IP stack.

It may or may not be worse than a DOS.  From my perspective it isn't, 
since external machines can't get inside unless they're tunneled, and 
I'm watching for tunnels.  

> > I don't see how the IP stack running in user space is SPF, and not just
> > an IP stack.
>
> I define an SPF as a piece of software that isn't part of the OS,
> and passes packets (modified or otherwise) without needing
> services from the OS.  For example, it doesn't have to ask
> the OS for sockets, doesn't have to reserve ports, etc..  Think
> of a piece of software that listens, via a NIC it controls in
> promiscuous mode, for packets, some of which it
> ignores, some of which it passes, some it modifies and
> passes.  Most people would call this some sort of
> packet filter.  It could also be an IP stack that has been
> decoupled from it's OS.  Heck, perhaps you could get a
> good unix stack, and hack it to run on a Netware box.

You don't need state for any of that though, that's where I was missing 
something I guess.

> > I also don't think it buys automatic protection, since (a)
> > intrusion attacks haven't happened via a stack,
>
> I gave an example of some that, while not a direct
> intrusion, gives a trivial next step to a successful attack.

This, of course depends on your policy.  In my current situation, 
anything going outside is for an external resource, and you won't make 
it to the DMZ coming inside, so you won't see leaky packets.  Perhaps 
you engineer your systems differently, but my layers and equipment don't 
mind if the user's AG leaks because it's not the exterior defense by a 
large margin.  

> > 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.
>
> I don't know exacly how it could happen, but I expect we'll find
> out before too long.  I'm thinking along the lines of pushing code
> onto a stack by fiddling with pointers, one byte at a time.

And how does running in user space stop this as an attack method?  If 
you're the user running the protection mechanism, then I don't *need* 
root, I just need your context, no?

> > > I haven't thunked this much since Win32 came out ;)
>
> Is that good or bad?  Or, more specifically, should I
> take offense? :)

Not at all, trust me, you'll know when you need to take offense, I'm not 
all that subtle about such things ;)

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