Preventing Format String Attacks A class of attacks that were started by June 2000 was format-string attack in which hostile inputs are passed on directly triggering format strings function calls such as printf. The main problem that arises here is that any directive (such as %n) will execute, with remote (root) privileges. Attempts were made to resolve the problem by removing such directives from the list of directives or allowing static format strings, but this would ultimately render many programs unfit to run. FormatGuard was proposed to solve this issue accounts for variation in the number of arguments. This count is then sent to the function (printf for instance) wrapper, and whenever it finds a difference in the number of arguments it kills the process.
Preventing Input Validation AttacksTaint analysis can be effective in preventing input validation attacks, especially with command injection in web applications. In such cases, unwanted system commands that are like pseudo system shell gets executed as an authorised system user. This grant the inputs, the same privileges and environment the normal application would run. Improper input validation, mostly system commands like “rm”, “ls”, “chroot”, “kill” etc. which could affect the entire execution flow. In web applications, popen(), unlink(), execve() are commonly used functions which are sensitive operations which are vulnerable to command injection attacks. A simple policy to prevent this attack using taint analysis is “no commands should be tainted” and “no tainted strings should contain special characters (like ;)”. By identifying the untrusted input and security-sensitive operations by generic annotations on relevant functions, taint analysis helps in first secluding the command attacks from normal execution cycle. After that, the arguments are realized in fine level of granularity for runtime tracking of information to obtain a high degree of accuracy necessary for a proactive approach for attack prevention. This provides a stage for the creation of complex access policies for different data or variables. Taint tagging is done on the variables for easy creation and identification of “taintedness” in different part of the program. The byte level source-to-source transformation technique helps easier tracking of the untrusted data flow.
Other approaches or possible ideas Although TBFD is a hardware approach, it also concurrently checks for software errors. Particularly whenever there is an attack on the source code that is being executed on the core, by checking it on another core, the software vulnerability is ascertained when the error persists. This trace based method can be further improved by continuously taking periodic traces, thereby finding for software failures, and double checking them in case of an attack. It is interesting to note that whenever there are different parts of the application running in different nodes or processor core, (imagine a virtualized platform) certain variables pertaining the part of code running in one core might affect the variables executed in another core. Whenever, there is hardware vulnerability in either of these cores, they do not properly communicate the patching information among one another causing the variable to remain permanently tainted.
