full-disclosure - Re: Vulnerability Note VU#12345

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]

Message-ID: <a19de5380805080633i44f20814j88bf927d34573acf@mail.gmail.com>
Date: Thu, 8 May 2008 09:33:41 -0400
From: "Dr. J Swift" <fdiscsplat@...il.com>
To: "Security Group" <secgro@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Vulnerability Note VU#12345

An alternate solution is proposed requiring zero modifications to the
legacy software of Full Disclosure clients.

Proposal:
The proposal is to remove certain rogue processes that spawn an
inordinate number of threads where those threads individually and
collectively have high CPU utilization and yet provide little benefit
to the processing of the Full Disclosure system.

Method:
A novel method is introduced whereby an executive monitoring process
watches for the creation of such time intensive threads and
selectively destroys their parent process via the injection of
reflective capabilities to the parent.  [Note: reflective capabilities
allow certain processes which parent an inordinate count of time
intensive threads to observe the futility of their own state and
self-terminate.]

Notes:
It is acknowledged that the solution proposed is not optimal.
However, due to the disparate nature of FD clients and the general
inertia inhibiting change in FD clients en mass, it is felt that the
addition of a monitoring layer allows the system of FD to continue
unabated by a set of well-defined, fully vetted, and minimally cpu and
bandwidth intensive executive monitoring primitives.

All further changes would be encapsulated in the executive primitives.
 This obviates the need to duplicate changes across all FD clients.

I look forward to further discussion on this topic.

Respectfully Yours,

Dr. Jonathan Swift

On Thu, May 8, 2008 at 2:22 AM, Security Group <secgro@...il.com> wrote:
> Vulnerability Note VU#12345
>
>  Full Disclosure DoS vulnerability
>
>  Overview
>  A vulnerability in the way the mailinglist 'Full disclosure' handles
>  'n3td3v' packets could result in a remotely exploitable denial of
>  service.
>
>
>  I. Description
>  'Full disclosure' does not properly handle trolling packets, which can
>  render the service useless. Upon receiving a trolling message the
>  system response with a huge number of disapproval-messages. The
>  magnitude of these disapproval-messages will cause a client to stop
>  listening to the service.
>
>
>  II. Impact
>  An attacker can render 'Full disclosure' useless.
>
>
>  III. Solution
>  Clients of 'Full disclosure' should drop trolling messages of 'n3td3v'
>  or others instead of sending a response of disapproval.
>
>
>  Vendor          Status       Date Updated
>  Full-discluse   Vulnerable   28-Apr-2008
>
>  _______________________________________________
>  Full-Disclosure - We believe in it.
>  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>  Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/