[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <38AC1C58.25D609BB@mail.gmail.com>
From: slotto at gmail.com (Slotto Corleone)
Subject: H9-0001 Advisory: Sphiro HTTPD remote heap overflow (Rosiello Security)
What? Did you not read the fucking rest of it you clueless sack of
shit? Here let me give you a little tutorial on how the stack works
because obviously you don't know.
The first overflow is not exploitable on linux x86 directly because of
the way that filename[128] is allocated in a lower stack address than
auth_buff[MAX_READ]. Yes, if there is some place filename[128] is
copied and the sting length is assumed to be at max 128 bytes but
isn't because I extended it into auth_buff, then maybe we could
exploit the stack overflow here. BUT WE DON'T FUCKING CARE ABOUT THIS
OVERFLOW SO PLEASE READ ON
Ok, now since you didn't actually look at the rest of the email I will
paste it again:
- sphiro/libhttp/security.c <-- security? heh
int find_rullefile (char *request)
...
char *filename;
...
filename = (char *) malloc ( strlen(request) + strlen(config->webroot) + strlen
("secure.auth") +1 );
...
sprintf( filename,"%s/%s/secure.auth",config->webroot,request+1);
Do I need to give you a tutorial on why this is exploitable too?
Sphiro is not meant to be any serious http daemon and this advisory is
obviously not serious. Nothing in this advisory is a lie. Since you
don't understand any of this (maybe because english isn't your primary
language) I will make you a numbered list of points that this
"advisory" was written for.
1. rave is a clueless piece of shit
2. angelo is a script kiddie
3. rosiello security can't even write secure code but claim to be a
security company?
4. endorse www.boobys.org
On Fri, 30 Apr 2004 19:49:54 +0400, 3APA3A <3apa3a@...urity.nnov.ru> wrote:
>
> Dear Slotto Corleone,
>
> --Friday, April 30, 2004, 3:43:15 AM, you wrote to full-disclosure@...ts.netsys.com:
>
> SC> - sphiro/libhttp/http_socks.c
> SC> int get_request(int type,struct sockaddr_in client,int sc,SSL *s)
> SC> ...
> SC> char buffer[MAX_READ +1];
> SC> char auth_buff[MAX_READ+1];
> SC> char filename[128];
> SC> ...
> SC> ...
>
> <skipped>
>
> SC> sprintf(filename,"%s%s",config->webroot,request); <-- oops
>
> According to information you provided this is stack overflow, not heap.
> And in this very case it looks not to be exploitable, because behind
> filename boundaries sprintf() overwrites beginning of auth_buf. Of cause
> I may be wrong, full annalists of source code required to make
> conclusion.
>
> --
> ~/ZARAZA
> ???? ???? ?? ???????? ?????-?????? ??????, ?? ??? ????? ?? ??????? ??? ?????????. (????)
>
>
Powered by blists - more mailing lists