linux-kernel - Re: Finding a hidden bound TCP socket

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

Date:	Tue, 15 Nov 2011 21:23:57 +0100
From:	richard -rw- weinberger <richard.weinberger@...il.com>
To:	"G. D. Fuego" <gdfuego@...il.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Finding a hidden bound TCP socket

On Tue, Nov 15, 2011 at 8:21 PM, G. D. Fuego <gdfuego@...il.com> wrote:
> Hello,
>
> I have a question about an odd linux networking behavior, that could
> potentially be a local networking DoS.  I'm curious if anyone is
> familiar with this behavior.
>
> Essentially I was assisting someone with tracking down a hidden tcp
> connection.  Attempts to bind to a particular port were failing,
> saying the socket was in use, even though netstat was not reporting
> any sort of connection.  They were initially suspecting a root kit,
> but after a bit of digging, I came across this page:
>
> http://dcid.me/2007/06/hidden-ports-on-linux/
>
> From the page:
>
> "Here is the idea. If you get this simple C program, it will attempt
> to bind every TCP port from 1025 to 1050, but it will not listen on
> them. After it is done, if you do a netstat (or fuser or lsof) nothing
> will be shown. However, if you try to use the port, you will get an
> error saying that it is already in use."
>
> I tested it out and confirmed that connections opened by their test
> program do in fact cause the port to be unavailable for use, and they
> are not reported in netstat, lsof, ss, or any other networking tools
> that I tried.  I'm unable to to find any references to the ports being
> in use anywhere I've looked within /proc.  Are you aware of another
> way to figure out which process may be bound to the port?  In our
> case, we figured out via trial and error which software was likely
> triggering this behavior.
>
> It seems to me that this could be a potentially interesting local
> networking DoS.  By binding to all ephemeral ports in this way, you'd
> prevent the local system from being able to establish any tcp
> connections, and it would be a pain to figure out which process was
> causing the problem.
>
> My lame attempts to exploit this failed due to a max file descriptor
> limit, but I'm told this could be doable by forking more processes for
> doing the binding.
>
> Is this behavior known/expected?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

CC'ing netdev

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/