Re: GSoC 2012 Project - Vulnerability and exploitation specialist

[Djalal Harouni <tixxdz () opendz org>]

On Mon, Mar 26, 2012 at 05:53:39PM +0200, Aleksandar Nikolic wrote:
[...]
> > And if the script will panic Windows then you should add 'dos' category.
> >
> >
> > (I did not follow this RDP stuff so sorry for my dumb questions)
> >
> > That said, if you have a test that will check/confirm the vulnerability
> > without the DoS then it will be better to start with it, perhaps a version
> > check or something else ?
> >
> > After the patch does something change from the first received bytes before
> > the check ?
> >
> > The sole purpose of this script is to test the server in a safe way and
> avoid triggering the DoS.
> It's already doing what you are suggesting. Just triggering the bug is
> trivial.
> The way this works follows:
> 1. send one user request
>  - server replies wit user id (let's call it A) and channel for that user
> 2. send another user request
>  - server replies with another user id (let's call it B) and another channel
> 3. send channel join request with requesting user set to A and requesting
> channel set to B
>  - this is the actual bug, user A should not be able to get channel of user
> B
>  - if server replies with success message , we conclude that the server is
> vulnerable
>  - if we do not get the success message , the server is patched
> 4. in case the server is vulnerable, send a channel join request with
> requesting user set to B and requesting channel set to B to prevent the
> chance of BSoD
> 5. The end
Ok, so you should just add the two vulnerability entries.

> This should be clear from the code, but I hope I've cleared things a bit
> more.
Thank you for the clarification.

> Thank you,
> Aleksandar Nikolic
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

-- 
tixxdz
http://opendz.org
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/