And if one do:
procedure example is
type C_String_Type is array (1..10) of Character;
a : C_String_type;
begin
a := ('1','2','3','4','5','6','7','8','9','A','B','C','D');
end example;
then when compiling:
% gnatmake example.adb
gnatgcc -c example.adb
example.
Alvin Oga <[EMAIL PROTECTED]> wrote on 24/01/2002 (11:13) :
>
> hi ya ralf
>
> i would have thought that gcc would barf on b[20]='X'
> and similarly for theother variable assignments since its not prev
> allocated/defined.. and yet explicitly assigned (incorrectly??)...
Why there are no range te
And if one do:
procedure example is
type C_String_Type is array (1..10) of Character;
a : C_String_type;
begin
a := ('1','2','3','4','5','6','7','8','9','A','B','C','D');
end example;
then when compiling:
% gnatmake example.adb
gnatgcc -c example.adb
example
Alvin Oga <[EMAIL PROTECTED]> wrote on 24/01/2002 (11:13) :
>
> hi ya ralf
>
> i would have thought that gcc would barf on b[20]='X'
> and similarly for theother variable assignments since its not prev
> allocated/defined.. and yet explicitly assigned (incorrectly??)...
Why there are no range t
On Wed, 23 Jan 2002 18:03:26 -0500 (EST), Emmanuel Valliet
<[EMAIL PROTECTED]> wrote:
>There was a good article of Aleph One on buffer overflows called
>'Smashing the stack for fun and profit'. Phrack 49.
>Search the web and enjoy :)
I found this one to be quite informative too:
http://www.cultd
On Wed, 23 Jan 2002 18:03:26 -0500 (EST), Emmanuel Valliet
<[EMAIL PROTECTED]> wrote:
>There was a good article of Aleph One on buffer overflows called
>'Smashing the stack for fun and profit'. Phrack 49.
>Search the web and enjoy :)
I found this one to be quite informative too:
http://www.cult
hi ya ralf
i would have thought that gcc would barf on b[20]='X'
and similarly for theother variable assignments since its not prev
allocated/defined.. and yet explicitly assigned (incorrectly??)...
its lot harder to control when the coder does
strcpy or readln() without first chcking the length
Here is a simple example with shellcode. It will give you a nice shell if
there's a /bin/sh on your system :
--
#include
#include
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
> #include
>
> void example()
> {
> char a[10];
> char b[10];
> strcpy(a, "123456789");
> printf ("a: %s\n", a);
> b[20]='X';
> b[21]='Y';
> b[22]='Z';
> printf("a: %s\n", a);
> return;
> }
> main()
> {
> example();
> }
Ralf,
i ran this code
very interesting results, how? i woul
hi,
> anyone to offer any
> explanation will be showered with greatness!
here is an example:
#include
void example()
{
char a[10];
char b[10];
strcpy(a, "123456789");
printf ("a: %s\n", a);
b[20]='X';
b[21]='Y';
b[22]='Z';
printf("a: %s\n", a);
return;
}
main()
{
example();
hi ya ralf
i would have thought that gcc would barf on b[20]='X'
and similarly for theother variable assignments since its not prev
allocated/defined.. and yet explicitly assigned (incorrectly??)...
its lot harder to control when the coder does
strcpy or readln() without first chcking the lengt
(2002-01-23) Steve Johnson sed :
| this may seem trivial but i've never really understood how a buffer
| overflow happens and effects your system, i have some knowledge of
| programming, but not much at low levels. like dealing direct with
| memory or devices(other than using standard pointer
hi ya steve...
when you write a program... you usually pass variables around...
the system keeps a "stack of return address/variables" ..what to do
next...
the rootkits tries to make the return address of "foo" program
to give them root access..
- so much for my simplied one-liners..
- a simp
this may seem trivial but i've never really understood how a buffer
overflow happens and effects your system, i have some knowledge of
programming, but not much at low levels. like dealing direct with
memory or devices(other than using standard pointers and reading and
writing to devices thruough
Here is a simple example with shellcode. It will give you a nice shell if
there's a /bin/sh on your system :
--
#include
#include
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
> #include
>
> void example()
> {
> char a[10];
> char b[10];
> strcpy(a, "123456789");
> printf ("a: %s\n", a);
> b[20]='X';
> b[21]='Y';
> b[22]='Z';
> printf("a: %s\n", a);
> return;
> }
> main()
> {
> example();
> }
Ralf,
i ran this code
very interesting results, how? i wou
hi,
> anyone to offer any
> explanation will be showered with greatness!
here is an example:
#include
void example()
{
char a[10];
char b[10];
strcpy(a, "123456789");
printf ("a: %s\n", a);
b[20]='X';
b[21]='Y';
b[22]='Z';
printf("a: %s\n", a);
return;
}
main()
{
example();
(2002-01-23) Steve Johnson sed :
| this may seem trivial but i've never really understood how a buffer
| overflow happens and effects your system, i have some knowledge of
| programming, but not much at low levels. like dealing direct with
| memory or devices(other than using standard pointe
hi ya steve...
when you write a program... you usually pass variables around...
the system keeps a "stack of return address/variables" ..what to do
next...
the rootkits tries to make the return address of "foo" program
to give them root access..
- so much for my simplied one-liners..
- a sim
this may seem trivial but i've never really understood how a buffer
overflow happens and effects your system, i have some knowledge of
programming, but not much at low levels. like dealing direct with
memory or devices(other than using standard pointers and reading and
writing to devices thruoug
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
>
> it indeed sounds VERY interesting (not only to me) :-)
> although I never dealt with special kernel modifications.
> But I'll give it a go..can anyone recommend any other
> kernel security patch sites? ..would be great!
I never tested it, but it lo
On Fri, 2002-01-18 at 22:15, Hassard, Stephen wrote:
> I'm not sure if anyone has tried this one, but a fairly extensive patch set
> for the 2.4 series of kernels is available called grsecurity
> (http://www.grsecurity.net). It includes whole whacks of stuff (take a look
> at the "features" page ht
Tim Uckun <[EMAIL PROTECTED]> wrote on 19/01/2002 (10:16) :
>
> >Has anyone any interesting comments about theses methods ?
>
> There are also alternative languages like cyclone
> http://www.research.att.com/projects/cyclone/ (which is based on C) and of
> course you could use a high level angu
On Friday 18. January 2002 21:33, Alvin Oga wrote:
> openwall works only w/ 2.2.x kernels unless they've released 2.4.x stuff
I beleive it has been ported to linux kernel 2.4 in grsecurity.
http://grsecurity.net/
--
Harald Skoglund
hi ya pav
good examples...
for more code checkers..( looking for bad code )
http://www.Linux-Sec.net/Audit/audit_tools.gwif.html#Code
have fun linuxing
alvin
On Sat, 19 Jan 2002, Pavel Minev Penev wrote:
> On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> > Hi all !
> >
>
Tim Uckun <[EMAIL PROTECTED]> wrote on 19/01/2002 (10:16) :
>
> >Has anyone any interesting comments about theses methods ?
>
> There are also alternative languages like cyclone
> http://www.research.att.com/projects/cyclone/ (which is based on C) and of
> course you could use a high level ang
code execution on the stack:
http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz
- Original Message -
From: Vincent <[EMAIL PROTECTED]>
To:
Sent: Saturday, January 19, 2002 4:11 PM
Subject: Re: protection against buffer overflows
>
On Friday 18. January 2002 21:33, Alvin Oga wrote:
> openwall works only w/ 2.2.x kernels unless they've released 2.4.x stuff
I beleive it has been ported to linux kernel 2.4 in grsecurity.
http://grsecurity.net/
--
Harald Skoglund
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
Hi all, and thanx for your help on this subject !
So far, I've seen mainly 3 methods to fight against buffer overflows :
1/ Kernel-patching oriented methods, to prevent any execution in the
stack
2/ Libsafe's overwriting of vulnerable functions, in a lib loaded
bef
hi ya pav
good examples...
for more code checkers..( looking for bad code )
http://www.Linux-Sec.net/Audit/audit_tools.gwif.html#Code
have fun linuxing
alvin
On Sat, 19 Jan 2002, Pavel Minev Penev wrote:
> On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> > Hi all !
> >
>
On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> Hi all !
>
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and
code execution on the stack:
http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz
- Original Message -
From: Vincent <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 19, 2002 4:11 PM
Subject: Re: protection against buffer overflows
>
--
To U
Hi all, and thanx for your help on this subject !
So far, I've seen mainly 3 methods to fight against buffer overflows :
1/ Kernel-patching oriented methods, to prevent any execution in the
stack
2/ Libsafe's overwriting of vulnerable functions, in a lib loaded
be
you should check out PaX as well: http://pageexec.virtualave.net
they got stuff for both 2.2.x and 2.4.x
- Original Message -
From: Vincent <[EMAIL PROTECTED]>
To:
Sent: Friday, January 18, 2002 9:20 PM
Subject: protection against buffer overflows
>
On Fri, Jan 18, 2002 at 09:20:16PM +0100, Vincent wrote:
> Hi all !
>
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and
you should check out PaX as well: http://pageexec.virtualave.net
they got stuff for both 2.2.x and 2.4.x
- Original Message -
From: Vincent <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 18, 2002 9:20 PM
Subject: protection against buffer overflows
>
--
To UNSUBS
c: debian-security@lists.debian.org
> Subject: Re: protection against buffer overflows
>
>
>
> hi ya vincent
>
> > I'm working on buffer overflows these days, and more precisely the
> > possible methods to avoid them. It seems that the most used
> tools
Has anyone any interesting comments about theses methods ?
There are also alternative languages like cyclone
http://www.research.att.com/projects/cyclone/ (which is based on C) and of
course you could use a high level anguage like pyton, perl, java, scheme etc.
:wq
Tim Uckun
US Investiga
hi ya vincent
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and maybe Saint Jude.
>
> Has anyone any interesting comm
Cc: [EMAIL PROTECTED]
> Subject: Re: protection against buffer overflows
>
>
>
> hi ya vincent
>
> > I'm working on buffer overflows these days, and more precisely the
> > possible methods to avoid them. It seems that the most used
> tools
>Has anyone any interesting comments about theses methods ?
There are also alternative languages like cyclone
http://www.research.att.com/projects/cyclone/ (which is based on C) and of
course you could use a high level anguage like pyton, perl, java, scheme etc.
:wq
Tim Uckun
US Investigati
hi ya vincent
> I'm working on buffer overflows these days, and more precisely the possible
> methods to avoid them.
> It seems that the most used tools to prevent exploits based on buffer
> overflows are Libsafe, OpenWall, StackGuard... and maybe Saint Jude.
>
> Has anyone any interesting com
42 matches
Mail list logo
