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 PHC | |
Open Source and information security mailing list archives
| ||
|
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 :/
Powered by blists - more mailing lists