26 Sep
2002
26 Sep
'02
1:18 p.m.
Hi!
I've tried this simple prog to encrypt a file using XOR
But it gives "Segmentation Fault " in 'interactive' mode (pls see the
source code)
it runs perfectly well in DOS (using Turbo C++ 3.0)
Can ny1 help pls ?
--
Nikhil Joshi
26 Sep
26 Sep
2:58 p.m.
On Thu, Sep 26, 2002 at 01:20:34PM +0530, Nikhil Joshi wrote:
I've tried this simple prog to encrypt a file
using XOR
But it gives "Segmentation Fault " in 'interactive' mode (pls see the
source code)
Read the man page of gets (it is obsolate and is dangerous). And try
some other option to read the strings. Allocate the (char *) pointers before
storing strings in them.
regards
--
Pankaj Jangid
ETU, NCST
Tel: +91-22-756 0013/5303/5304/5305
Fax: +91-22-756 0004
Yahoo: pankaj_jangid
27 Sep
27 Sep
10:27 a.m.
On Thu, 26 Sep 2002, Nikhil Joshi wrote:
I've tried this simple prog to encrypt a file
using XOR
But it gives "Segmentation Fault " in 'interactive' mode (pls see the
source code)
hehe.
didn't anyone tell you that you have to allocate memory before you can
gets into it?
char *arg[4];
...
gets(arg[1]);
man gets:
gets() reads a line from stdin into the buffer pointed to
^^^^^^^^^^^^^^^^^^^
by s until either a terminating newline or EOF, which it
replaces with '\0'. No check for buffer overrun is per-
formed (see BUGS below).
My guess is it's purely coincidental that your code worked on DOS.
--
In Mexico we have a word for sushi: bait.
-- Josi Simon
11:09 a.m.
My guess is it's purely coincidental that your
code worked on DOS.
Mustn't be much of a coincidence. Once I wrote a struct for a matrix
of doubles that was initialized on input from a file and it used
dynamic memory allocation.
I went on to make a heavy-duty Gauss-Jordan solver out of it and
tested it with the given equations (it was an assignment in college).
The program ran perfectly except for a memory access violation at the
very end of execution after all the results had been obtained.
Turned out that I forgot to allocate memory for _any_goddamed_thing_!
(That was supposed to be just one malloc()).
The compiler? TurboC++. (Don't ask me what _I_ was doing with TC++ :D)
--
Tahir Hashmi (VSE, NCST)
http://staff.ncst.ernet.in/tahir
tahir AT ncst DOT ernet DOT in
We, the rest of humanity, wish GNU luck and Godspeed
11:09 a.m.
On Sep 27, 2002 at 10:18, Philip S Tellis wrote:
man gets:
gets() reads a line from stdin into the buffer pointed to
^^^^^^^^^^^^^^^^^^^
by s until either a terminating newline or EOF, which it
replaces with '\0'. No check for buffer overrun is per-
formed (see BUGS below).
Bah, I should've used fgets() for my parser, instead of reading a
character at a time and examining it. Bah. Philip, is my method so
horrendous that I should replace it with fgets(), assuming it's not
production code, but for a class project?
--
Satya. <URL:http://satya.virtualave.net/>
S met ing's hap ening t my k ybo rd . .
11:54 a.m.
On Thu, 26 Sep 2002, Satya wrote:
Bah, I should've used fgets() for my parser,
instead of reading a
character at a time and examining it. Bah. Philip, is my method so
horrendous that I should replace it with fgets(), assuming it's not
reading a character at a time is fine if you don't care about
bufferring. However, you'll have to take care of backspace yourself.
It's good when you're doing a non-blocking read (using select).
--
I'm killing time while I wait for life to shower me with meaning and
happiness.
-- Calvin
28 Sep
28 Sep
1:24 a.m.
On Sep 27, 2002 at 11:37, Philip S Tellis wrote:
On Thu, 26 Sep 2002, Satya wrote:
It's reading from a disk file, so no worries about backspace and such.
Bah, I should've used fgets() for my parser,
instead of reading a
character at a time and examining it. Bah. Philip, is my method so
horrendous that I should replace it with fgets(), assuming it's not
reading a
character at a time is fine if you don't care about
bufferring. However, you'll have to take care of backspace yourself. It's good when you're doing a non-blocking read
(using select).
Whta's good? fgets()?
I'm doing a select()ed read elsewhere. The select call is doing
double-duty: waiting for a packet and waiting for a timeout.
--
Satya. <URL:http://satya.virtualave.net/>
hAS aNYONE sEEN mY cAPSLOCK kEY ?
30 Sep
30 Sep
10:33 a.m.
On Fri, 27 Sep 2002, Satya wrote:
if you're using select, you generally use something that will read as
how much you tell it to read, but will settle for less. fgets might
block if it reads all available data and doesn't see the newline or
exceed size.
It's good
when you're doing a non-blocking read (using select).
Whta's good? fgets()? I'm doing a select()ed read elsewhere. The select
call is doing
double-duty: waiting for a packet and waiting for a timeout.
yeah, I do something similar in my sample yahoo messenger client. I use
select to read from stdin, a socket, and to send a keepalive packet
every 20 minutes - at most.
--
These days the necessities of life cost you about three times what they
used to, and half the time they aren't even fit to drink.
30 Sep
30 Sep
10:23 a.m.
On Fri, 27 Sep 2002, Manish Jethani wrote:
D'uh. While we were all looking at problems with the solutions, no one
thought about relooking at the problem.
--
I've already got a female to worry about. Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
char *arg[4];
And now that you know how to malloc, I'd like to suggest a
better approach -
char arg[4][30];
11:02 a.m.
On Sep 30, 2002 at 10:05, Philip S Tellis wrote:
On Fri, 27 Sep 2002, Manish Jethani wrote:
Fixed-size arrays are often (not always) bad. I usually try to malloc,
and if I must have fixed-size, I try to #define the magic numbers.
Yeah, you can comment on my project after I submit it.
--
Satya. <URL:http://satya.virtualave.net/>
It's Ensign Flintstone - he's Fred, Jim.
char arg[4][30];
D'uh. While we were all looking at problems with the solutions, no one
thought about relooking at the problem.
3:24 a.m.
On Oct 1, 2002 at 01:42, q u a s i wrote:
At 10:18 even 9/29/02 -0700, Satya wrote:
>Fixed-size arrays are often (not always) bad.
ummm... Would it be possible to enlighten us (me) on
this issue?
Classic buffer overflow. Say you have:
char buf[80]; /* i like 80 */
and you read user input or network data into that buffer, without
checking bounds.
Even if you do bounds checking, you'll have a limited input condition.
This is fine if, for example, you're reading birthdates in yyyymmdd
format (example, could be mm-dd-yyyy for all I care), you know it's
always going to be 8 (or 9, considering Y10K) chars (plus 1 for the
trailing null, which depending on your application you may not need),
so you can have that be static.
But it's safest to malloc and realloc, because then you're only
limited by how much memory the OS is willing to give you.
--
Satya. <URL:http://satya.virtualave.net/>
Kernel panic: I have no root and I want to scream <--- perfect error
message
1:20 p.m.
Hi,
With a security perspective, the buffer overflow problem is
not anything to do with bound arrays. Oh no no no..
It is w.r.t how your coding logic works!
what you want to make sure is you copy only as much data as
you have allotted space for. It doesn't matter if this
memory allocation was done using malloc or arrays
but there is one place where dynamic allocation is not
good. Think maximum memory allocation char buf[2 << 16];
when in a particular execution you only needed 2<< 5 bytes!
u might b better off simply allotting (digging) only as
much as you need(to bury)!
again in satya's eg. of date.. i m sure people are going to
pass me a string with dd-mm-yy or some such variant.. then
i m trusting them to b good citizens. So i would do either
(array or malloc) and write code as
strcpy(this_foo_date, nice_date);
will b crashed by a cracker quickly by making nice_date to
a abnormally large size and the strcpy will copy more than
it intends! solution..
strncpy(this_foo_date, evil_date, i_max_size_allowed);
Point: It did not matter if it was malloc'ed or array
defined.
just my 2 bits.
Shailesh
--- Satya <satyap(a)satya.virtualave.net> wrote:
On Oct 1, 2002 at 01:42, q u a s i wrote:
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
At 10:18 even 9/29/02 -0700, Satya wrote:
>Fixed-size arrays are often (not always) bad.
ummm... Would it be possible to enlighten us (me)
on
this issue?
Classic buffer overflow. Say you have:
char buf[80]; /* i like 80 */
and you read user input or network data into that buffer,
without
checking bounds.
Even if you do bounds checking, you'll have a limited
input condition.
This is fine if, for example, you're reading birthdates
in yyyymmdd
format (example, could be mm-dd-yyyy for all I care), you
know it's
always going to be 8 (or 9, considering Y10K) chars (plus
1 for the
trailing null, which depending on your application you
may not need),
so you can have that be static.
But it's safest to malloc and realloc, because then
you're only
limited by how much memory the OS is willing to give you.
--
Satya. <URL:http://satya.virtualave.net/>
Kernel panic: I have no root and I want to scream <---
perfect error
message
_______________________________________________
http://mm.ilug-bom.org.in/mailman/listinfo/linuxers
1:29 p.m.
At 02:39 even 9/30/02 -0700, Satya wrote:
Classic buffer overflow. Say you have[...]:
buffer over flow is defined as when you feed more data than the buffer has
[free] capacity for. Due to the C legacy which does not do bound checking
for array writes this may lead to to bad places. Agreed. But when you
malloc you allocate /limited/ memory too. There is /no/ way to prevent you
from overflowing an allocated buffer if you so wish.
Even if you do bounds checking, you'll have a
limited input condition.
yeah, if you allocate 64 bytes (I like 2^n - aligns well), say, then you
/do/ have a limit.
[..C for dummies example]
But it's safest to malloc and realloc, because then you're only limited by
how much memory the OS is willing to give you.
to malloc or not to malloc is the question. ummmm... Malloc allows you to
have sophisticated mechanisms where you may limit size of buffer to only
the size of free memory available from the OS. I seem to remember
someplace that realloc should be avoided as it is highly
inefficient. Someone else can have a say on this maybe. For truly
flexible storage a linked lists of buffers may be more the way to go.
2:14 p.m.
On Oct 1, 2002 at 10:47, q u a s i wrote:
At 02:39 even 9/30/02 -0700, Satya wrote:
I guess I should say that dynamic memory allocation, by definition,
allows you to allocate as much memory as you need at runtime.
Classic buffer overflow. Say you have[...]:
buffer over flow is defined as when you feed more data than the buffer has
[free] capacity for. Due to the C legacy which does not do bound checking
for array writes this may lead to to bad places. Agreed. But when you
malloc you allocate /limited/ memory too. There is /no/ way to prevent you
from overflowing an allocated buffer if you so wish. >[..C for dummies example]
Haven't read that. It's a fairly obvious example.
inefficient. Someone else can have a say on this
maybe. For truly
flexible storage a linked lists of buffers may be more the way to go.
Like for a text editor? Yeah, and you're still mallocing the structs.
--
Satya. <URL:http://satya.virtualave.net/>
A feature is a bug with seniority.
6:17 p.m.
At 01:24 morn 10/1/02 -0700, Satya wrote:
which is irrelevant. What makes you /not/ to define a array sufficiently
large as per your needs before hand? In both cases someone who does /not/
heed your needs [or simply is trying to be bad] may pour in more data then
there is space available for. Malloc does not have a predictive logic
built into it by which it keeps up with the memory requirements. It just
allocates what you as it to. The mechanism has to be provided by the
program logic, which was the point of the last communique.
I was not alluding to any book.
You have very /conveniently/ snipped off portions which state the same
thing. There was a line above - "Malloc allows you to have sophisticated
mechanisms where you may limit size of buffer to only the size of free
memory available from the OS." Malloc is a standard function for
allocating memory dynamically. But it by itself does /not/ solve the
overflow problem - which is what you insinuated. One has to have a
mechanism for having a truly flexible input buffer. And the one I
mentioned may not be a good method - it was just a method to support a point.
quasi
malloc you
allocate /limited/ memory too. There is /no/ way to prevent you
from overflowing an allocated buffer if you so wish.
I guess I should say that dynamic memory allocation, by definition, allows
you to allocate as much memory as you need at runtime. >[..C for
dummies example]
Haven't read that. It's a fairly obvious example. inefficient.
Someone else can have a say on this maybe. For truly
flexible storage a linked lists of buffers may be more the way to go.
Like for a text editor? Yeah, and you're still mallocing the structs. 
2:15 p.m.
q u a s i wrote:
At 02:39 even 9/30/02 -0700, Satya wrote:
I think the thing with a fixed-sized array on the stack is that
a buffer overrun will more certainly overwrite the program code
which is far more dangerous than overwriting some random memory.
Manish
Classic buffer overflow. Say you have[...]:
buffer over flow is defined as when you feed more data than
the buffer has [free] capacity for. Due to the C legacy
which does not do bound checking for array writes this may
lead to to bad places. Agreed. But when you malloc you
allocate /limited/ memory too. There is /no/ way to prevent
you from overflowing an allocated buffer if you so wish.
6:09 p.m.
At 01:46 even 10/1/02 +0530, MJ wrote:
which is true. But a seg fault is also not too good a thing for one's
program to do.
lead to to bad
places. Agreed. But when you malloc you
allocate /limited/ memory too. There is /no/ way to prevent
you from overflowing an allocated buffer if you so wish.
I think the thing with a fixed-sized array on the stack is that a buffer
overrun will more certainly overwrite the program code which is far more
dangerous than overwriting some random memory.
2:33 p.m.
--- q u a s i <quasar(a)vsnl.net> wrote:
For truly
flexible storage a linked lists of buffers may be more
the way to go.
hmm... not really.. plethora of known problems here unless
u r careful (think speed of access.. ) if u can use then go
for BOOST library (C++).
Re-iterating the point .. Again this is for flexible
storage.. It has nothing to do with buffer overflow
problem. That is a coding issue.
Just as an eg., windows CRT in scanf, gets, uses a simple
algorithm. Allocate 4096 byte buffer array. Read inputs in
chunks of 4096 bytes and keep passing!
hth,
Shailesh
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
6:18 p.m.
At 01:56 morn 10/1/02 -0700, S wrote:
--- q u a s i <quasar(a)vsnl.net> wrote:
^^^^^
[cannot really do that, please be more spoon feedish. - consider me a dummy
as Satya did]
I would be interested in knowing some of the 'plethora' of problems
mentioned about. as for the speed issue, I would be mucho obliged if you
could suggest a method which is faster.
For truly
flexible storage a linked lists of buffers may be more the way to go.
hmm... not really.. plethora of known problems here unless u r careful
(think speed of access.. ) if u can use then go for BOOST library (C++). Re-iterating the point .. Again this is for flexible
storage.. It has
nothing to do with buffer overflow problem. That is a coding issue.
both are related. If I am supposed to take input which is of undetermined
length & I dont want to miss any bytes then the above is relevant. How in
the name of Gawd do you say it has nothing to do with buffer overflows is
beyond me. They occur because of predicted size of expected input. Of
course the methods of avoiding that are a design[1] issue.
Just as an eg., windows CRT in scanf, gets, uses a
simple algorithm.
Allocate 4096 byte buffer array. Read inputs in chunks of 4096 bytes and
keep passing!
keep passing where? To memory space being dynamically added? Memory space
which can be called a buffer? Memory chunks which are in someway linked [to
give the impression of one large chunk]? If you look carefully at what I
wrote you may see that these two are approximately the same things.
[1] - Design as in problem solution. Coding is just translation - mundane
& irrelevant.
quasi
3 Oct
3 Oct
5:43 a.m.
Hi,
flexible storage using linked list of buffers-
from memory.. atleast one library that does that... GMP. It
uses linked lists to store and access large numbers. the
problem we face in optimization is one size does not fit
all.. more on the lines of large buffers-small data: memory
unnecessarily allotted, small buffers and a deep linked
list hence increasing latency. so may be 'horses for
courses' its a good idea you have and is known to be
implemented elsewhere too. At the same time, acknowledge
the issues involved.
flexible storage v/s buffer overflow:
buffer overflow is something you have to manage with in
your programming logic aka design (now adding). It has
nothing to do with whethere you use arrays, malloc's or
above method. In other words use of either of above methods
does not ensure my code to be free of buffer overflow
problems.
you r right in saying buffer overflow stems up from
predicted size of input.. but ur programming logic should
take care of reading only as much as you can and rejecting
the rest.
In windoz CRT 'passing':
quasi, scanf is a core libc function which interfaces with
user thru I/O funcs (keyboard in this case) and users
program in the other end. so passing here implies taking
data from input and passing it in to user passed pointer!
hope that clarifies,
Shailesh
--- q u a s i <quasar(a)vsnl.net> wrote:
consider me a dummy
ok.
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
4 Oct
4 Oct
1:14 a.m.
At 04:57 even 10/2/02 -0700, S...lesh wrote:
thanks. a good Samaritan, thou.
[...]At the same time, acknowledge the issues involved.
eh? /Those/ issues where not the point of discussion.
flexible storage v/s buffer overflow:
[...]
you r right in saying buffer overflow stems up from
predicted size of input.. but ur programming logic should take care of
reading only as much as you can and rejecting the rest.
which I have already mentioned in great detail. So why repeat the same point?
In windoz CRT 'passing':
[...]and passing it in to user passed pointer!
agreeably I have not done any windows programming. These above explained
details are new to be but slightly irrelevant as we are not discussing
/particular/ systems.
hope that clarifies,
It does not clarify what your point is. The matter was clear enough to me
earlier [except, the details of your example].
My original reaction was towards the insinuation by Satya that fixed arrays
are dangerous and the reason being buffer overflows. My reply, though
travelling in a roundabout way, said the same thing that you did. I did
not reply to your earlier mail because I felt we both had the same
point. The linked buffers example I gave was ad-hock and was to support my
argument. I never claimed it is even a good solution. My exact statement
"For truly flexible storage a linked lists of buffers may be more the way
to go." - which is true enough.
Hope that /this/ clarifies your [mis]understandings.
consider me a
dummy
ok.
5:14 a.m.
quasi,
The point in replying to your mail was to suggest other
alternatives. My suggestions were
1. Standard libraries (eg. Boost) --> if possible to use
2. If not --> use design methodologies eg. given is a
simple scanf implementation in windows crt
-shailesh
--- q u a s i <quasar(a)vsnl.net> wrote:
At 04:57 even 10/2/02 -0700, S...lesh wrote:
thanks. a good Samaritan, thou.
_______________________________________________
http://mm.ilug-bom.org.in/mailman/listinfo/linuxers
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
[...]At the same time, acknowledge the issues
involved.
eh? /Those/ issues where not the point of discussion.
flexible storage v/s buffer overflow:
[...]
you r right in saying buffer overflow stems up from
predicted size of input.. but ur programming logic
should take care of
reading only as much as you can and rejecting the
rest.
which I have already mentioned in great detail. So why
repeat the same point?
In windoz CRT 'passing':
[...]and passing it in to user passed pointer!
agreeably I have not done any windows programming. These
above explained
details are new to be but slightly irrelevant as we are
not discussing
/particular/ systems.
hope that clarifies,
It does not clarify what your point is. The matter was
clear enough to me
earlier [except, the details of your example].
My original reaction was towards the insinuation by Satya
that fixed arrays
are dangerous and the reason being buffer overflows. My
reply, though
travelling in a roundabout way, said the same thing that
you did. I did
not reply to your earlier mail because I felt we both had
the same
point. The linked buffers example I gave was ad-hock and
was to support my
argument. I never claimed it is even a good solution.
My exact statement
"For truly flexible storage a linked lists of buffers may
be more the way
to go." - which is true enough.
Hope that /this/ clarifies your [mis]understandings.
consider
me a dummy
ok.
11:38 a.m.
--- Philip S Tellis <philip(a)konark.ncst.ernet.in> wrote:
On Thu, 3 Oct 2002, Shailesh wrote:
Right. It is not in the current C++ standard. There is a
move to standardize some of its interfaces! It is available
at www.boost.org for download.
-shailesh
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
1. Standard libraries (eg. Boost) --> if
possible to
use
boost is standard? It isn't in my 'standard'
installation.
9:11 p.m.
At 04:26 even 10/3/02 -0700, S wrote:
The point in replying to your mail was to suggest other
alternatives.
thank you for your consideration.
My suggestions were
1. Standard libraries (eg. Boost) --> if possible to use
unfortunately, I do not use C++
2. If not --> use design methodologies eg. given is
a simple scanf
implementation in windows crt
more so, I do not program windows.
thanks anyway,
quasi
1 Oct
1 Oct
10:39 a.m.
On Tue, 1 Oct 2002, q u a s i wrote:
think buffer overflow.
--
Might as well be frank, monsieur. It would take a miracle to get you out
of Casablanca and the Germans have outlawed miracles.
-- Casablanca
Fixed-size
arrays are often (not always) bad.
ummm... Would it be possible to enlighten us (me) on this issue?
7660
days inactive
7668
days old
28 comments
8 participants
participants (8)
-
Manish Jethani -
Nikhil Joshi -
Pankaj Jangid -
Philip S Tellis -
q u a s i -
Satya -
Shailesh -
Tahir Hashmi