Subject: RE: keep RST data nonstandardized for the future!

From: Ignacio Goyret <[email-masked]>
Date: Tue, 01 Aug 2000 19:01:55 -0700

At 06:54 PM 8/1/00 -0400, Bernie Volz wrote:
>Some that I could think of are:
>- No listener (for a SYN segment)
>- Unknown connection
>- Receiver discard connection (data received on a connection with no higher
>level receiver available)
>- Application abort (application requested RST on connection instead of
>closing it)

I'm sure that your reasons are well-meant and quite honest, but I have to
wonder out loud if these codes won't be of great help to a hacker.
For example, if I just get an RST and no code, it is harder for me to guess
the reason than if I get an RST with "application abort". In the latter case,
it might be easier to mount a DoS based on the knowledge obtained through
those messages. For example, in the previous example, I can guess that an
application was run and that it probably consumed some resources, so if
I can trigger this type of RST, I might be able to consume all the resources
on that server and either make it crash or make it run very slowly.

Exactly what problem are you trying to solve by adding these codes?

I also hope that all those vendors mentioned have knobs to enable these codes
only when desired (they should default to disabled).

---

From: Rick Jones <[email-masked]>
Date: Tue, 01 Aug 2000 20:51:44 -0700

> wonder out loud if these codes won't be of great help to a hacker.

Well heck, the very existence of the Internet is the greatest help a
cracker has ever received. :)

> on that server and either make it crash or make it run very slowly.

I would think that in this example, you can already guess that an
application was run and/or resources were consumed when your connection
was accepted in the first place.

Perhaps there are other texts from other situations that _might_ yield
script-kiddie-useful info beyond the sending of the RST itself, but I
cannot think of one myself at the moment.

> only when desired (they should default to disabled).

ndd -set /dev/tcp tcp_text_in_resets 0 for HP-UX 11. The default
however, is 1.

rick jones
-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Aug 2000 14:11:11 -0700

> wonder out loud if these codes won't be of great help to a hacker.

Only if they're trying to hack your statistics or debugging.
I don't think (pls correct me if this is not the case) that
anyone is proposing different receiver actions based on these
codes; it's just for diagnoses, right?

> only when desired (they should default to disabled).

That seems like it would make diagnoses harder; if they're just
informational, they could default to 'on'.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Aug 2000 15:59:51 -0700

Ignacio Goyret wrote:
> 
> At 02:11 PM 8/17/00 -0700, Joe Touch wrote:
> >
> >Ignacio Goyret wrote:
> >>
> Any information shot back to the sender of a SYN is potential information
> for a hacker. 

Yes! A SYN/ACK is info, the window size is info, etc.

If you're that worried about hackers, use IPSEC.

How does this _add_ compromises, is the question...

Joe

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 17 Aug 2000 15:24:42 -0700

Any information shot back to the sender of a SYN is potential information
for a hacker. For example, if the code says something like "too busy" (or
something that might indicate that), then Joe Hacker knows that your server
is on the brink: just keep pumping SYNs until it keels over. If it says
something like "bad security" or "bad precedence", well, you are just asking
for it. :-)

On typical servers, a new incoming connection usually implies that a daemon
will be spawn or something like that, in other words, resources will be consumed.
If that malicious person can get a view into how you are denying his SYN attack,
he might be able to tune the attack and kill your server/router/etc.

All I say is "let's be careful". The less information you provide back to the
potentially malicious instigator, the lesser the chances that it will know how
to affect you worst.

In fact, I would almost argue that an RST in response to a SYN or SYN/ACK should
not contain any information whatsoever (unless a kernel flag was turned on) to
minimize this potential. I have no problem with info on RSTs which are sent
elsewhere in the cycle, ie, from established onwards.

>informational, they could default to 'on'.

What I'm saying is that you only want to turn them on when you are actively
debugging something. Until then, leave them off. There is no need to provide
extra tools to the intruders out there.

-Ignacio
"Just because I'm paranoid it doesn't mean they are not after me" :-)

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 17 Aug 2000 16:40:24 -0700 (PDT)

> will be spawn or something like that, in other words, resources will be
> consumed. If that malicious person can get a view into how you are denying
> his SYN attack, he might be able to tune the attack and kill your
> server/router/etc.

I think you need to be more specific on why the extra info can be used by
an attacker to do more harm than without the info.  In the example above, 
does an attacker need to know whether a server is busy or not before an
attack can be launched?  Well, if it is not busy, make it busy by the attack!
This is a DoF attack afterall.  If it is busy, will the attacker not launch
a DoF attack?

> potentially malicious instigator, the lesser the chances that it will know
> how to affect you worst.

