How to use gets_s

I don't know why I can't get this function to work, but I've spent all day and all night searching and have found nothing but problems. gets_s(buffer, size) is supposed to be a more direct, more secure replacement for gets(). So, why is it that on VC++ compiler, I still get buffer overflows even though I specify the sizeof(buffer) as the second argument? And on OS X (Darwin), it won't even compile, I get this error:

Undefined symbols:
"_gets_s", referenced from:
_main in ccHlsIH2.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Gets_s only works on VS.
But you had better use fgets instead of gets. I don't know if there's a safer version of gets, though.

And as for the size, you had better post some code you get problems with, so as for someone to have a look for you.

Quote:

---

Gets_s only works on VS.

---

gets_s is defined in ISO/IEC 99 maybe that is why it is not in other compilers?

but for VC++ my code looks like this:

Code:

---

#include <stdio.h>

int main ( int argc, char *argv[] )
{
        char stringArray[10] ;
       
        printf( "please enter some text" ) ;
        gets_s( stringArray, sizeof( stringArray ) ) ;
       
}

---

I've also tried using gets_s( stringArray, 10 ). The function works fine if the input is <= the amount attempted to store in stringArray, but if you type more than 9 characters, the program crashes and windows reports an error.

Is its really? Well, maybe it is, I don't really have a good check but...
Many compilers do not implement these safe functions.
Running your code, I get an assert followed by a crash. As it should be.
You don't?

Quote:

---

gets_s is defined in ISO/IEC 99 maybe that is why it is not in other compilers?

---

As far as I can tell, ISO/IEC 9899:1999 does not define gets_s.

As for ISO definition of gets_s, I got my information from this site: buildsecurityin.us-cert.gov

As far as I can tell from the explanation of the gets_s function, explained in the link above, it is supposed to return a NULL pointer if the input was larger than the size spec in the second argument. Not halt the program.

Quote:

---

As for ISO definition of gets_s, I got my information from this site: buildsecurityin.us-cert.gov

---

Read your source carefully: "gets_s() function is defined by ISO/IEC WDTR 24731". The function is not part of standard C (yet).

I see now, it had ISO/IEC 99 as a reference as well simply because it was talking about current standard functions as well as ISO/IEC WDTR 24731 (Secure C Library).

So the VC++ implementation of it still should not crash if there is more input than expected right? Isn't that why fgets and gets_s was designed to prevent overloading the buffer and causing a crash possibly opening the computer to security risks?

Quote:

---

Originally Posted by gwarf420

So the VC++ implementation of it still should not crash if there is more input than expected right? Isn't that why fgets and gets_s was designed to prevent overloading the buffer and causing a crash possibly opening the computer to security risks?

---

No, it will throw an assert and then crash, without doing a buffer overrun.
Yes, they were designed to prevent buffer overruns, but they aren't perfect. If you pass a buffer that's not large enough, it's (usually), your fault, a programmer mistake.

so, because every modern OS has memory protection, using gets() throws a fault and doesn't continue just like gets_s. Why should I go through the trouble of using these supposedly more robust/secure functions for standard input if they all behave the same way? A function like gets_s should (like I understood it to) simply see if the line in stdin is <= the amount of storage available, if not return a NULL pointer so I can handle that and say If NULL, printf("Your response is too long") ;

Is there no way to determine the amount of input coming from stdin like peak in VBasic and be able to handle the error like Try...Catch ---- or use malloc to dynamically allocate enough memory to store the input line?

Quote:

---

Originally Posted by gwarf420

so, because every modern OS has memory protection, using gets() throws a fault and doesn't continue just like gets_s.

---

No. Buffer overruns are a security issue and can cause data corruption.
http://cpwiki.sf.net/Buffer_overrun
Do take a look.

Quote:

---

Why should I go through the trouble of using these supposedly more robust/secure functions for standard input if they all behave the same way? A function like gets_s should (like I understood it to) simply see if the line in stdin is <= the amount of storage available, if not return a NULL pointer so I can handle that and say If NULL, printf("Your response is too long") ;

---

They are more meant to safeguard that you don't do buffer overruns, not as a solution to the problem.

Quote:

---

Is there no way to determine the amount of input coming from stdin like peak in VBasic and be able to handle the error like Try...Catch ---- or use malloc to dynamically allocate enough memory to store the input line?

---

Use fgets to chip away at the current data stored until you get a newline as the last character in the buffer or EOF.
There are no other solutions, other than maybe unportable functions or platform specific functions. Sorry, C is pretty limited in this regard.

In the secure coding article at buildinsecurity.us-cert.gov what is the purpose of the following code if it is only going to bomb out before the exception can be handled?

Code:

---

if (gets_s(buff, BUFFSIZE) == NULL)
{
    printf("diagnosed undefined behavior.\n");
    abort();
}

---

