Archief
- De topics van lang geleden
bug execv
27-03-2007, 21:16 door Anoniem, 19 reacties
Hoi!
Mijn exuses dat ik deze eerdere topic heb gedelete ik dacht eerst dat ik een
fout had gemaakt maar toch bleek het niet zo te zijn.
Zo vertelde anoniem in de topic van vinden van de shellcode in het
geheugen "Je weet dat strings in C met een NULL byte af worden
gesloten dus we xor'en eerst benodigde registers". En dit is niet zo
bij execv!
Zo kwam ik bij toeval achter toen ik met die null byte bezig was.
-------------------------------------
global _start
_start:
jmp short label_two
label_one
xor eax,eax
xor edx,edx
mov al,11
mov ebx,sh
push ecx,esp
push edx
int 0x80
label_three:
jmp label_one
sh db "/bin/sh"
-------------------------------------
Resultaat met ./a.out
sh-2.05b#
Dus kennelijk doet of de compiler dit automatisch of de cpu. Wel bizar.
Mijn exuses dat ik deze eerdere topic heb gedelete ik dacht eerst dat ik een
fout had gemaakt maar toch bleek het niet zo te zijn.
Zo vertelde anoniem in de topic van vinden van de shellcode in het
geheugen "Je weet dat strings in C met een NULL byte af worden
gesloten dus we xor'en eerst benodigde registers". En dit is niet zo
bij execv!
Zo kwam ik bij toeval achter toen ik met die null byte bezig was.
-------------------------------------
global _start
_start:
jmp short label_two
label_one
xor eax,eax
xor edx,edx
mov al,11
mov ebx,sh
push ecx,esp
push edx
int 0x80
label_three:
jmp label_one
sh db "/bin/sh"
-------------------------------------
Resultaat met ./a.out
sh-2.05b#
Dus kennelijk doet of de compiler dit automatisch of de cpu. Wel bizar.
Reacties (19)
Hohoho ik had het over die "push techniek". Als jij dus direct een string in
het geheugen pushed, dan zul je wel een NULL byte moeten gebruiken.
Jij maakt hier gebruik van een db waarbij je gewoon een fixed size array
van bytes declareert, dan wordt het gewoon door de compiler afgehandeld.
het geheugen pushed, dan zul je wel een NULL byte moeten gebruiken.
Jij maakt hier gebruik van een db waarbij je gewoon een fixed size array
van bytes declareert, dan wordt het gewoon door de compiler afgehandeld.
28-03-2007, 08:32 door
pikah
Je kan in assembly gewoon gebruik maken van een NULL byte,
dit werkt perfect en zonder problemen. Maar op het moment
dat je er shellcode van wil maken en deze vanuit C wil
runnen, dan moet je ervoor zorgen dat er geen NULL bytes
meer in staan.
Vandaar dat je er dan wel rekening mee moet houden.
dit werkt perfect en zonder problemen. Maar op het moment
dat je er shellcode van wil maken en deze vanuit C wil
runnen, dan moet je ervoor zorgen dat er geen NULL bytes
meer in staan.
Vandaar dat je er dan wel rekening mee moet houden.
Je kan in assembly gewoon gebruik maken van een NULL byte
Er is geen NULL byte in. Toen ik push 0 uit de code haalde dee die het ook
terwijl met xor,eax,eax push eax, die in een overflow aangaf.
Je kan in assembly gewoon gebruik maken van een NULL byte,
dit werkt perfect en zonder problemen.
dit werkt perfect en zonder problemen.
Ik heb geen gebruik gemaakt null byte. Toen ik push 0 weg haalde dee die
het ook. Terwijl die met xor ea,eax push eax een overflow aangaf. Die code heb ik gechecked in gdb . Zonder "/bin/sh" in de de string maar gewoon ""
opvallend dat push eax in een keer verdwenen was. In de disas main.
En dat is na mijn idee waneer die de null byte op de stack heeft geplaatst. En die staat er niet meer tussen.
ps. die reactie van anoniem was van mij was vergeten in te loggen :D
Door Anoniem op woensdag 28 maart 2007 09:27
quote:
--------------------------------------------------------------------------------
Je kan in assembly gewoon gebruik maken van een NULL byte
--------------------------------------------------------------------------------
Er is geen NULL byte in. Toen ik push 0 uit de code haalde dee die het ook
terwijl met xor,eax,eax push eax, die in een overflow aangaf.
Kan weg (=
28-03-2007, 10:11 door
SirDice
Het gaat er niet om of de shellcode wel of niet werkt met
een NULL byte er in. Het gaat er om of de uiteindelijke
shellcode een NULL byte bevat of niet. Als je je shellcode
in een string input wilt gebruiken (als buffer overflow)
geeft de NULL het einde van de string aan. Jouw code wordt
dan niet in z'n geheel door gegeven in de buffer die je
probeert te overflowen. Daarom moet die NULL byte er uit.
een NULL byte er in. Het gaat er om of de uiteindelijke
shellcode een NULL byte bevat of niet. Als je je shellcode
in een string input wilt gebruiken (als buffer overflow)
geeft de NULL het einde van de string aan. Jouw code wordt
dan niet in z'n geheel door gegeven in de buffer die je
probeert te overflowen. Daarom moet die NULL byte er uit.
Het gaat er niet om of de shellcode wel of niet werkt met
een NULL byte er in.
een NULL byte er in.
Nee, Het ging erom dat je alle functies in c moest afsluiten met een NULL
byte. Dat je het niet kan injecteren via shellcode is een heel ander verhaal
en dan ben ik het met je eens. Dat stukje programma code zou een
overflow moeten geven omdat die geen NULL byte heeft. Want execve is
wel aangeroepen. Dus zou er ook een NULL byte bij hadden gemoeten.
Gezien het een c functie is.
Wanneer je push 0 toevoegd geeft die bij gdb aan
xor %edx,%edx
mov $0xb,%al
mov $0x804809a,ebx
push $0x0
mov %esp,%ecx
push %edx
int $0x80
Execve aanroep zonder NULL
xor %edx,%edx
mov $0xb,%al
mov $0x804809a,ebx
mov %esp,%ecx
push %edx
int $0x80
Hoe kan die dan toch execve uitvoeren?
Waneer ik die dan run in gdb geeft die aan. Bij label_one+9
0x80408b (label_one+9) add %al,0x0
Is dat waar die de NULL toevoegd dan?
Jij maakt hier gebruik van een db waarbij je gewoon een fixed size array
van bytes declareert, dan wordt het gewoon door de compiler afgehandeld.
van bytes declareert, dan wordt het gewoon door de compiler afgehandeld.
Daar was ik dus nieuwschierig na of die compiler dit wil dee. Gezien assembly anders is als gcc.
28-03-2007, 10:48 door
[Account Verwijderd]
[Verwijderd]
28-03-2007, 10:54 door
pikah
Door SirDice
Het gaat er niet om of de shellcode wel of niet werkt met
een NULL byte er in. Het gaat er om of de uiteindelijke
shellcode een NULL byte bevat of niet. Als je je shellcode
in een string input wilt gebruiken (als buffer overflow)
geeft de NULL het einde van de string aan. Jouw code wordt
dan niet in z'n geheel door gegeven in de buffer die je
probeert te overflowen. Daarom moet die NULL byte er
uit.
Het gaat er niet om of de shellcode wel of niet werkt met
een NULL byte er in. Het gaat er om of de uiteindelijke
shellcode een NULL byte bevat of niet. Als je je shellcode
in een string input wilt gebruiken (als buffer overflow)
geeft de NULL het einde van de string aan. Jouw code wordt
dan niet in z'n geheel door gegeven in de buffer die je
probeert te overflowen. Daarom moet die NULL byte er
uit.
Dat probeer ik de hele tijd al te zeggen :D Misschien dat jou post iets duidelijker is als de mijne...
Verder moet je weten dat er een verschil is tussen het zelf pushen van bv 4 bytes of het gebruiken van een db. Zoals eerder gezegt, wanneer je gebruik maakt van db wordt er automatisch een achter gezet. Wanneer je zelf pushed moet je dit zelf doen.
Dus het is dan verplicht om gebruik te maken van
push 0x0
push 0x41414141
wanneer je "AAAA" wil pushen.
Waneer ik die dan run in gdb geeft die aan. Bij label_one+9
0x80408b (label_one+9) add %al,0x0
Hier wordt er bij het AL register (een van de twee 16-bit registers van EAX) 0 opgetelt)
Je stopt '/bin/sh' in je voorbeeld in een db en daar zet de
assembler automagisch een x00 achter.
assembler automagisch een x00 achter.
Ik heb het niet over shellcode... maar over de c syntax. En met name de
NULL in execve:
char * name [] = "/bin/sh";
execve (name [0], name, NULL);
Die heb ik niet gedeclared.... En toch voerd die execve uit. Of de comipler moet de x00 van de /bin/sh aan zien voor NULL ^_^
28-03-2007, 11:07 door
pikah
Je hebt hem wel gedeclareerd:
eax == systemcall
ebx == name[0]
ecx == name
edx == NULL // Dit is de xor edx,edx aan het begin van je code.
eax == systemcall
ebx == name[0]
ecx == name
edx == NULL // Dit is de xor edx,edx aan het begin van je code.
28-03-2007, 11:23 door
[Account Verwijderd]
[Verwijderd]
Thx, Allemaal !
Echt enorm bedankt !
Ik dacht eerst met edx was voor declaraties als bv /bin/sh zoals mov edx,9
voor mov ebx,sh. Dus dacht toen push gewoon edx op de stack voor sh.
Maar stond ff niet stil bij de gedachte dat het eigenlijk NULL was.
Daarom begreep ik het ook niet vanuit execve (name [0], name, NULL);
Echt enorm bedankt !
Ik dacht eerst met edx was voor declaraties als bv /bin/sh zoals mov edx,9
voor mov ebx,sh. Dus dacht toen push gewoon edx op de stack voor sh.
Maar stond ff niet stil bij de gedachte dat het eigenlijk NULL was.
Daarom begreep ik het ook niet vanuit execve (name [0], name, NULL);
28-03-2007, 12:20 door
pikah
Klopt maar die gebruikt hij in dit geval niet :D
Klopt maar die gebruikt hij in dit geval niet :D
Heb trouwens die code nu goed werkend volgens mij.
global _start
_start:
jmp short label_two
label_one:
xor eax,eax
mov al,11
mov ebx,sh
push ebx
mov ecx,esp
push edx
int 0x80
label_two:
jmp label one
sh db "/bin/sh"
Wel geinig trouwens want zoals nu is die helemaal zero byte vrij. Nog raar eigenlijk. Waneer push edx boven xor eax,eax zet execute die nog de shell sh. En gezien van uit lifo idee kan het niet eens want dan zou NULL voor name[0] staan. ^_^
28-03-2007, 13:44 door
pikah
Eerst vul je de registers, dan bij int 0x80 wordt het
interrupt naar de kernel geladen, die gaat de registers
lezen en dan wordt alles uitgevoerd.
Het maakt dus niet uit in welke volgorde je de registers vult.
Ik zou alleen voordat je edx pushed wel eventjes xor'ren. Anders ben je niet 100% zeker dat het 0 is. Het is nog steeds geheugen.
interrupt naar de kernel geladen, die gaat de registers
lezen en dan wordt alles uitgevoerd.
Het maakt dus niet uit in welke volgorde je de registers vult.
Ik zou alleen voordat je edx pushed wel eventjes xor'ren. Anders ben je niet 100% zeker dat het 0 is. Het is nog steeds geheugen.
28-03-2007, 14:26 door
pikah
In die registers zitten de argumenten van de system call.
Hier kan je misschien wel wat nuttigs vinden:
http://www.posix.nl/linuxassembly/
Hier kan je misschien wel wat nuttigs vinden:
http://www.posix.nl/linuxassembly/
Thx!
sweet,http://hyvatti.iki.fi/~jaakko/pic/picprog.html :D
http://mbtronics.homelinux.org/index.php?pag=kbspy.pag
sweet,http://hyvatti.iki.fi/~jaakko/pic/picprog.html :D
http://mbtronics.homelinux.org/index.php?pag=kbspy.pag
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
