Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

Re: [Full-Disclosure] H9-0001 Advisory: Sphiro HTTPD remote heap overflo

Subject: Re: [Full-Disclosure] H9-0001 Advisory: Sphiro HTTPD remote heap overflow (Rosiello Security)
Date: Fri, 30 Apr 2004 11:11:19 -0800
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@security.nnov.ru> wrote:

Dear Slotto Corleone,

--Friday, April 30, 2004, 3:43:15 AM, you wrote to 
full-disclosure@lists.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
Åñëè äàæå âû ïîëó÷èòå êàêîå-íèáóäü ïèñüìî, âû âñå ðàâíî íå ñóìååòå åãî 
ïðî÷èòàòü. (Òâåí)




<Prev in Thread] Current Thread [Next in Thread>