> > Answer 1. Besides port access granted by ioperm/iopl, svgalib needs write > access to /dev/mem to operate. Therefore svgalib keeps an open > descriptor ( number three usually ) to /dev/mem ( is it true in all cases ? > can someone confirm that authoritatively ? ). So, we can modify our uid AFAIK this is always correct. I am not sure if it is fd 3 or 4 though. > ( any kernel structure in fact ) by writing to the kernel > memory via /dev/mem. All we need to do in our shellcode is to exec a program > which does lseek(3,someoffset,SEEK_SET); write(3,"\000\000",2) > where someoffset is the addres of our uid in our task_struct. > It is even easier than that. > Q2. Pure technical question: How do I find the address of my task_struct ? > Better question: is the task struct the only thing you can muck with to gain additional privileges. > > Q3 An obstacle. When you spawn the exploit being logged from another > system, you'll receive a message "You must be the owner of the current > console to run zgv" and zgv terminates before its stack is smashed. > Indeed, zgv tries to limit the usage of itself, allowing to be run only > by the user who owns current /dev/tty? . How can this check be bypassed > ? > > Answer 3. Launch X-server, for instance by running X :1 & . X server will > change the current tty to the next free one and make you owner of it, > fooling zgv. > This part was clever, I hadn't thought of this. > Conclusions: > 1) Any suid program that uses svgalib must be secured against overflows as > tightly as any other suid binary. Absolutely 100% correct. ... Complex code removed ... The exploit for this is even easier than you think. The HOME overflow, which was mentioned in KSRT advisory #1 (where we also hinted that there were other prolems in svgalib (which was going to be our next advisory :-) ) you can gain access to the /dev/mem file descriptor. By using the exploit posted to bugtraq / rootshell shortly after the KSRT advisory, you can gain access to a shell that has inherited the /dev/mem file descriptor. At that point, you can modify any portion of system memory. In our tests, we just modified any occaision of /usr/sbin/tcpd to /bin/sh, which is far easier than hunting for the task_struct. Then connect to any service that was tcpwrapped, and instant shell. There are probably even easier ways. We will probably make the 2nd svgalib advisory available on our website once it comes back online. Dave G. <dhgat_private>
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:20:47 PDT