Re: Variations of firewall ruleset bypass via FTP

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

On Sat, 12 Oct 2002, Darren Reed wrote:

I'm going to stop after this one, I've had my say[0], and I think this 
summarizes my remaing issues, if a bit verbosely...

> > I think what Mikael's concern was (and he'll pipe up if I'm wrong, I'm 
> > sure) is that folks looking at the vuln. note will see "IPFilter- Not 
> > vulnerable." and stop there, rather than looking for a Net- or Free- 
> > entry.  "Check the specific OS line, or your version number, or upgrade." 
> > Might be more helpful too.
>
> Well what other conclusion do you arrive at when you've spent several
> days testing and failed to make the problem happen ?

I was hoping the follow-up discussion here made clear what apparently 
didn't carry through CERT- While Mikael was nice enough to code up "proof 
of concept" code for ICSA to use in product testing, this isn't a "there's 
an attack raging out there" issue (because it was handled *this* way 
instead of the "produce attack code and announce the problem method.)

> That said, my feedback mentioned quite specifically that ipfilter was
> not vulnerable to *that* exploit, ie the one we received from CERT,
> written by Mikael, and that it may be vulnerable to others (I have
> not seen all the others so I can't be sure, either way.)

That's what I was afraid of.  I think this is why we're all shouting in 
different directions.  I can't speak for the OBSD folks, Mikael, or the 
Labs, so I'll do it for me-  I'm worried that folks who provide dynamic 
filtering firewalls understand the attack class issue (I wasn't trying to 
make Daniel look dense when I reiterated the lack of SACK issue, I was trying 
to get past the CERT language to be sure we were talking about exactly the 
same class of attack- the fact that he articulated it well means we were.) 
and that they make sure they've covered the partial ACK case explicitly- 
that doesn't mean we expect Mikael to code up attacks for products- he's 
been *very* helpful in providing code that can be used as a basis for 
testing, but frankly all these folks (indeed also IPF) are his 
*competitors* in the market, he's not to be expected to QA for 
them[1].

What I'm saying, and I think it's reflected in some of the other 
statements is that we don't expect you to necessarily be vulnerable to the 
POC code, as it wasn't specifically coded to exploit any particular 
product, but to generate packets to show the concept, and if it broke some 
products, then it's been *really* useful for those folks, but hopefully 
they've all looked beyond the specific code to the class of problem.

In my mind, saying "Not vulnerable" and just relating that to the POC code 
is bad because it makes people think they're safe when they may not be, so 
if this is indeed the case, I think we'd all appreciate a more verbose 
clarification.

> Unfortunately the people behind security-officer for NetBSD have been 
> next to useless in this case and if you asked me, their largesse in
> this case would be a good excuse to give them all the ass (it's not
> a fun job, either.)  FreeBSD has not been much better.

Frankly, that's *why* we're looking to you.  You're the #1 IPF authority- 
no matter what version *they* ship.   If you need someone to generate 
pages of rants pointed at them, I'm obviously qualified ;)

> What compounds my annoyance about all this is the lack of information
> available to me, at the time.  To me the notes looked like someone had
> specifically developed an ftp daemon to tickle the problem and if that
> is what it took, I was just simply not interested.

There's a client issue, as well as a server one, that makes a potential 
(but unlikely) malcode vector.  

The reason I wanted this discussion on -Wiz is because I wanted to be sure 
that (a) the on and off-list stuff could happen with Mikael and others in 
the development community, and (b) to ensure that the *correct* 
information got out.  I harp quite often on companies that fix a 
particular instantiation of a problem, then have a related issue 30 days 
later when someone tries a slight variation.  I was, and still do *really* 
hope that the firewall development community doesn't fall into that trap 
on any particular issue in general, and this one in particular.

I know you're frustrated with the info you got from CERT, and I'm trying 
to see what I can do about that (if anything- but I'm trying to do 
something.)

Now however, I think you should have pretty-much all the information, so 
perhaps the frustration is in the fact that I dunno if you're saying:

"I understand the class of attack, and I know IPF isn't vulnerable, 
because I've looked at what I'm doing and compared it to the partial ACK 
issue."

"I understand the class of attack, and I know that I've fixed this in the 
current version of IPF, older versions are probably vulnerable, but I'm 
not saying that explicitly."

"I ran the proof-of-concept code and it didn't work, so I'm going to say 
IPF isn't vulnerable until someone proves otherwise."

"I'm not going to fix theoretical attacks until there's an actual 
exploit.[2]"

I'm sure you know what exactly you're saying, I think we're all missing 
it, quite possibly because of our pre-concieved notions of what sort of 
response we each expect to see.  I think I've seen parts of each of these 
in this thread, but the thread has been disjointed and my preconcieved 
notions of how I'd prefer folks to react hasn't changed, so it may be the 
combination of that- I certainly don't expect you to have to react to my 
idea of how people should react.  I know from the thread that you 
understand the attack, but I still really don't understand your position, 
and that's frustrating to me.

Perhaps some of it is due to us drifting between the times of the CERT 
notification and the present, but I think it'd help immensely if you could 
clarify the current situation with IPF.  I still haven't stepped through 
the code, but I don't see anything that obviously stops this type of 
attack (I see lots of string stuff that obviously makes it difficult)- but 
I'm not the world's best code auditor either, so I guess I'm looking for a 
way to raise my level of assurance that IPF doesn't have this problem, or 
that it might but until there's an attack you're witholding making changes 
(both of those are reasonable positions to me.)

A final last-minute thought- if we're relying solely on the lack of 
presence of a CR, then we've got a potential "Intruder on the DMZ outside 
the firewall injecting bytes into traffic" vector here.  That includes 
possibly the DMZ at the *other* end...

We now return you to your regularly scheduled variant of "Which firewall?"

Thanks,

Paul
[0] I'm not killing the thread, I am going to step back personally.
[1] Yes, we've been kind of heaping praise all over poor Mikael, but this 
is a part of it- The Right Thing regardless of vendor boundaries is very 
refreshing.
[2] I'm willing to admit the risk assessment and the vulnerability 
assessment are completely different.  I think it's fair to talk about the 
risk in the response to the vulnerability note, I just think that I'm not 
sure the phrase "not vulnerable" is appropriate if indeed the class of 
attack and therefore vulnerability described are either not quantified, or 
potentially present.  Sometimes, we tend to get hung up in the exactness 
of our language when we really need to understand how it's understood 
rather than how we said it.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards