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
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
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.
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)
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?
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).
On Sep 27, 2002 at 11:37, Philip S Tellis wrote:
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 reading from a disk file, so no worries about backspace and such.
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.
On Fri, 27 Sep 2002, Satya wrote:
It's good when you're doing a non-blocking read (using select).
Whta's good? fgets()?
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.
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.
On Fri, 27 Sep 2002, Manish Jethani wrote:
char *arg[4];
And now that you know how to malloc, I'd like to suggest a better approach -
char arg[4][30];
D'uh. While we were all looking at problems with the solutions, no one thought about relooking at the problem.
On Sep 30, 2002 at 10:05, Philip S Tellis wrote:
On Fri, 27 Sep 2002, Manish Jethani wrote:
char arg[4][30];
D'uh. While we were all looking at problems with the solutions, no one thought about relooking at the problem.
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.
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.
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@satya.virtualave.net wrote:
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
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
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.
On Oct 1, 2002 at 10:47, q u a s i wrote:
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.
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.
At 01:24 morn 10/1/02 -0700, Satya wrote:
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.
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.
[..C for dummies example]
Haven't read that. It's a fairly obvious example.
I was not alluding to any book.
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.
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
q u a s i wrote:
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.
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
At 01:46 even 10/1/02 +0530, MJ wrote:
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.
which is true. But a seg fault is also not too good a thing for one's program to do.
--- q u a s i quasar@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
At 01:56 morn 10/1/02 -0700, S wrote:
--- q u a s i quasar@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++).
^^^^^ [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.
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
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@vsnl.net wrote:
consider me a dummy
ok.
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
At 04:57 even 10/2/02 -0700, S...lesh wrote:
[...]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.
thanks. a good Samaritan, thou.
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@vsnl.net wrote:
At 04:57 even 10/2/02 -0700, S...lesh wrote:
[...]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.
thanks. a good Samaritan, thou.
__________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
--- Philip S Tellis philip@konark.ncst.ernet.in wrote:
On Thu, 3 Oct 2002, Shailesh wrote:
- Standard libraries (eg. Boost) --> if possible to
use
boost is standard? It isn't in my 'standard' installation.
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
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
- Standard libraries (eg. Boost) --> if possible to use
unfortunately, I do not use C++
- 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
On Tue, 1 Oct 2002, q u a s i wrote:
Fixed-size arrays are often (not always) bad.
ummm... Would it be possible to enlighten us (me) on this issue?
think buffer overflow.
-
Manish Jethani -
Nikhil Joshi -
Pankaj Jangid -
Philip S Tellis -
q u a s i -
Satya -
Shailesh -
Tahir Hashmi