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]

Message-ID: <CALmbKGVUuZs+wigpkr0WPfn2pYP=tQh5-MsYWeRxbug=HskVQQ@mail.gmail.com>
Date:	Wed, 23 Nov 2011 15:27:33 -0500
From:	"G. D. Fuego" <gdfuego@...il.com>
To:	richard -rw- weinberger <richard.weinberger@...il.com>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Finding a hidden bound TCP socket

Any comments?  The behavior seems broken.  At the very least its very
inconsistent with other Unixes.

On Tue, Nov 15, 2011 at 3:23 PM, richard -rw- weinberger
<richard.weinberger@...il.com> wrote:
> 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/