Is void* vulnerable

[Lalatendu Das]

Is it vulnerable to use "void *" in the program as a return type or
as a TYPE of variable.
Does it lead to any exploitation of program in any means like use
strcpy( )
leads to some sort of exploitation to the progarm ?

 

[santosh]

Is it vulnerable to use "void *" in the program as a return type or
as a TYPE of variable.
No.

Does it lead to any exploitation of program in any means like use
strcpy( ) leads to some sort of exploitation to the progarm ?

No.

 

[Malcolm McLean]

Is it vulnerable to use "void *" in the program as a return type or
as a TYPE of variable.
Does it lead to any exploitation of program in any means like use
strcpy( )
leads to some sort of exploitation to the progarm ?

Any pointer introduces a potential security flaw if the programmer does not
control the address it points to.
void * must be converted to and from another type to be useful, and so a
wild void * is probably more likely than a wild pointer of any other type,
because there are more places in the chain for things to go wrong.

However if a pointer holds the correct address and the boundaries of the
object it points to are not overflowed, then pointers are safe.

 

[Fred Kleinschmidt]

Is it vulnerable to use "void *" in the program as a return type or
as a TYPE of variable.
Does it lead to any exploitation of program in any means like use
strcpy( )
leads to some sort of exploitation to the progarm ?

There is nothing wrong with strcpy. The problem in using it lies in
the programmer, not in the function. If the programmer is
careless, her app *might* be vulnerable to exploitation.

If you always check that the receiving buffer is at least as
long as the sending buffer, there is no problem:
if ( strlen(sender) <= known_length_of_receiver ) {
strcpy( receiver, sender );
}

or you can exclusively use strncpy()

 

[Eric Sosman]

Fred Kleinschmidt wrote On 02/09/07 14:55,:

There is nothing wrong with strcpy. The problem in using it lies in
the programmer, not in the function. If the programmer is
careless, her app *might* be vulnerable to exploitation.

If you always check that the receiving buffer is at least as
long as the sending buffer, there is no problem:
if ( strlen(sender) <= known_length_of_receiver ) {
strcpy( receiver, sender );
}

There's some ambiguity about known_length_of_receiver.
The receiving area's string length (if it contains a string
at all) is irrelevant, so what's really important is instead
known_size_of_receiver. But in that case, the <= above is
wrong and should be < instead ...

"Even in trivia there are traps."

or you can exclusively use strncpy()

Blecch.

 

[Christopher Benson-Manica]

Blecch.

Having looked like an idiot by trying to use strncpy() the way it
*should* work and not the way it *does* work, in public, more than
once, I second that "blecch".

 

[Christopher Layne]

There's some ambiguity about known_length_of_receiver.
The receiving area's string length (if it contains a string
at all) is irrelevant, so what's really important is instead
known_size_of_receiver. But in that case, the <= above is
wrong and should be < instead ...

"Even in trivia there are traps."


Blecch.

I've always found it fairly ridiculous that strncpy() insists on nullifying
anything remaining. What exactly was the thinking there in that purpose?

If you know the length enough to compare, might as well just use memcpy()
anwyays.

If it's coming from a foreign source, chances are you read it from some other
source - hence you probably have the length already and can avoid all of the
str* functions.

 

[Ben Pfaff]

I've always found it fairly ridiculous that strncpy() insists on nullifying
anything remaining. What exactly was the thinking there in that purpose?

Read the Rationale.

7.21.2.4 The strncpy function

strncpy was initially introduced into the C library to deal
with fixed-length name fields in structures such as
directory entries. Such fields are not used in the same
way as strings: the trailing null is unnecessary for a
maximum-length field, and setting trailing bytes for
shorter names to null assures efficient field-wise
comparisons. strncpy is not by origin a "bounded strcpy,"
and the Committee preferred to recognize existing practice
rather than alter the function to better suit it to such
use.

 

[CBFalconer]

There is nothing wrong with strcpy. The problem in using it lies
in the programmer, not in the function. If the programmer is
careless, her app *might* be vulnerable to exploitation.

If you always check that the receiving buffer is at least as
long as the sending buffer, there is no problem:
if ( strlen(sender) <= known_length_of_receiver ) {
strcpy( receiver, sender );
}

or you can exclusively use strncpy()

Or better, use strlcpy (which is non-standard). You can find a
portable implementation with documentation at:

<http://cbfalconer.home.att.net/download/>

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Lalatendu Das]

Thanks for all the infos.
I guess Malcom has told really relevant thing.
And I find the discussion about strcpy and strncpy intresting.
But I would rather prefer strncpy to (a condition + strcpy).

Thanks anyways.

 

[Richard Heathfield]

Lalatendu Das said:

Thanks for all the infos.
I guess Malcom has told really relevant thing.
And I find the discussion about strcpy and strncpy intresting.
But I would rather prefer strncpy to (a condition + strcpy).

