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)

Ryan Russell (ryanrsybase.com)
Fri, 3 Jul 1998 18:13:10 -0700

>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.

>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.

>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?

>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.

>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.

>> 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.

>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
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.

>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.

>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.

>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.

>> 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
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?

>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,
then my web server has to have over a million buffers. It doesn't.
It's not too much work for an external box to maintain a table with
a millon connections waiting to finish handshaking.

>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.

>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?

>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
can't have any application knowledge because they're encrypted. Some
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.

>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.

>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.

>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.

>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.

>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.

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

Is that good or bad? Or, more specifically, should I
take offense? :)

                    Ryan

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