Secure version of I/O functions

[Ioannis Vranos]

Some days ago, I came across in the net a C standard (technical
corrigendum?) that specified secure equivalents of C functions ,
available to be used.

MS documentation provides info on some secure functions, but I not see a
specific ISO standard of them.

Does anyone know the standard where these functions are specified?

 

[santosh]

Some days ago, I came across in the net a C standard (technical
corrigendum?) that specified secure equivalents of C functions ,
available to be used.

MS documentation provides info on some secure functions, but I not see
a specific ISO standard of them.

Does anyone know the standard where these functions are specified?

http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n1036.pdf

 

[santosh]

http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n1036.pdf

I'm sorry. That was the wrong link. This one is correct (?):

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1093.pdf

 

[Richard Heathfield]

Ioannis Vranos said:

Some days ago, I came across in the net a C standard (technical
corrigendum?) that specified secure equivalents of C functions ,
available to be used.

MS documentation provides info on some secure functions, but I not see a
specific ISO standard of them.

Does anyone know the standard where these functions are specified?

Only the FUD Standard. The "secure" variants are mentioned (briefly) here:

http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Framework/CPlusSafeLibraries.htm

The basic idea is:

1) take a function that is perfectly secure if used properly, but which can
be used improperly;
2) write a version with a trailing _s on the name, which imposes a runtime
performance penalty not only on those who don't know how to use the
original function properly (which would be fair enough) but also on those
who do;
3) scare people away from the original functions by claiming that they are
insecure and "deprecated";
4) sit back in contentment at having contributed just a little to the
success of Gates's Law.

The canonical example, strcpy_s, "prevents" buffer overruns by taking a
length parameter, it is claimed. The claim is, of course, spurious.

As an exercise, think up at least one way in which you can overrun a buffer
using strcpy_s. It isn't difficult.

 

[Richard Heathfield]

santosh said:

I'm sorry. That was the wrong link. This one is correct (?):

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1093.pdf

Er, santosh... that's *not* a Standard.

 

[santosh]

santosh said:


Er, santosh... that's *not* a Standard.

Ah yes. I was too quick to pull up a link and failed to read the OP's
post carefully enough.

<snip>

 

[CBFalconer]

Some days ago, I came across in the net a C standard (technical
corrigendum?) that specified secure equivalents of C functions ,
available to be used.

MS documentation provides info on some secure functions, but I
not see a specific ISO standard of them.

Does anyone know the standard where these functions are specified?

Take a look at N1146 and N1147, at:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf>

This is another Microsoft effort to upset existing standards. I
advise ignoring them.

 

[Aaron Hsu]

Take a look at N1146 and N1147, at:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf>

This is another Microsoft effort to upset existing standards. I
advise ignoring them.

Wait, so, these functions are different than those such as strlcat()?
What "benefit" do they provide?

 

[santosh]

Wait, so, these functions are different than those such as strlcat()?
What "benefit" do they provide?

Most of the *_s functions take an additional length or size parameter.
The reasoning is that this is likely to reduce programming errors by
explicitly forcing the programmer to keep track of such details.

In practise, the length/size parameter could still be computed to an
incorrect value. There is no foolproof substitute for alertness on the
part of the programmer, though modern "managed" languages like VB and
JavaScript come very close to the holy grail of enabling anyone to
cobble together a "program."

 

[fnegroni]

I agree with the general consensus that the new 'secure' functions
have nothing to do with security.

When compiling on Windows using Visual C++, just make sure you define
the global macro
_CRT_SECURE_NO_WARNINGS

 

[jacob navia]

Ioannis Vranos said:


Only the FUD Standard. The "secure" variants are mentioned (briefly) here:

http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Framework/CPlusSafeLibraries.htm

The basic idea is:

1) take a function that is perfectly secure if used properly, but which can
be used improperly;

and it *was* used improperly a million of times except by geniueses like
heathfield.

Take gets() for instance.

2) write a version with a trailing _s on the name, which imposes a runtime
performance penalty not only on those who don't know how to use the
original function properly (which would be fair enough) but also on those
who do;

The performance penalty in most cases will be of the order of a few
integer comparisons. This is a non-issue, since many of
the unsecure functions will be thousands or ten thousands of
instructions. Making a few checks and giving a reasonable and
defined outcome for error cases is just error handling.

3) scare people away from the original functions by claiming that they are
insecure and "deprecated";

They are surely insecure:

printf("%s\n",string);

there is NO WAY to limit output in this specific case.

Not to speak about gets() or other goodies that the C standard
allowed.

4) sit back in contentment at having contributed just a little to the
success of Gates's Law.

Empty talk. If Mr Gates says

2+2 is 4

I will NOT say otherwise even if I risk being treated as a "traitor
that accepts Gates Law".

The canonical example, strcpy_s, "prevents" buffer overruns by taking a
length parameter, it is claimed. The claim is, of course, spurious.

Heathfield misses all other specs from strcpy_s. His claims are
spurious.

