Re: Excellent host SYN-attack fix for BSD hosts

[mark.graff () ENG SUN COM (Mark Graff)]

        Avi Freedman said,

> I've been running Jeff Weisberg's SunOS patches for a day now without
> trouble on my news and web boxes.  He's come up with an implementation
> of the not-going-into-the-SYN_SENT-or-SYN_RCVD state hack.  It appears
> to be working fine.

        Always good news.

>  Hopefully Sun will incorporate this into their security announcement, which
>  basically says you're screwed if you run SunOS, though it does describe
>  how to increase the queue and decrease the SYN-holding timeout (if you
>  have source...

        Incorporating it or endorsing it would be problematical for a couple
        of reasons. Let me state them, then if anybody wants to give me
        public or private feedback I'd be delighted.

        First, the announcement is already out. I do keep tinkering with
        it, and am not arguing that it's "finished"; but I put the nickel
        in the Bulletin machine and it's gonna rocket around to something
        like half a million people (several hundred thousand for sure)
        in the form it was posted it here day before last. Of course I get
        reprint requests and what not, but updates would get little attention.

        Of course if we wanted to now, or had wanted to then, we could
        make (could have made) a statement recommending Jeff's material.
        Why didn't we do that? It would have required considerable extra
        testing, under ferocious internal and external time pressure; but
        that wasn't the reason. It could have been embarassing, telling
        out SunOS 4.1.x customers that we had no solution but Jeff Weisberg
        did; but that wasn't the reason either--any truly good solution is
        better than none, or almost none. Rather, it comes down to the
        damned dull dreary issue of support.

        Now let's assume that this fix is exactly what Avi (and Jeff) believe,
        a sound and elegant approach that represents a significant advance.
        Why not put my (our) weight behind it? (If you know me: no jokes.)

        I am often asked why Sun does not ship excellent free software with
        our systems such as tcp_wrapppers (my favorite example) or tripwire.
        For this lacuna, we have to thank those many, many customers who
        routinely assume--no matter what the documentation says, or the
        packaging, or the installation files or the README--that if Sun
        ships it, Sun supports it, and Sun will fix it. At the first sign
        of trouble, they call in, in droves. It's happened so many times
        (and we've tried it many times, though not as I recall with security)
        that it's a dead issue, for now at least, as far as I am concerned.

        Now imagine the situation if we recommended that customers go to
        a Web site and pick up kernel binaries. I know, I know, Jeff is
        surely a great guy, and the stuff really works great and he even
        will probably jump to fix any problems that crop up; and there
        is nothing to worry about WRT to someone breaking in to his
        system and tampering with binaries (sure it happened just that
        way to the University of North Carolina's SunSite a couple of
        years ago, but it probably wouldn't happen again); and if folks
        called in with system problems and the Sun support people heard
        that the customer was running Jeff's kernel, well, we could
        just take the bug report anyway, and try to help them, right?
        There are answers to all of these concerns. Sincerely now. But
        consider.

        What happens when Sun issues, as we do dozens of times a year,
        security-related patches for all supported releases? Do we test
        it not only on our own 13 or so, but on Jeff's too? And what about
        (as God forfend) we have to patch the kernel, which we do several
        times a year? Do we give Jeff the diffs and have him fold them in?
        Which do we tell our customers, who are under attack (say) and
        screaming for a fix: "You're screwed," (to quote Avi), or "Ask
        your vendor?" (That would be Jeff). You see the point? Folks
        would have to choose between backing out Jeff's kernel, and being
        vulnerable to SYN attacks again, or living with the Next Big
        Problem. And we would be stuck squarely in the middle.

        See, Jeff's kernel is what we call a "point patch", a fix to a
        program frozen in time. They're always a headache. The way out of
        the dilemma is to re-unite the divergent streams, when the point
        fix gets into the main source pool. But in this case, that ain't
        gonna happen.

        And there we are again, back to the nub of the problem. We are
        just not going to dive in again and start making design changes,
        after four or five years, to SunOS 4.1.x.  We're committed to
        Solaris 2.x; engineering support for 4.1.x is at the minimum
        level needed to meet our contractural obligations; and we don't
        consider that this is a bug and that we should divert resources
        from 2.x to make design-level improvements this late in the game.

        Sorry to go on so long. I guess the good news is that you're
        getting the answer straight from the horse's mouth, with the
        bark off and (pretty much) to the point. If anybody can change
        my mind, I can probably get Avi's suggestion put into practice.
        Now at least you know we considered this kind of action carefully,
        and know the most important reasons we rejected it.

        I know that this space is not really the place for discussion,
        but I figured if one person could post my work here and the
        other could make a (thoughtful) suggestion about it, it wouldn't
        be out of place for me to respond. I do suggest we take this
        discussion off line now, though. (And I would appreciate it if
        this note didn't appear in places I don't choose to put it, as
        only a few of my other explanations have. Thanks.)

        -mg-