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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