Re: Variations of firewall ruleset bypass via FTP

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

On Sun, 13 Oct 2002, Darren Reed wrote:

> I know you want this to die, but I've posed some more questions for you
> to think about :)

No, I'm not trying to force it to die, I did want to make my concerns 
clear and to make sure that those with similar concerns had the chance to 
berate me for mispeaking if my characterizations didn't cover theirs as 
well. I also think dragging it out makes it look like I'm trying to beat 
up on you, and I'm not. 

> In some email I received from Paul D. Robertson, sie wrote:
> [...]
> > 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.
>
> So what do you do ?
> The last N versions since 1 Jan 2000 ?
> Just test your current/latest version ?
> Poll your userbase and check every version that's in use everywhere ?
>
> As it happens, IPFilter was fixed before I got any information about
> this at all from CERT.  But that is of no help to anyone not running
> the latest version.  Then again, you need to be running a certain
> make & model of ftpd before it's a problem as well.

If I'm reading this right, I think you're saying this was fixed in the 
current version, and likely not fixed before, in which case I'd have found 
"IPFilter version $current is not vulnerable, previous versions likely 
are, so please ensure you're running at least $current."  to be the 
minimum bar.
  
If you suspect earlier versions to be vulnerable, and they're rolled with 
particular projects (such as Net- and Free-) I think it's nice if you can 
go the extra mile and address at least the -current and -stable versions, 
or (probably better) get the Net- and Free- folks to address those, or if 
you *know* you fixed something in $current then mark those as likely 
vulnerable and let those teams deal with the fallout.  

I'm assuming here that you know what fixed this for the current version 
and therefore can at least somewhat authoritatively say when that fix was 
put in place.  

> > > 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 ;)
>
> Like I keep trying to say, if I don't get the right information then
> there's not much I can do or say to provide the right help to people.

Indeed.  No argument there from me.

> For whatever it's worth, I depend on them to provide me with information
> that gets passed to them from CERT.  What I guess I'm saying here is
> that because I had no direct contact with anyone useful in this, looking
> to me, now, is pointless.  I kind of get the impression that IPfilter

I'm sorry, I don't see why it's still pointless- we've still got a class 
of attack, we've still got an IPFilter developer, we've still got 
folks running older versions of IPFilter, what event horizon are 
we past where things are beyond doing something that does some good here, 
or at least clears up the status for folks who are running this in 
production?

> may have been the only popular product that did have an issue and yet
> you'd be forgiven for thinking it was a complete afterthought the way
> some people acted.  If there had of been some sort of direct communication
> between me and CERT/ICSA/Mikael before this week then maybe things would
> have worked out better.  CERT at least appears to have learnt a thing or
> two from this.

If CERT's learned something from this, then we're all better off for it, I 
know I've learned from it, and I hope others have too.

> [...]
> > "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."
>
> All of these.

Ok- then here's where you're going to get incomming fire, and where my 
unsolicited advice is to try to spread some foam to stop the flames:

"older versions are probably vulnerable, but I'm not saying that 
explicitly."

"I'm going to say IPF isn't vulnerable until someone proves otherwise."

So, you can sort of leave all of us wondering if the new version of IPF is 
truly not vulnerable based on your understanding of the attack, or if 
you're really saying it's "not proven vulnerable," or you can make an 
explicit statement.  In either case, I'd really think it prudent to make 
an explicit statement about older versions if the code behaviour affecting 
this has changed.

> It was hard enough to even compile the damn PoC code.  Plus:
>
> "It looked like the proof-of-concept code required a special agent on the
>  inside and if that's the case then I cannot protect against that."

But that's part of it being PoC code- to set up a test condition rather 
than to exploit a particular set of products.  That's distinct from what 
most of the current crowd hand out, which is really proof of exploit code.  

In this case, you're getting the test case code from a vendor who's 
testing their product agaist a class of exploit- not a kiddie who's trying 
to compromise fielded systems and disclaim responsibility for the code 
later.

> All in all, I think I'd rather try and make some sort of celestial
> alignment try and happen than have to go through all that again.
> > From start to end, it's been one big f*cked experience.
>
> Darren

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