I will say that it really depends on what info it is.  For example, there
may be a security problem if the RST is sent because of a duplicate SYN with
wrong sequence number.  But let's postpone this discussion of potential
security problem after the list of RST code is finalized.  Then we can talk
about specific issues, not wasting time on some "generic info..."  IMHO, I
don't believe that any extra info provided in a RST in reponse to a SYN or
SYN/ACK is automatically a security hole.  We'll discuss that later, for
sure (-:

							K. Poon.
							[email-masked]

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 17 Aug 2000 16:39:36 -0700

>How does this _add_ compromises, is the question...

The info you listed is non-critical.

What I meant were the specific codes that have been suggested, such as
"application abort", "bad precedence", "bad security", "low memory", etc.
This type of information is quite interesting for someone trying to do
damage. All he would need to do is repeat the same SYN ad nauseum, and
if he keeps getting "application abort", he is well on his way to crash
your server. Is this compromise enough?

Responding with "bad precedence" or "bad security" is synonymous with inviting
him to try a few other values. This _adds_ compromise.

A simple empty RST doesn't give him any of this information so he doesn't know
if you are just not listening on that port or that you rejected his attempt.
He can't use the information of why you rejected a particular connection attempt
against you because he doesn't know it. Adding a code to the RST provides this
attacker with the information he needs to fine-tune his attack to bring your
server down.

>If you're that worried about hackers, use IPSEC.

Regarding IPSEC, remember that there are many reasons to use TCP _without_ IPSEC,
a web server is a good example. We (or at least I) want to be able to build boxes
that are sturdy enough and can withstand some attacks. A code in an RST sent in
response to a SYN or SYN/ACK as suggested just adds vulnerabilities.

Again, sending RST information elsewhere in the state machine doesn't bother me
as much.

I _do_ see the debugging value in the idea, but I worry that it opens Pandora's box.

Cheers,
-Ignacio

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Aug 2000 17:24:02 -0700

> something like "bad security" or "bad precedence", well, you are just asking

Agreed. "too busy" is a foolish place to send a RST, however. 

The message needs to have meaning in the TCP-sense; bad precedence means
something, but bad security doesn't (that message would come in other
layers, or not at all. why would you tell someone about that?).

> potentially malicious instigator, the lesser the chances that it will know how

The primary purpose I saw was to send "where in the TCP stack the RST
came from". I wouldn't suggest 'different application reasons'; it seems
to me TCP's job is over once you tell be why _TCP_ did something.

> elsewhere in the cycle, ie, from established onwards.

It could say "SYN rejected", or "SYN/ACK rejected". There are different
reasons for the SYN/ACK rejection, including precedence. But that
doesn't seem like information that's particularly useful. Either _you_
changed the precedence (in which case this is helpful) or a hacker did
(in which case they can change the RST anyway).

This is the reason I caution about _USE_ of the information, e.g., used
for diagnostics only.

> extra tools to the intruders out there.

If it's turned off by default, it may be impossible to debug. I don't
always have control over both ends.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Aug 2000 17:30:47 -0700

> your server. Is this compromise enough?

Any response means he is succeeding.

> him to try a few other values. This _adds_ compromise.

Bad precedence just means subsequent packets didn't match the precedence
bits. We already know that they can be changed, and sending two packets
with different values is sufficient to guarantee a crashed connection in
that case. This isn't particularly interesting.

Bad security makes no sense; TCP has no security (SSL does, so does
IPSEC, but then _THEY_ should carry that info, or not. not TCP :-) It'd
be inappropriate to send a RST in response to failed SYN authentication
(to counter DOS attacks); silence is the best response there anyway.

> if you are just not listening on that port or that you rejected his attempt.

No. He knows you're listening, and that you've responded. Otherwise,
you'd have to have been spamming the world with RSTs.

> attacker with the information he needs to fine-tune his attack to bring your

There is no new information here that is useful. So he tries again. He
can do that now. The RST has to have information that CHANGES how he
attacks you; there isn't enough info (at least in my view of what's
included) to do that.
 
> a web server is a good example.

Web servers can use IPSEC for authentication. A web server wouldn't get
too many RSTs in response to SYNs, because they typically answer (not
initiate) connections. Sure, it could get RSTs in response to SYN/ACKs,
but it can do that now.

Joe

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 17 Aug 2000 17:55:04 -0700

>Any response means he is succeeding.

Not necessarily. Simple responses that don't tell him the failure reason
prevents him to tailor his attack.

>(to counter DOS attacks); silence is the best response there anyway.

I'm not disagreeing with you. Both of these are examples of bad codes. They are
just two examples of the codes that have been suggested on this list by some
people. I'm guessing (since I don't know the reason why they were initially
suggested) that they were probably inspired by the text in page 67 of rfc793.

>you'd have to have been spamming the world with RSTs.

RFC 793, page 36, 'Reset Generation', item #1 seems to say otherwise.

BTW, I use the term "listening" meaning that there is a TCB in the LISTEN state
for that port. Is that you what you meant?

And why would I (or anybody else for that matter) be spamming the world with RSTs?
If I telnet to a port that nobody is listening on, or if inetd fails to spawn the
proper daemon, I'll get an RST.

>attacks you; there isn't enough info (at least in my view of what's

It all depends on the kind of information that is included and that's where the
issue hinges.

It has been suggested to add codes indicating "application failure" or "bad
security/precedence". These are clearly bad (at least to me) because they
can tell him how to make his attack more efficient.

When the list of codes is finally compiled, it should be carefully scrutinized
to make sure that this attacker is not given golden information.

>initiate) connections. Sure, it could get RSTs in response to SYN/ACKs,

Huh? Web servers wouldn't be receiving RSTs: they would be _sending_ RSTs
with potentially juicy information. The attacker would be receiving the RSTs,
not sending them. That's what makes it easier for him to attack the server.

The other way around is not interesting at all.