grsecurity forums

Hello!
Help me to understood that...
when this is off echo reply id`s is equal to request ......why???
kernel 2.4.21 is that options for old kernel? or just default

thanks

matador wrote:Hello!
Help me to understood that...
when this is off echo reply id`s is equal to request ......why???
kernel 2.4.21 is that options for old kernel? or just default

thanks

Erm, could you please speak a language?
I don't get what you are trying to ask at all .

thanks

ciao, Marc

lol

speaking myself a bad english, i understood what he wants to say :
He wants help to understand the fact that when the random ping ID feature is disabled, why the icmp echo request ID is equal to icmp echo reply ID.
Is it an option of 2.4.21 kernel for compatibility with older kernels or is it just a network basis.

This is what i understood
My apologizes if i'm wrong.

gkweb.

Another words (about Altered ID pings) - what for is that option?
(in kernel 2.4.20 for example ID of echo-reply is ALREADY equal ID of echo-request - so what does this option do???)

Sorry for my english..

gkweb wrote:
He wants help to understand the fact that when the random ping ID
feature is disabled, why the icmp echo request ID is equal to icmp
echo reply ID.

It is exactly what i mean. I use kernel 2.4.21 and Ethereal . And when altered pings options is off echo request ID is equal to echo reply ID, but why? Is it only in new kernel ? or maybe i must use another sniffer for example tcpdump?
so thanks for all

that can't be the case. The kernel doesn't even fill in the echo id field without grsecurity. Maybe you're confusing the echo ID with the IP ID.

-Brad

No. Network analyzer (Ethereal) shows that ID echo-reply is equal ID echo-request (without GRSecurity) and looks like the number of this ID depends of ID process that sends echo-request. I suppose this is realization of TCP/IP in Linux (may be a long time ago it was different and this option stayed from that time)
P.S. Sorry fo my bad English

Hi all
So doing that:
echo 0 > /proc/sys/kernel/grsecurity/altered_pings

starting ethereal;
capturing eth0 :

ICMP
Type: 8 (Echo Request)
Code: 0
Checksum: 0x381c (correct)
Identifier: 0xb306
Sequence number: 00:00
Data 56 bytes

Type: 0 (Echo Reply)
Code: 0
Checksum: 0x401e (correct)
Identifier: 0xb306
Sequence number: 00:00
Data 56 bytes

So , how can you see, Id`s is equal. Why?
Or maybe i`m wrong,where?
thanks

I was right:
This is a part of icmp.c - as is (kernel source):

/*
* Handle ICMP_ECHO ("ping") requests.
*
* RFC 1122: 3.2.2.6 MUST have an echo server that answers ICMP echo requests.
* RFC 1122: 3.2.2.6 Data received in the ICMP_ECHO request MUST be included in the reply.
* RFC 1812: 4.3.3.6 SHOULD have a config option for silently ignoring echo requests, MUST have default=NOT.
* See also WRT handling of options once they are done and working.
*/

static void icmp_echo(struct sk_buff *skb)
{
if (!sysctl_icmp_echo_ignore_all) {
struct icmp_bxm icmp_param;

icmp_param.data.icmph=*skb->h.icmph;
icmp_param.data.icmph.type=ICMP_ECHOREPLY;

if(grsec_enable_randping)
icmp_param.data.icmph.un.echo.id = skb->h.icmph->un.echo.id;

icmp_param.skb=skb;
icmp_param.offset=0;
icmp_param.data_len=skb->len;
icmp_param.head_len=sizeof(struct icmphdr);
icmp_reply(&icmp_param, skb);
}
}

Line with grsec_enable_randping:
icmp_param.data.icmph.un.echo.id = skb->h.icmph->un.echo.id;
do that what one line before was done:
icmp_param.data.icmph=*skb->h.icmph;
See also RFC 1122: 3.2.2.6 Data received in the ICMP_ECHO request MUST be included in the reply.
So what for that option (looks like it was not written by a professional)

Sorry for bad English.

Indeed, the current Linux code does set it correctly. I quickly checked the latest 2.2 and 2.0, and they both do the same. The feature was written around 2 years ago. Maybe at that time linux 2.4 wasn't doing it correctly, I don't have any source on me at the moment to check.

-Brad