netdev - [iputils] - patch for ping to set un.echo.id to network byte order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 1 Sep 2009 01:05:37 -0400
From:	Jamie Le Tual <jamie.letual@...il.com>
To:	nedev <netdev@...r.kernel.org>
Subject: [iputils] - patch for ping to set un.echo.id to network byte order

I noticed in the ping source code that the identity flag on the icmp
echo packet is set to the pid of the ping command being run. I
immediatly fired up a packet sniffer to see it, but got endian
wierdness. Looking back at the code, and comparing with ping6 and
traceroute6, I noticed that when the identity is set, its fed the
value of getpid() without running it through htons(), as is done in
traceroute6.

So this patch for the ipv4 version of ping:

diff -pu iputils-s20071127/ping_common.c iputils-jamie/ping_common.c
--- iputils-s20071127/ping_common.c	2007-11-26 19:57:27.000000000 -0500
+++ iputils-jamie/ping_common.c	2009-09-01 00:10:58.000000000 -0400
@@ -473,7 +473,7 @@ void setup(int icmp_sock)
 			*p++ = i;
 	}

-	ident = getpid() & 0xFFFF;
+	ident = htons(getpid() & 0xFFFF);

 	set_signal(SIGINT, sigexit);
 	set_signal(SIGALRM, sigexit);

seems obvious enough. I figured that htons was safe enough, since
pid_t is just an int.

Is there some reason to not send the identifier properly so it doesn't
end up bass-ackwards on the receiving end?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html