netdev - Re: [PATCH net-next v2 2/6] net: Add STT tunneling protocol.

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>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 30 Jan 2015 17:31:56 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Pravin Shelar <pshelar@...ira.com>
Cc:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Jesse Gross <jesse@...ira.com>
Subject: Re: [PATCH net-next v2 2/6] net: Add STT tunneling protocol.

On Thu, Jan 29, 2015 at 9:02 PM, Pravin Shelar <pshelar@...ira.com> wrote:
> On Thu, Jan 29, 2015 at 8:10 PM, Tom Herbert <therbert@...gle.com> wrote:
>> On Thu, Jan 29, 2015 at 3:29 PM, Pravin B Shelar <pshelar@...ira.com> wrote:
>>> This adds a device level support for Stateless TCP Tunnel (STT)
>>> protocol encapsulation. NF-hook is used for receiving STT
>>> packets from networking stack.
>>> Open vSwitch can be used for configuring, set up and tear down
>>> STT tunnels.
>>>
>>> The protocol is documented at
>>> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
>>>
>>> Signed-off-by: Pravin B Shelar <pshelar@...ira.com>
>>> Signed-off-by: Jesse Gross <jesse@...ira.com>
>>> ---
>>>  include/net/stt.h |   59 +++
>>>  net/ipv4/Kconfig  |   11 +
>>>  net/ipv4/Makefile |    1 +
>>>  net/ipv4/stt.c    | 1398 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  4 files changed, 1469 insertions(+)
>>>  create mode 100644 include/net/stt.h
>>>  create mode 100644 net/ipv4/stt.c
>>>
>
> ....
>>> +
>>> +static void tcp_sock_release(struct socket *sock)
>>> +{
>>> +       kernel_sock_shutdown(sock, SHUT_RDWR);
>>> +       sk_release_kernel(sock->sk);
>>> +}
>>> +
>>> +static int tcp_sock_create4(struct net *net, __be16 port,
>>> +                           struct socket **sockp)
>>> +{
>>> +       int err;
>>> +       struct socket *sock = NULL;
>>> +       struct sockaddr_in tcp_addr;
>>> +
>>> +       err = sock_create_kern(AF_INET, SOCK_STREAM, 0, &sock);
>>
>> Should be: err = sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP, &sock);
>>
>
> ok.
>
>>> +       if (err < 0)
>>> +               goto error;
>>> +
>>> +       sk_change_net(sock->sk, net);
>>> +
>>> +       memset(&tcp_addr, 0, sizeof(tcp_addr));
>>> +       tcp_addr.sin_family = AF_INET;
>>> +       tcp_addr.sin_addr.s_addr = htonl(INADDR_ANY);
>>> +       tcp_addr.sin_port = port;
>>> +       err = kernel_bind(sock, (struct sockaddr *)&tcp_addr,
>>> +                         sizeof(tcp_addr));
>>
>> I think there should also be a kernel_listen also. I'm a little
>> surprised that this could work without it, it doesn't seem like we
>> should be finding closed sockets on input. In any case even if that
>> did work, it is quite annoying that the socket doesn't appear in
>> "netstat -ant".
>>
>
> This is fake TCP socket. it is created to gain exclusive access to the
> TCP port. STT receives packet from nf-hook, so no need to listening
> TCP socket.
> I am not updating any socket stats so I do not think you will see any
> socket stats.
>
Neither the system nor the sysadmin will know these are "fake" TCP
sockets. To the outside world this looks like TCP packets being sent
to a closed port with no RSTs nor replies being generated (one
conclusion may be DOS attack of some sort). These sockets need to be
visible in management tools. If you call listen on it at least we'll
see this in the open connections list, but it would be better to
create a completely new TCP state for STT sockets and display that.

>
>>> +       if (err < 0)
>>> +               goto error;
>>> +
>>> +       *sockp = sock;
>>> +       return 0;
--
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