Linux and UNIX Secure Programming howto-be careful when calling and exporting other resources

From: http://man.chinaunix.net/tech/secure_programs_howto_cn/c711.html

Restrict the call exit to a valid value

Make sure to call otherProgramOnly valid and expected values of each parameter are allowed. It sounds not difficult, but it is much harder to implement, because many library calls or commands call low-level routines in potentially amazing ways. For example, a number of system calls such as popen (3) and system (3) are implemented by calling the shell command, that is, they are affected by Shell escape characters. In the same case, execlp (3) and execvp (3) may also call shell. Many guidelines recommend that you avoid using popen (3), system (3), execlp (3), and execvp (3) when generating a process, and directly use execve (3) in C) [Galvin 1998b]. At least avoid using system (3) When execve (3) can be used; because system (3) uses shell to expand characters, system (3) will provide more opportunities. The backtick (') of Perl and Shell also calls the shell command in the same way. For more information, see the Perl section.

The biggest headache for this problem is Shell escape characters. The standard UNIX-like shell (stored in/bin/sh) has a special explanation of many characters. If these characters are passed to the shell, unless ignored, their special interpretations will be used; this can be used to destroy the program. According to the WWW Security FAQ [Stein 1999, q37], these escape characters are:

&; ''\" | *? ~ <> ^ () [] {}$ \ N \ r

Unfortunately, this is not actually all escape characters. There may be some other characters below:

• "!" It means "no" in the expression (just like in C); if the return value of the program is detected, consider "!" in advance. It will fool the script to think it has failed or vice versa when something has succeeded. In some shells, "!" Will access the past of the command, which will lead to real problems. In bash, only the interaction mode may fail, but tcsh (the CSH replication mode in some Linux distributions) even uses "!" In scripts. The new bash also seems to use "!". To access the previous commands-but it may only be used in interactive mode.

• "#" Is a comment character, and subsequent text is ignored.

• "-" Is misunderstood as an option (or Disable other options like ). Even when it is in the middle of the file name, or there is a character in front of shell that is considered to be a space, there may be problems.

• "" (Space) and other space characters convert a "separate" file name into multiple parameters.

• Other control characters (especially nil) may cause problems in some shell implementations.

• According to the application situation, you can even imagine ". "(" run in current shell ") and" = "(set variables) are both worrying characters, and the examples found at present indicate that these problems will cause more serious security problems.

Forgetting a character may cause disastrous consequences. For example, many programs ignore the backslash as an escape character [RFP 1999]. As discussed in the "Confirm input" section, a recommendation solution ignores all these characters at least once entered. Similarly, the best solution currently is to identify the characters you want to allow and only use these characters.

Many programs have "escape" for performing "extra" operations"Code; Make sure they are not included (unless you want them to appear in the message ). For example, many line-oriented mail programs (such as mail and mailx) use tokens (~) As escape characters, it can be used to send many commands. As a result, commands like "mail admin <file-from-user" that seem innocent will be used to execute arbitrary programs. Interaction programs such as VI and Emacs have an "escape" mechanism, which usually allows users to execute arbitrary shell commands during the process. Check the Program Calling documentation in any case to find the escape mechanism.

This prevents code escape and even involves underlying hardware components and their simulators. Most modems implement the so-called "Hayes" command set, use the "++" sequence, a latency plus "++" to force the modem to switch the mode (and use the subsequent text as the command explanation ). This can be used to launch denial-of-service attacks, or even force a user to connect to another person. Many "terminal" interfaces implement the escape code of VT100 class old physical terminals that are outdated. For example, these codes can be used to change the font color of the Terminal interface. However, do not allow sending arbitrary untrusted data directly to the terminal screen, because some code may cause serious problems. You can remap buttons on some systems; on several systems, you can even send code to clear the screen, display a group of commands that you want the victim to run, and send these settings back (forcing the victim to run the commands selected by the attacker ).

One problem related to this is that the NIL character (character 0) may have unexpected consequences. Most C and C ++ functions assume that the character marks the end of the string, but the string processing routines in other languages (such as Perl and ada95) can process strings containing nil. Because many library and kernel calls use the C language specification, the result is that the checked content is not actually used [RFP 1999].

When calling other programs or referencing a file, you should always specify its full path (such/Usr/bin/sort). For program calls, even if the path value is set incorrectly, This will eliminate possible errors caused by calling the "error" command. When referencing other files, this reduces the problem caused by the "error" Starting directory.