('binary' encoding is not supported, stored as-is) Mailer: SecurityFocus In-Reply-To: <20011120150406.29986.qmailat_private> I have been trying to recreate this kind of situation with no luck. Below I will go into detail as to why I beleive this is so. Yes there is a off-by-one bof here. However I have doubts about its exploitability. >Bug is in libhttpd.c/auth_check(): > >static int >auth_check( httpd_conn* hc, char* dirname ) > { > static char* authpath; > static int maxauthpath = 0; > struct stat sb; > char authinfo[500]; > char* authpass; >[...] > l = b64_decode( &(hc->authorization[6]), authinfo, sizeof(authinfo) ); > authinfo[l] = '\0'; > from what I can tell that struct seems to be on the stack. If so this causing major problems in trying to exploit this bug. Perhaps I'm wrong. Any clarity is welcome. > l = b64_decode( &(hc->authorization[6]), authinfo, sizeof(authinfo) ); > authinfo[l] = '\0'; > >It made 'l' == 500 so "authinfo[500] = '\0'" be made and buffer is made >overflow by one byte I have been able to get this far but I get different results. It looks like half the null is going to the array and the other half somewhere else. If I am wrong about the struct this could mean exploitation but that would mean ebp would be under control. I have yet to experience that. >Exploitable? Yes. If compiler arrange 'authinfo' first on stack, then on x86 >machine it possible to overwrite saved register ebp value and fuck over >process like described by Olaf Kirch in 1998 team bugtraq post which >describe "Poison NUL Byte" method of punching hole in software to get in >computer. I have read that posting. It describes your run of the mill off-by-one overflow. Which with the testing I have done does not seem to be the case in this situation. However I maybe wrong. >2) Build and then: > >[terminal 1] > >mkdir test >echo "joe:blow" > test/.htpasswd >./thttpd -D -p 7777 > >[terminal 2] > >(printf "GET /test/ HTTP/1.0\r\nAuthorization: Basic " ; printf `perl -e >'print "A"x550'` | openssl enc -base64 -e -in /dev/stdin ; printf "\r\n\r\n") | nc 0 7777 > >[terminal 1] > >We see '41'. This mean off-by-one overflow is really present! > This is where I get really confused. I have debugged thttpd during a normal and accurate basic authentication session and compaired the registers to the buffer overflow authentication session. ebp seems to be untouched. I maybe wrong yet again but I have always thought no control over ebp means no execution of arbitrary code. If anyone else has had better luck recreating this scenario please respond. I would enjoy any comments or clarity. banned-it Fate Research Labs IDS Division -------------------------- [e] banned-itat_private [w] www.fatelabs.com
This archive was generated by hypermail 2b30 : Fri Nov 23 2001 - 15:55:24 PST