As an exercise, think up at least one way in which you can overrun a buffer
using strcpy_s. It isn't difficult.

Yes, sure. But a little more difficult than with strcpy isn't it?

Heathfield logic

"Since a perfect world can't exist, a perfect copy function either,
let's keep all buffer overflows and all stupid functions like
strcpy"

lcc-win implements most of this proposal.

 

[jacob navia]

santosh said:


Er, santosh... that's *not* a Standard.

Can't read Heathfield?
It is a Technical report where those function are specified. TRs are
the stage just before standardization

 

[jacob navia]

I agree with the general consensus that the new 'secure' functions
have nothing to do with security.

This is only a consensus within the "regulars" clique.

 

[Eric Sosman]

and it *was* used improperly a million of times except by geniueses like
heathfield.

Take gets() for instance.

It takes no "geniuese" to use gets() properly. Anyone
able to understand the phrase "Don't Do That" will know what
to do, and even a sub-genius can probably comprehend it.

They are surely insecure:

printf("%s\n",string);

there is NO WAY to limit output in this specific case.

The problem being ...? Or did you mean sprintf() instead
of printf()? What's your point?

 

[jacob navia]

It takes no "geniuese" to use gets() properly. Anyone
able to understand the phrase "Don't Do That" will know what
to do, and even a sub-genius can probably comprehend it.

Then , you agree that gets() can't be used properly
and that a function gets_s is OK since it makes gets()
usable. I was answering to heathfield's claim that
the secure functions proposal

This is not the case for gets()

The problem being ...? Or did you mean sprintf() instead
of printf()? What's your point?

???

So, an infinite loop making the program scan memory until it finds
a zero byte possible making it access non-existing memory doesn't
matter?

That is an unbounded memory scan for a zero byte!

 

[Eric Sosman]

Then , you agree that gets() can't be used properly
and that a function gets_s is OK since it makes gets()
usable. I was answering to heathfield's claim that
the secure functions proposal

No, you have (again) attributed to me both less and more
than I wrote:

Less:
"you agree that gets() can't be used properly"
No, I wrote that there *is* a proper way to use gets(),
namely, "Don't Do That."

More:
"... and that a function gets_s is OK"
No, I did not write any such thing. I do not know what
this gets_s() function does -- nor do I much care, since
I already have fgets().

So, an infinite loop making the program scan memory until it finds
a zero byte possible making it access non-existing memory doesn't
matter?

That is an unbounded memory scan for a zero byte!

Doesn't worry me much. Does the package also include a
"safe strlen" to avoid the unbounded memory scan for a zero
byte implicit in strlen(string)? How well does a "safe"
printf() substitute cope with

printf("%s\n", (char*)rand());

?

 

[santosh]

Then , you agree that gets() can't be used properly
and that a function gets_s is OK since it makes gets()
usable. I was answering to heathfield's claim that
the secure functions proposal


This is not the case for gets()


???

So, an infinite loop making the program scan memory until it finds
a zero byte possible making it access non-existing memory doesn't
matter?

That is an unbounded memory scan for a zero byte!

Even with one of the *_s functions a wrong value for the rsize_t
parameter is going to cause trouble. Null pointers may be caught, but
wild pointers are going to cause trouble.

This "secure" C proposal is, IMO, doomed to be ineffective. Nothing
short of complete runtime bounds checking is going to make C "secure".
These *_s functions can be misused with just a little more trouble than
their unadorned counterparts.

 

[ymuntyan]

This is only a consensus within the "regulars" clique.

That whole proposal is bullshit for people like you. Have you
seen the title page? It says "bounds checking". But it doesn't
check no bounds, it only makes sure you write or read no more
than 100 bytes of garbage instead of 1000. Oh yeah, it also
checks arguments for being non-NULL, some great improvement!

Why a proposal for standardization? Because a standard is
important and all that? Why not implement the latest (eight
years old now) standard then? Perhaps because they don't give
a shit? It's marketing crap. You trust it's not, well, good
for you. You'll be first to implement new standard, not the
authors of the great change to the standard, isn't it funny?

Am I now in clique, like a clique troll or something?

Yevgen

 

[santosh]

That whole proposal is bullshit for people like you. Have you
seen the title page? It says "bounds checking". But it doesn't
check no bounds, it only makes sure you write or read no more
than 100 bytes of garbage instead of 1000. Oh yeah, it also
checks arguments for being non-NULL, some great improvement!

Yes. IMO, a combination of something like libmudflap and use of Valgrind
is likely to be more useful than this redundant interface.

<snip>

 

[Richard Heathfield]

jacob navia said:

Can't read Heathfield?

I can read just fine, Mr Navia. In particular, I can read this.

"Warning
This document is an ISO/IEC draft Technical Report. It is not an ISO/IEC
International Technical Report. It is distributed for review and comment.
It is subject to change without notice and shall not be referred to as an
International Technical Report or International Standard."

It is a Technical report where those function are specified. TRs are
the stage just before standardization

Translation: It's not a Standard. Well done.