Bug nella gestione del record route in ping.c

Nulla di particolare, semplicemente ho notato una strana implementazione dell'opzione di record route nei nuovi ping.c
(per intenderci ho provato quello della slack8)

Non so per quale motivo l'autore passa come parametro alla pr_addr() l'indirizzo registrato nel pacchetto icmp ricevuto,
parsandolo prima attraverso una htonl()...
Visto che questa operazione viene ripetuta ad ogni invocazione della pr_addr(), c'e` 1 motivo per cui viene fatta?
Nelle versioni precedenti (ad esmpio nel ping.c delle iputils-ss001110), pur essendo differente il codice l'indirizzo viene
passato in modo diretto.

Il problema consiste nel fatto che la pr_addr() riceve un indirizzo che e` *reversato* rispetto a quello che e` stato
registrato dall'opzione del record route, quindi anche il reverse dell'ip viene falsato...

La versione su cui sono stati fatti i test, reperibile su ftp.slackware.com, e`:

--- ping.c version ---

char copyright[] =
  "@(#) Copyright (c) 1989 The Regents of the University of California.\n"
  "All rights reserved.\n";
/*
 * From: @(#)ping.c     5.9 (Berkeley) 5/12/91
 */
char rcsid[] = "$Id: ping.c,v 1.39 2000/07/23 04:16:21 dholland Exp $";
#include "../version.h"

---

Ecco 1 esempio:

--- Versione buggata ---

[recidjvo@madmax:~]$ ping-bugged -c1 -R 192.168.0.64
PING 192.168.0.64 (192.168.0.64): 56 octets data
64 octets from 192.168.0.64: icmp_seq=0 ttl=255 time=0.3 ms
RR:     112.1.168.192
        w192.z064000168.aus-tx.dsl.cnc.net (64.0.168.192)
        w192.z064000168.aus-tx.dsl.cnc.net (64.0.168.192)
        112.1.168.192

--- 192.168.0.64 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms

---

Come vedete chiaramente il risultato non e` corretto, e si puo` intuire come sia il percorso leggendo gli ip al contrario
byte a byte

--- Versione corretta ---

[recidjvo@madmax:~]$ ./ping -c1 -R 192.168.0.64
PING 192.168.0.64 (192.168.0.64): 56 octets data
64 octets from 192.168.0.64: icmp_seq=0 ttl=255 time=0.3 ms
RR:     bimbamia.pkcrew.org (192.168.1.112)
        gw.pkcrew.org (192.168.0.64)
        gw.pkcrew.org (192.168.0.64)
        bimbamia.pkcrew.org (192.168.1.112)

--- 192.168.0.64 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms

---

Per sistemare il problema la cosa piu` facile da fare e` modificare la pr_addr(), ad esempio cosi`:
pr_addr(u_int32_t l)
{
        struct hostent *hp;
        static char buf[256];
        struct in_addr addr;

	/* Added code */
        l=htonl(l);
	/* --- */

        if (l==0) {
                return "0.0.0.0";
        }

Oppure modificare le chiamate alla pr_addr() eliminando la ntohl().

Nel pomeriggio cerchero` i contattare l'autore per chiedere chiarmenti, cosi` mi becco 1 valanga di insulti pure da lui, eheh.

Se qcuno si sta chiedendo se non ho di meglio da fare, la risposta gli verra` fornita personalmente :D
Ora scappo che devo andare a scuola che non posso saltare il secondo giorno =)

bye bye
t.R.
--
tHE rECIdjVO <recidjvo@pkcrew.org>
Member of the Packet Knights
http://www.pkcrew.org/
Public Key at http://www.pkcrew.org/keys/recidjvo.asc

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List