[3434] in bugtraq
Re: Excellent host SYN-attack fix for BSD hosts
daemon@ATHENA.MIT.EDU (Mark Graff)
Sat Oct 12 04:11:59 1996
Date: Fri, 11 Oct 1996 19:57:47 -0700
Reply-To: Mark Graff <mark.graff@ENG.SUN.COM>
From: Mark Graff <mark.graff@ENG.SUN.COM>
X-To: freedman@netaxs.com
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
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-
