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 probertsat_private which may have no basis whatsoever in fact." probertsonat_private Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Sat Oct 12 2002 - 07:37:00 PDT