Gets

From Wikipedia, the free encyclopedia

The correct title of this article is gets. The initial letter is shown capitalized due to technical restrictions.

gets is a function in the C standard library, declared in the header file stdio.h, that reads a line from the standard input and stores it in a buffer provided by the caller. It might be implemented as follows:

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

As indicated by the code above, gets does not perform bounds checking on the input, and therefore is a potential source of buffer overflow exploits in programs that use it. Most gets man pages contain the warning "Never use gets"[1] precisely because of this design flaw.

While the use of gets is not officially deprecated by any C standard, its use is discouraged; it is left in the C89 and C99 standards for backward compatibility. Some development tools, such as lint, will emit warnings when code using gets is linked. The fgets(..., stdin) function is a frequently suggested substitute.

Safe use of gets requires that the programmer ensure that buffer overflows cannot be a problem. Standard C provides no way to do this; however, there are a number of relatively complicated ways to ensure it, with varying degrees of portability, including:

  • Use a guard page to protect memory. Alone, this turns exploitable buffer overflows into mere crashes. In combination with an exception handler, such as one involving SIGSEGV and sigaction, the guard page can allow graceful error handling.
  • Do not use gets on data which is less trusted than the program itself, thus avoiding privilege escalation. Somewhat obviously, this makes gets unsuitable for handling the untrusted data that setuid programs and network services are faced with. Less obviously, gets is unsuitable for handling data files that users may acquire from others. One should remember that code is often reused in future projects which may need to handle untrusted data, often without review for possible security issues.