Why? Because otherwise you would use a potential buffer that is uninitialized. Garbage data or other worrysome things that can cause security issues.
It may not cause problems in this specific instance (since the previous fread succeeded), but can cause problems elsewhere. It's just an example. Not real code.
Sure, you can handle the error if you want. It was just a simple example and they didn't handle the error simply because of simplicity I guess.

so, the line "if (gets_s( buff, BUFFSIZE ) == NULL )" is not testing the return value of gets_s() but in fact testing to see if the buffer I specified was NULL? I'm sorry but that doesn't make sense to me. It doesn't look like the error can be handled. As soon as it enters the if and does gets_s, if the input is too large it will halt and end the program. Unless someone can show me otherwise. Does fgets() act this same way?

Quote:

---

Originally Posted by gwarf420

so, the line "if (gets_s( buff, BUFFSIZE ) == NULL )" is not testing the return value of gets_s() but in fact testing to see if the buffer I specified was NULL? I'm sorry but that doesn't make sense to me. It doesn't look like the error can be handled. As soon as it enters the if and does gets_s, if the input is too large it will halt and end the program. Unless someone can show me otherwise. Does fgets() act this same way?

---

No, NULL is return if there was an error (such as end-of-file when the first attempt to read was made). Of course if you pass in NULL, it will also return NULL (assuming it succesfully completes), since it returns the address of the buffer. But since NULL should normally cause a trap/exception/fault of some sort if you try to read/write to such an address, it's unlikely that you ever see a NULL returned for that reason - it will at the very least try to write a 0 at the end of the string. So, conclusion: If you pass in a NULL buffer, it will cause the program to crash, and you will not see a return value [unless you use exception handling and catch the system fault and then continue, but you should then come back to somewhere other than the return of the gets_s() function, so I don't think this can happen]

The only exception would be if your input is already at end-of-file, in which case the function will not modify the input, but it will return a constant NULL, rather than your passed in buffer NULL - do you really care about this rather obscure case?

What we really want to prevent is that someone maliciously can allow input data to be executed - if you allow that, you potentially allow others to interfere with your machine. This gets even better if the interface is available to external users (e.g. through the internet).

--
Mats

so, the only check in the line "if (gets_s( buff, BUFFSIZE ) == NULL )" is to see if there is an absence of input in which the error is caught and handled. But does not check whether or not the amount of input is more than the specified buffer size, instead it just bombs out.
I rewrote the gets_s() function to behave the way that it should. It works but does anyone see any problems with it?

Code:

---

#include <stdio.h>

char * getss ( char *s, int size ) ;

int main ( int argc, char *argv[] )
{
        char buffer[10] ;
       
        printf ("Enter a string:  ") ;
       
        if (getss(buffer, 10) == NULL) printf ("Buffer Overloaded!") ;
        else printf ("The line entered was: %s\n", buffer) ;
        return 0 ;
}

char *getss(char *s, int size)
{
    char *stringBuilder = (char *) malloc( size * sizeof( char )) ;
    int i, k;
   
    /* Read and store characters until reaching a newline or end-of-file */
    for (i = 0; k != EOF && k != '\n'; i++)
    {
        k = getchar() ;
    /* If a read error occurs, the resulting buffer is not usable. */
        if (i > size) return NULL ;
        if (k == EOF && !feof(stdin)) return NULL;
          stringBuilder[i] = k;
    }
    /* Null-terminate and return the buffer on success.
      The newline is not stored in the buffer. */
  //stringBuilder[i] = '\0';

    strcpy( s, stringBuilder ) ;
    return s;
}

---

Yes.
You never free stringBuilder.
And why not just use fgets?

Quote:

---

Originally Posted by Elysia

Yes.
You never free stringBuilder.
And why not just use fgets?

---

Thanks, I'll make sure to free it and I see that it is not Null terminating the string also.
I just tried fgets(). Unfortunately, it has the same response to finding more input than specified. it just dies. I understand bounds checking is good, but allow to handle the error instead of exiting the program. So, I would need to modify fgets() as well, to respect the size given in the parameter and return NULL if there is more input than expected instead of doing an assert. I mean, how am I to make a useful program if the program exits any time someone types one more character than the field is permitted?

On an aside, I found this excellent ppt presentation that explains the dangers or arc-injection, code-injection, and various mitigation techniques for buffer overflows, I think it would be helpful for anyone trying to learn how to program in C securely.

Quote:

---

Originally Posted by gwarf420

I just tried fgets(). Unfortunately, it has the same response to finding more input than specified. it just dies.

---

No, it doesn't. It reads up to a maximum of the specified characters - 1 and appends null to the end.
So how do we know if fgets read the entire line or not? Simple.
First, check the return of fgets. Does it return 1? If yes, then it means it read successfully (ie, not end of file). Then check the last character before the null in the buffer. Is it '\n'? If yes, then fgets read the entire line. If not, read some more.

Quote:

---

I understand bounds checking is good, but allow to handle the error instead of exiting the program.

---

