netdev - Re: [PATCH net-next] tcp: allow traceroute -Mtcp for unpriv users

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d0280b5f-dbf2-a7db-9137-2f795aa81819@gmail.com>
Date:   Mon, 25 May 2020 19:42:45 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Miller <davem@...emloft.net>, edumazet@...gle.com
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com, maze@...gle.com,
        willemb@...gle.com
Subject: Re: [PATCH net-next] tcp: allow traceroute -Mtcp for unpriv users



On 5/25/20 5:54 PM, David Miller wrote:
> From: Eric Dumazet <edumazet@...gle.com>
> Date: Sun, 24 May 2020 11:00:02 -0700
> 
>> Unpriv users can use traceroute over plain UDP sockets, but not TCP ones.
>>
>> $ traceroute -Mtcp 8.8.8.8
>> You do not have enough privileges to use this traceroute method.
>>
>> $ traceroute -n -Mudp 8.8.8.8
>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>>  1  192.168.86.1  3.631 ms  3.512 ms  3.405 ms
>>  2  10.1.10.1  4.183 ms  4.125 ms  4.072 ms
>>  3  96.120.88.125  20.621 ms  19.462 ms  20.553 ms
>>  4  96.110.177.65  24.271 ms  25.351 ms  25.250 ms
>>  5  69.139.199.197  44.492 ms  43.075 ms  44.346 ms
>>  6  68.86.143.93  27.969 ms  25.184 ms  25.092 ms
>>  7  96.112.146.18  25.323 ms 96.112.146.22  25.583 ms 96.112.146.26  24.502 ms
>>  8  72.14.239.204  24.405 ms 74.125.37.224  16.326 ms  17.194 ms
>>  9  209.85.251.9  18.154 ms 209.85.247.55  14.449 ms 209.85.251.9  26.296 ms^C
>>
>> We can easily support traceroute over TCP, by queueing an error message
>> into socket error queue.
>>
>> Note that applications need to set IP_RECVERR/IPV6_RECVERR option to
>> enable this feature, and that the error message is only queued
>> while in SYN_SNT state.
>>
>> socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
>> setsockopt(3, SOL_IPV6, IPV6_RECVERR, [1], 4) = 0
>> setsockopt(3, SOL_SOCKET, SO_TIMESTAMP_OLD, [1], 4) = 0
>> setsockopt(3, SOL_IPV6, IPV6_UNICAST_HOPS, [5], 4) = 0
>> connect(3, {sa_family=AF_INET6, sin6_port=htons(8787), sin6_flowinfo=htonl(0),
>>         inet_pton(AF_INET6, "2002:a05:6608:297::", &sin6_addr), sin6_scope_id=0}, 28) = -1 EHOSTUNREACH (No route to host)
>> recvmsg(3, {msg_name={sa_family=AF_INET6, sin6_port=htons(8787), sin6_flowinfo=htonl(0),
>>         inet_pton(AF_INET6, "2002:a05:6608:297::", &sin6_addr), sin6_scope_id=0},
>>         msg_namelen=1024->28, msg_iov=[{iov_base="`\r\337\320\0004\6\1&\7\370\260\200\231\16\27\0\0\0\0\0\0\0\0 \2\n\5f\10\2\227"..., iov_len=1024}],
>>         msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1590340680, tv_usec=272424}},
>>                                    {cmsg_len=60, cmsg_level=SOL_IPV6, cmsg_type=IPV6_RECVERR}],
>>         msg_controllen=96, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 144
>>
>> Suggested-by: Maciej Żenczykowski <maze@...gle.com
>> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> 
> Applied, thanks Eric.
> 

I will send a fix, it appears tcp_v4_err() has two sk_buff variables,
one named icmp_skb, and another one :/