That is almost always a mistake, because it involves potential data
loss. Make sure your buffer is big enough for strcpy. If it isn't, get
a bigger buffer!

 

[Richard Bos]

or you can exclusively use strncpy()

Yuck. strncpy() is just wrong, in the context of the rest of the
library[1]. Instead of

strncpy(str1, str2, n);
str1[n]='\0';

which almost always does the Wrong Thing, do

*str1='\0';
strncat(str1, str2, n-1);

which does what you actually want.

Richard

[1] It's right in the very limited historical context out of which it
grew, but that's no help to the other 99.99% of programs out there.

 

[Nick Keighley]

Lalatendu Das said:

That is almost always a mistake, because it involves potential data
loss. Make sure your buffer is big enough for strcpy. If it isn't, get
a bigger buffer!

plus it can copy unnecessary data.

char *s = "short";
char t [10000];
strncpy (s, t, 10000);

copies ~10000 nul characters at the end.

 

[Malcolm McLean]

Lalatendu Das said:

That is almost always a mistake, because it involves potential data
loss. Make sure your buffer is big enough for strcpy. If it isn't, get
a bigger buffer!

plus it can copy unnecessary data.

char *s = "short";
char t [10000];
strncpy (s, t, 10000);

copies ~10000 nul characters at the end.

But often you want that. If we've got any sort of memory problem then t
having old bits of human-readable strings embedded in it is going to
complicate debugging considerably.

 

[Flash Gordon]

Malcolm McLean wrote, On 12/02/07 19:55:

Lalatendu Das said:
Thanks for all the infos.
I guess Malcom has told really relevant thing.
And I find the discussion about strcpy and strncpy intresting.
But I would rather prefer strncpy to (a condition + strcpy).
That is almost always a mistake, because it involves potential data
loss. Make sure your buffer is big enough for strcpy. If it isn't, get
a bigger buffer!

plus it can copy unnecessary data.

char *s = "short";
char t [10000];
strncpy (s, t, 10000);

copies ~10000 nul characters at the end.

But often you want that.

I've never wanted that.

> If we've got any sort of memory problem then t
having old bits of human-readable strings embedded in it is going to
complicate debugging considerably.

Not really since you can see where the copied string ended easily enough.

On the other hand I don't want the needless inefficiency.

 

[Richard Heathfield]

Flash Gordon said:

Malcolm McLean wrote, On 12/02/07 19:55:

plus [strncpy] can copy unnecessary data.

char *s = "short";
char t [10000];
strncpy (s, t, 10000);

copies ~10000 nul characters at the end.

But often you want that.

I've never wanted that.

I have wanted that behaviour from time to time, but very rarely.

Not really since you can see where the copied string ended easily
enough.

More relevantly, Malcolm could have pointed out that having old bits of
human-readable string embedded in your data is a security risk for
programs where that matters. So sometimes it's a good idea to scrub the
data clean.

On the other hand I don't want the needless inefficiency.

Yes. When you don't need it, why pay for it?

And for my own part, I don't want the needless arbitrary data loss.

 

[Malcolm McLean]

More relevantly, Malcolm could have pointed out that having old bits of
human-readable string embedded in your data is a security risk for
programs where that matters. So sometimes it's a good idea to scrub the
data clean.

Exactly that thing happened to me the other day.
I was debugging a front end to MiniBasic. I called my test program
"helloFred". It asked me for a name, and I entered "Fred". Then it answered
"Hello Fred". However I neither scrubbed the buffer nor intialised it
correctly, so it printed out "Hello helloFred Fred". That sort of bug is OK
if you catch it early, but extremely confusing if it arises later on.

 

[Richard Heathfield]

Malcolm McLean said:

Exactly that thing happened to me the other day.
I was debugging a front end to MiniBasic. I called my test program
"helloFred". It asked me for a name, and I entered "Fred". Then it
answered "Hello Fred". However I neither scrubbed the buffer nor
intialised it correctly, so it printed out "Hello helloFred Fred".

How is that a security risk, exactly? Is Fred a secret agent? How does
Wilma feel about this? Is Mr Slate an agent provocateur?

 

[Flash Gordon]

Malcolm McLean wrote, On 13/02/07 08:15:
Yes, I agree there are sometimes good reasons. I also agree with the
rest of what you posted that Malcolm snipped.

Exactly that thing happened to me the other day.
I was debugging a front end to MiniBasic. I called my test program
"helloFred". It asked me for a name, and I entered "Fred". Then it answered
"Hello Fred". However I neither scrubbed the buffer nor intialised it
correctly, so it printed out "Hello helloFred Fred". That sort of bug is OK
if you catch it early, but extremely confusing if it arises later on.

It may be to you but I do not find it confusing at all. I would know
that depending on what I was doing I had either failed to initialised
the buffer or I had copied in a string without the nul termination.

 

[Christopher Layne]

But often you want that. If we've got any sort of memory problem then t
having old bits of human-readable strings embedded in it is going to
complicate debugging considerably.

Dude, no way.