Usually, because it means it's a programmer error. C is very unfriendly when it comes to buffers. Sometimes it is mostly the programmer's fault for not providing big enough buffers. And it's better than nothing.

Quote:

---

So, I would need to modify fgets() as well, to respect the size given in the parameter and return NULL if there is more input than expected instead of doing an assert.

---

No you don't, see above.

Quote:

---

On an aside, I found this excellent ppt presentation that explains the dangers or arc-injection, code-injection, and various mitigation techniques for buffer overflows, I think it would be helpful for anyone trying to learn how to program in C securely.

---

Nice catch. Let's investigate this one and see if we can put it somewhere.

Quote:

---

Originally Posted by Elysia

No, it doesn't. It reads up to a maximum of the specified characters - 1 and appends null to the end.
So how do we know if fgets read the entire line or not? Simple.
First, check the return of fgets. Does it return 1? If yes, then it means it read successfully (ie, not end of file). Then check the last character before the null in the buffer. Is it '\n'? If yes, then fgets read the entire line. If not, read some more.

---

Erm, fgets(), like gets(), returns a pointer to the buffer, or NULL if EOF was encountered. It will never ever return 1 [For the pedants: unless you have a system where memory address 1 is a valid address, and that's what you passed to fgets() - but that rules out most modern 32-bit OS's at least].

--
Mats

>> First, check the return of fgets. Does it return 1? If yes, then it means it read successfully (ie, not
>> end of file).

fgets returns the buffer or NULL, not a number.

gwarf, it sounds like you need to roll your own. If you know how realloc works you can make an input function that reads an entire line up to '\n'

Quote:

---

Originally Posted by matsp

Erm, fgets(), like gets(), returns a pointer to the buffer, or NULL if EOF was encountered. It will never ever return 1 [For the pedants: unless you have a system where memory address 1 is a valid address, and that's what you passed to fgets() - but that rules out most modern 32-bit OS's at least].

---

Quote:

---

Originally Posted by citizen

>> First, check the return of fgets. Does it return 1? If yes, then it means it read successfully (ie, not
>> end of file).

fgets returns the buffer or NULL, not a number.

---

Oops, yes, I was thinking of fread.
Still, that presentation is pretty good. Just beware of the void main in there.
And not surprisingly, it does mention that Visual Studio catches some common errors such as some buffer overruns and stack smashing.

Quote:

---

Originally Posted by Elysia

It means it's a programmer error. C is very unfriendly when it comes to buffer overflows. It is the programmer's fault, for whatever reason (not considering implementation deficiencies).

---

fixed.

Quote:

---

Originally Posted by Elysia

Oops, yes, I was thinking of fread.

---

fread does not guarantee return of 1 on success.

Quote:

---

Originally Posted by robwhit

fixed.

---

If you like it better that way...

Quote:

---

fread does not guarantee return of 1 on success.

---

No, it doesn't, it returns "count," but it was a simplification since I always use fread(whatever, size, 1, file).

Quote:

---

Originally Posted by Elysia

If you like it better that way...

---

:D I find it less inflammatory.

[QUOTE]
I just tried fgets(). Unfortunately, it has the same response to finding more input than specified. it just dies.[/QOUTE]

My bad, I was using a function that tested gets_s() and then fgets() right after it. So, it was not fgets that was causing the assert. It was my useless friend gets_s().

fgets() works well, but seems to cause its own complications:
1. The '\n' is stored in the string (which is fine if I'm just dumping input to a file). In order to use input for variables, I would have to go through each input string and NULLify the '\n' characters.
2. If there is more input than the length of the buffer, I would need to flush the rest of the input line.

I believe the least complex way of accepting input is to implement this function that is similar in behavior to C++'s getline which is stack safe and dynamic (then I can validate the input length, format, etc):

Code:

---

char * getstring ()
{
        FILE *tempFile = tmpfile() ;
        int i, k = 0 ;
        char *s = NULL ;
   
    if (tempFile)
        {
                /* Read and store characters until reaching a newline or end-of-file */
                for (i = 0; k != EOF && k != '\n'; i++)
                {
                        k = getchar() ;
               
                /* If a read error occurs, the resulting buffer is not usable. */
                if (k == EOF && !feof(stdin)) return NULL;
               
                if (k == '\n') fputc( '\0', tempFile ) ;  //substitute NULL termination for newline
                else fputc( k, tempFile ) ;
               
                }
               
                s = (char *) realloc( s, ++i * sizeof( char ) ) ;
                rewind( tempFile ) ;
                fgets( s, i, tempFile ) ;
                fclose( tempFile ) ;
                tempFile = NULL ;
                return s;
        }
        else return NULL ;
}

---

Anybody have any idea why if I pass a character pointer into this function and realloc the passed pointer, it does not retain the new info back in the main function?

If you want to modify a pointer, you need a pointer to pointer, because you can only modify something if you have a pointer to it (you need to know the original address of the thing you want to modify).

--
Mats