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 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 - 11:52:15 PDT