Sheffield Hallam University

Sheffield Hallam University

Module Code and Title: Systems Application Security

Assignment Title:	Buffer Overflow and NIDPS
Assessment Tutor:	Dr David Day
Student name:	Evgeny Danshin
Weighting Towards Module Grade:	50%
Word Limit:	3000 Words
Date Set:	29-10-12
Hand In Date:	6-1-2012

TABLE OF CONTENT

Abstract............................................................................................................................................3

1 Introduction...................................................................................................................................4

2 Buffer overflow protection techniques.........................................................................................5

2.1 Data Execution Prevention (DEP).................................................................................5

2.2 Canaries (Canary words)................................................................................................6

2.3 Address Space Layout Randomization (ASLR)............................................................8

3 Intrusion detection and prevention systems (IDS/IPS).................................................................9

3.1 Signature-based IDS/IPS................................................................................................9

3.2 Anomaly-based IDS/IPS..............................................................................................10

4 Novel approach in buffer overflow detection.............................................................................11

5 Summary.....................................................................................................................................12

ABSTRACT

A poorly designed [1] software or hardware's program source code can contain a small inappropriate placed character or multiple characters that are improperly processed and as a result it can lead to buffer overflow attacks. Buffer overflow vulnerabilities might be found in local programs, operation system applications, services, remote software such as DNS, FTP, E-mail and Web servers. These buffer overflow vulnerabilities allow for the implementation of a various range of attacks and they can the cause for some of the most serious damages in a company's network.

This work presents a few techniques to protect systems and applications against buffer overflow attacks and these techniques do not require modifications of source code. Buffer overflow protection methods and IDS/IPS demonstrate an advanced approach in prevention and avoidance of buffer overflow and worm propagation attacks.

Keywords: buffer overflow attacks, randomization, worm propagation, intrusion detection and prevention systems, malicious code, stack, heap.

1 Introduction

Historically, buffer overflow is the most common vulnerability used by malicious software to infect; compromise and destroy a system or an application. Worms which may be a part of a malicious code are the most "active users" of buffer overflow vulnerabilities than viruses. By using buffer overflow a worm can replicate and spread itself through a network thus infecting more hardware recipients. Buffer overflow vulnerabilities created by worm propagation may allow an attacker to take control over a system, crash an application, escalate privileges, create a "backdoor" and etc. Moreover, if a worm can infect one PC using the heap or buffer overflow, X thousand PCs can be infected and damaged - if they have the same features, software or security configurations [2].

In contrast to the Morris worm that had an aim to define how big the Internet is, modern worms have a various range of goals. In general, a worm's goal relies on the attacker's aims and it can have unpredictable results and effects. For example, worms can create bot-nets to spread spam or implement the dDoS attacks, steal an account's details or login credentials, gain an authorized access, take control over industrial or SCADA systems (e.g. Stuxnet, Duqu). Considering what was stated above we can clearly see that absolutely all systems and applications need to be protected against buffer overflow attacks and worm propagation. It is not surprisingly that software developers [3] are constantly introducing mechanisms which allow for avoiding and preventing buffer overflow attacks. Some advanced techniques, for instance - Program Shepherding [4], Canaries, Data Execution Prevention and Address Space Layout Randomization - can protect system's stack and prevent code injection attacks, format string execution and, additionally, attacks that use vulnerabilities in the heap structure management.

In spite of the fact that software developers patch any vulnerabilities found in their products and the use of stack overflow mechanisms, buffer overflow attacks are still used to a high degree (Figure 1) [5].

Figure 1: Buffer overflow tendency in accordance with NIST database

Moreover, today's stack overflow vulnerabilities tend to have a "zero-day" character and it becomes increasingly difficult to protect a system against such vulnerabilities, for this reason, it is necessary to apply an additional mechanism for detecting and preventing buffer overflow attacks and worm propagation. Such mechanisms might be antivirus programs, firewalls, host or network -based intrusion detection (and/or prevention) systems.

2 Buffer overflow protection techniques

Buffer overflow attacks may be used to overwrite data in memory in order to provoke direct changes in execution flow process in accordance with attacker's goals [6]. However, modern buffer protection mechanisms allow for prevention and avoidance of such attacks. DEP, ASLR and Canaries are the modern buffer protection approaches which will be considered below.

2.1 Data Execution Prevention (DEP)

DEP is a security feature integrated into Microsoft Windows operation systems (e.g. - XP SP2, Vista, Windows 7 and Windows Server 2003), Linux and MAC OS. In Microsoft Windows, DEP is a default option set only to protect its OS applications and services. On the other hand, DEP is a set of hardware and software technologies that perform an additional check on the memory and prevent malicious code from executing in memory data pages. Specifically, DEP can block the spreading of malware programs trying to execute its code in regions of the system memory which are reserved for authorized programs (e.g. - legitimate system applications and services). Additionally, DEP prevents code from executing in the heap, stack and memory pools. Furthermore, DEP does not allow the execution of programs that take advantage of exception-handling mechanisms (especially in Windows OS).

By detecting that a program uses the system memory incorrectly [7] or attempts to execute some code from a protected data page, DEP initiates a memory access violation and if this exception can not to be processed - terminates the calling of a process, making an enforced closure of a program and displays an "alert" message.

Technically, execution of injected code into stack, heap or protected memory pages generates an exception. If an application needs to start executing a code from a protected memory page, the application gets an exception "STATUS_ACCESS_VIOLATION" which is generated by DEP. Initially, if an application must execute a code from non-executable memory page, the correct set of virtual memory attributes must be set up and allocated for secure code executing. Some examples of these attributes [8] are PAGE_EXECUTION, PAGE_EXECUTE_READ and PAGE_EXECUTE_WRITEREAD. More commonly, DEP is configured in accordance with the no-execute memory page protection policy's settings in the boot configuration data (system boot).

An application can obtain the policy's settings [7] by calling GetSystemDEPPolicy function and by relying on these settings the application is able to modify the current DEP attributes for the current process by calling SetProcessDEPPolicy function which possibly creates a disadvantage of DEP's approach.

As mentioned, DEP has two realization approaches: software enforced DEP and hardware enforced DEP. Software enforced DEP must be supported by operation systems and protects only user-mode processes. Hardware enforced DEP provides a set of instructions to the CPU to make some certain memory pages non-executable. Technically, hardware enforces DEP specifies a bit in the page table entry that points the system to prevent code from being run from a virtual memory page that must contain only non-executable data.

2.2 Canaries (Canary words)

Canary words were initially implemented in StackGuard [9]. StackGuard is a compiler extension that enhances an executable code processed by the compiler (also used in ProPolice and Microsoft VisualStudio.NET). Canaries address space protection mechanism is used against buffer overflows which attempt to overwrite the return address [10]. A canary is placed as a metadata value (4 bytes) between the program and the control data on a stack to monitor and prevent the buffer overflow. The main purpose of Canary words is to protect the return address against overwriting.

Canary in its mechanism uses two functions called "epilogue" and "prologue" [11]. The function "prologue" introduces a canary word value onto the stack before the return address (Figure 2). Commonly, exploitation of stack buffer overflow includes overwriting the return address; if canary words are implemented-the value of the canary will be overwritten instead of the actual return address. The second function "epilogue" monitors the changes in the canary value and if the canary is changed or can not to be matched (before the return from the function which has been executed) - the program or process is forcibly terminated [12].

Figure 2: Canary words approach

There are a few general types of canaries which are used to stop stack overwriting:

1. "Terminator" canaries - can terminate execution of vulnerable functions (e.g.-strcpy(), getc());

2. Random Canaries - randomly generated (by entropy-gathering deamon) to prevent an attacker from obtaining its values. Generated at the program initialization, these values are kept in global variables. An attempt to read these values by using any kind of method prompts a segmentation fault which terminates the program or process. On the other hand, it has a serious vulnerability: an attacker may be able to obtain the current random canary value via exploiting the victim program [9];

3. Random XOR Canary - by expecting that an exploit may be able to gain a random write access to the location of protected data; some or all saved control data can be encrypted (XORed) with a random canary value. The resulting value is kept in the canary's location. This approach has the same vulnerability as Random Canaries have.

Despite the fact that Canary words can prevent the overwriting the return address, this technique has some drawbacks. Some examples of these drawbacks are:

- Local variables and saved frame pointer are not secure;

- Program can be modified until the functions return;

- Heap can be overflowed;

- Format string exploits can be used;

-Generally, when a canary modification is detected, the program is terminated that fact creates a DoS attack opportunity.

2.3 Address Space Layout Randomization (ASLR)

It was initially integrated in PaX kernel patch for Linux OS (in 2001) and then formally introduced in Windows Vista, Windows 7 and Windows Server 2008 [13]. ASLR focuses on stack smashing types of buffer overflow attacks. The main function of ASLR is to add a certain amount of randomness into the layout of virtual memory space. It makes an attacking process more difficult as long as memory address keeps altering [14]. By randomizing the location allocated to the stack, heap, loaded *.dll files and executable binaries, ASLR decreases the probability that an exploit (usually relies on hardcoded addresses) will redirect a code execution. Obviously it creates a limitation; all executable binaries must be recompiled and relocated. ASLR can successfully protect stack against the return-to-LIBC and code injection attacks. The following addresses can be randomized:

- Executable images (1 of 255 random positions);

- DLL images (in the first 1of 256 positions of ntdll.dll, the other DLLs loaded after);

- Stack (has more positions than other sections);

- Heap (heap structure is located in 1 of 32 random positions);

- Process Environment Block (PEB) and Thread Environment Block (TEB).

ASLR can be applied to a system (for instance, in Windows OS it protects its processes only) and for those applications which optionally use the DYNAMICBASE linker flag. Linux kernel patch PaX uses more advanced ASLR techniques. It contains four main ASLR's components [12]:

1. RANDKSTACK - to introduce randomness into a task's kernel stack.

2. RANDMMAP - processes the randomization of all files and memory mappings.

3. RANDUSTACK - to randomize stack addresses.

4. RANDEXEC - to randomize the locations of ETC_EXEC ELF binaries.

Nowadays, ASLR is the most advanced technique designed to protect the stack against overflow attacks which are used through worm propagation etc. However, the ASLR approach has some disadvantages, for example:

- Return-to-Code attack is still possible to implement;

- Due to fact that Windows OS have the size memory page limitation (64 Kb), some memory sections can have less entropy after the randomization - this fact can be exploited through the use of a brute force attack;

- Some binaries cannot be recompiled (it is not provided by most distributions);

- ''Forked'' process uses the same layout as the main process (in case of object-oriented programming).

3 Intrusion detection and prevention systems (IDS/IPS)

Intrusion detection/prevention is the process of monitoring and defining unauthorized access attempts. IDS/IPS systems are advanced mechanisms of "in-depth" protection allowing for the detection and prevention of potentially dangerous "events" [15]. Some examples of these events" are:

- Buffer overflow;

- Executing of a malicious code (worms, viruses);

- Worm propagation;

- Illegal data control;

- Exploitation of a programs vulnerabilities.

IDS/IPS can be implemented in two approaches host and network-based IDS/IPS. Additionally, these approaches have two realizations which are signature and anomaly-based IDS/IPS which will be considered below.

3.1 Signature-based IDS/IPS

Signature-based IDS/IPS is the most accurate technique to detect well-known attacks. Representations of intrusions and attacks are stored as signatures and then are compared to the system activity in order to detect and prevent "abnormal" activity. Signature-based analysis is similar to the analysis that an antivirus program may provide which allows the detection of malicious content in the packet payload.

Signatures are a specific set of rules or a sequence of bytes derived from each particular attack's pattern. A signature can contain a malicious code pattern, commands to open shell command line or a malicious combination that is used for buffer overflow attacks [15].

This type of IPS/IDS has the following benefits:

- provide the full information about an attack as a result can stop it correctly;

- detect malicious content, shortcut combinations in the network packets;

- stop and prevent dDoS and inside/outside attacks;

- detect access to files and objects;

- provide a connection control;

- control e-mail, IM content;

- Less false positives;

- Specific checks can be implemented (in accordance with signatures);

Despite the advantages, the signature-based approach has the following set of disadvantages:

- Can not to detect zero-day and stealth attacks;

- Signatures must be created for each attack (impossible to use common features);

- can be blocked by network traffic or in different segments of network (if it is distributed);

- Vulnerable to "false" generation attacks;

- Initially, a lot of false positives/negatives;

- needs a lot of memory resources;

- Each attack pattern must be fully determined;

- 1 byte difference and an attack can not to be detected;

3.2 Anomaly-based IDS/IPS

The main point of anomy-based technique is to define baseline parameters for network behavior. During the operation, system defines the network behavior and any deviation from the baseline parameters if detected triggers and alarm. The main purpose of such analysis is to detect or provide an opportunity to detect the wide range of attacks that have no-predefined attributes (signatures) [15]. Anomaly-based IDS have no dependence on knowledge about vulnerabilities in a particular network environment which allows them to detect and prevent unknown attacks (e.g.- zero-days and stealth attacks). Anomaly detection is a static process which is based on the concept of determining the number of events that occur in a certain time period (based on size and traffic load of the network) for a particular behavior pattern of intrusion.

The anomaly-based approach has the following advantages allowing for the detection and prevention of:

- Zero-days attacks;

- Abnormal user activity (internal anomaly detection);

- Escalation and unauthorized access attacks;

- Intrusion in any type of networks (has no dependence on network size).

However, this approach is not without drawbacks such as:

- creates a lot of "false" positives;

- Do not provide the fully described information about an attack (only deviations from predefined parameters);

- can be easily compromised by human side situations (no self-defence);

- Vulnerable in case of direct attacks;

- Extremely difficult to adopt if network environment changes fast.

4. A novel approach in buffer overflow detection

Considering the fact that IPS/IDS systems are able to detect and prevent buffer overflow attacks and worm propagation, an additional module can be integrated into host-based IDS/IPS systems. Based on Sandbox approach such mechanism can provide an extra check of data before these data are being executed in the stack. It means that data can get the access to execute only after executing in the stack's "sandbox". In accordance with Figure 3, data that successfully passed check-execution in Stack Pre-Processor can be secure executed in stack, otherwise it will generate a violation and program or process's data will be terminated as a malicious or suspicious content.

Figure 3: Stack Pre-Processor mechanism

By putting and executing data in Stack Pre-Processor, it possible to detect and prevent buffer overflow attacks, unauthorized systems and API callings, program entry pointers, execution unsafe function (e.g. - getc(), strncpy(), strcat() and etc.) and exploiting vulnerabilities in stack structure. In addition, this approach can provide a passive or active static analysis of ELF files that may contain exploits responsible for buffer overflow attacks. Finally, in accordance with defined rules or signatures, stack pre-processor process can block (stop, suspend, terminate) execution of data during initialization or boot process.

5. Summary

In spite of the fact that threads from malware (especially - worm propagation) are well known they still take place in any software or operation system. Attacks on such systems are still available for implementation because of any system's drawbacks. Buffer overflow attacks and exploits are the major category of possible ways to compromise a system and propagate a malicious code (viruses, worms). Despite the protection mechanisms against buffer overflow attacks which are integrated into the modern operating systems, a probability to find and exploit a zero-day vulnerability of buffer overflow is still extremely high. Modern techniques such as DEP, ASLR and Canaries used to prevent buffer overflow attacks, have a set of disadvantages allowing bypassing the prevention mechanism. It creates a necessity to use an additional approach to protect system's stack against overflowing. Some of them are found in the use of firewalls, IDS/IPS systems, network packet payload scanners, static or dynamic analysis for preventive protection of program's code and etc.

In the case of worm propagation, buffer overflow is still the most usable vulnerability that a worm can use to replicate, propagate itself and infect PCs via the network connection. Moreover, some protection mechanisms, for example - Canaries, can be exploited by worm to obtain stack address space for the further buffer overflowing.

It is the author's belief that modern techniques are morally-outdated and it is highly important to create new methods against buffer overflow attacks to stop spreading worms and malicious software. One such possibility is described above; an approach can be used and integrated into the real-time system after in-depth research and correct implementation.

Work cited:

[1] James C. Foster, Vitaly Osipov, Hish Bhalla, Neils Heinen. Buffer Overflow Attacks: Detect, Exploit, Prevent. s.l.: Syngpress, 2005.

[2] Ed Skoudis, Lenny Zeltser. Malware Fighting Malicious Code. s.l.: Prentice Hall, 2004.

[3] Osborn, Russ. Modern Buffer Overflow Prevention Techniques. 2006.

[4] USENIX Security Symposium. Kiriansky, Vladimir. s.l.: MIT Research paper, 2002. Secure Execution via Program Shepherding.

[5] 5th International Conference on Trust and Trustworthy Computing. Ahmad-Reza Sadeghi, Lucas Davi. Darmstadt (Germany): s.n., 2011. Runtime Attacks: Buffer overflow and Return-Orienting Programming.

[6] Szor, Peter. The art of Computer: Virus Research and Defence. s.l.: Symatec Press, 2005.

[7] MSDN. Data Execution Prevention. http://msdn.microsoft.com. [Online] 12 Feb 2011. [Cited: 9 12 2011.] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366553%28v=vs.85%29.aspx.

[8] MSDN. Memory Protection Constants. http://msdn.microsoft.com. [Online] 12 Feb 2011. [Cited: 12 9 2011.] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786%28v=vs.85%29.aspx.

[9] GCC Developers Summit. Perry Wagle, Crispin Cowan. 2003. StackGuard: Simple Stack Smash Protection for GCC. pp. 243-256.

[10] 09 IEEE International Conference on Electro/Information Technology. Sirisara Chiamwongpaet, Krerk Piromsopa. 2009. Implementing of Secure Canary Word for Buffer Overflow Protection. pp. 56-61.

[11] Secologic Meeting. Johns, Martin. Hamburg: s.n., 2005. Preventing Buffer overflows: An Overview of Scientific Approaches.

[12] Software Security Conference. Yuklyanyuk, Igor. January 2008. Stack Based Overflows and Protection Mechanisms.

[13] Wikipedia. Address space layout randomization. http://en.wikipedia.org. [Online] 6 Dec 2011. [Cited: 12 Dec 2011.] http://en.wikipedia.org/wiki/Address_space_layout_randomization.

[14] Allen Harper, Jonathan Ness, Gideon Lenkey. Grey Hat Hacking. The Ethical Hacker's handbook. Third Edition. s.l.: McGraw-Hill, 2011.

[15] Roberta Braqq, Mark Rhodes-Ousley, Keith Strassberg. Network Security: The complete Reference. s.l.: Osborne, 2006.

[16] Collman, Dieter. Computer Security. Third Edition. s.l.: WILEY, 2011.

Bibliography:

1. James C. Foster, Vitaly Osipov, Hish Bhalla, Neils Heinen. Buffer Overflow Attacks: Detect, Exploit, Prevent. s.l.: Syngpress, 2005.

2. Ed Skoudis, Lenny Zeltser. Malware Fighting Malicious Code. s.l.: Prentice Hall, 2004.

3. Michal Chmielewski, Neill Clift, Sergiusz Fonrobert, Tomasz Ostwald. Find and Fix Vulnerabilities Before Your Application Ships. http://msdn.microsoft.com. [Online] 2007. [Cited: 6 12 2011.] http://msdn.microsoft.com/en-us/magazine/cc163312.aspx.

4. Osborn, Russ. Modern Buffer Overflow Prevention Techniques. 2006.

5. Grover, Sandeep. Buffer Overflow Attacks and Their Countermeasures. http://www.linuxjournal.com. [Online] 14 March 2003. [Cited: 5 12 2011.] http://www.linuxjournal.com/article/6701.

6. Szor, Peter. The art of Computer: Virus Research and Defence. s.l.: Symatec Press, 2005.

7. Allen Harper, Jonathan Ness, Gideon Lenkey. Grey Hat Hacking. The Ethical Hacker's handbook. Third Edition. s.l.: McGraw-Hill, 2011.

8. Application Security 101: Buffer Overflows. Martin, Luther. 2006, ISSA: The Global Voice of Information Security.

9. 5th International Conference on Trust and Trustworthy Computing. Ahmad-Reza Sadeghi, Lucas Davi. Darmstadt (Germany): s.n., 2011. Runtime Attacks: Buffer overflow and Return-Orienting Programming.

10. Secologic Meeting. Johns, Martin. Hamburg: s.n., 2005. Preventing Buffer overflows: An Overview of Scientific Approaches.

11. MSDN. Data Execution Prevention. http://msdn.microsoft.com. [Online] 12 Feb 2011. [Cited: 9 12 2011.] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366553%28v=vs.85%29.aspx.

12. MSDN. Memory Protection Constants. http://msdn.microsoft.com. [Online] 12 Feb 2011. [Cited: 12 9 2011.] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786%28v=vs.85%29.aspx.

13. Wikipedia. Page table. http://en.wikipedia.org. [Online] 17 Nov 2011. [Cited: 9 Dec 2011.] http://en.wikipedia.org/wiki/Page_table.

14. Wikipedia. Source lines of code. http://en.wikipedia.org. [Online] 7 12 2011. [Cited: 8 12 2011.] http://en.wikipedia.org/wiki/Source_lines_of_code.

15. 09 IEEE International Conference on Electro/Information Technology. Sirisara Chiamwongpaet, Krerk Piromsopa. 2009. Implementing of Secure Canary Word for Buffer Overflow Protection. pp. 56-61.

16. Wikipedia. Buffer overflow protection. http://en.wikipedia.org. [Online] 28 Apr 2011. [Cited: 9 Dec 2011.] http://en.wikipedia.org/wiki/Buffer_overflow_protection.

17. Software Security Conference. Yuklyanyuk, Igor. January 2008. Stack Based Overflows and Protection Mechanisms.

18. Wikipedia. Stack buffer overflow. http://en.wikipedia.org. [Online] 18 Nov 2011. [Cited: 9 Dec 2011.] http://en.wikipedia.org/wiki/Stack_buffer_overflow.

19. GCC Developers Summit. Perry Wagle, Crispin Cowan. 2003. StackGuard: Simple Stack Smash Protection for GCC. pp. 243-256.

20. USENIX Security Symposium. Kiriansky, Vladimir. s.l.: MIT Research paper, 2002. Secure Execution via Program Shepherding.

21. 7th USENIX Security Symposium. Crispan Cowan, Calton Pu et al. San Antonio, Texas: s.n., January 26-29, 1998. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks.

22. 21st IEEE International Symposium on Software Reliability Engineering. Vivek Iyer, Amit Kanitkar et al. 2010. Preventing Overflow Attacks by Memeory Randomization.

23. Blackhat and DEFCON conference. Peter Siberman, Richard Johnson. 2004. A comparison of Buffer Overflow Prevention Implementations and Weaknesses.

24. Buffer Overflow attack - Vulnerability in Stack. P. Vadivel Murugan, Dr. K. Alagarsamy. Jan, 2011, International Journal of Computer Applications.

25. Wikipedia. Address space layout randomization. http://en.wikipedia.org. [Online] 6 Dec 2011. [Cited: 12 Dec 2011.] http://en.wikipedia.org/wiki/Address_space_layout_randomization.

26. Roberta Braqq, Mark Rhodes-Ousley, Keith Strassberg. Network Security: The complete Reference. s.l.: Osborne, 2006.

27. Michael Rush, Angela Orebough, Grahman Clark. Intrusion detection and Active response: Deploying Network and Host IPS. s.l.: Syngress, 2005.

28. Rehman, Raffeeq Ur. Intrusion Detection Systems with Snort. Advanced IDS techniques using Snort, Apache, MySQL, PHP. 2003.

29. Earl Carter, Jonathan Hogue. Intrusion Prevention: Signatures and Actions. http://www.ciscopress.com. [Online] 26 May 2006. [Cited: 10 Dec 2011.] http://www.ciscopress.com/articles/article.asp?p=471095.

30. Paquet, Catherine. Network Security Using Cisco IOS IPS. http://www.ciscopress.com. [Online] 8 Jun 2009. [Cited: 10 Dec 2011.] http://www.ciscopress.com/articles/article.asp?p=1336425&seqNum=5.

31. NIST. National Vulnerability Database. http://nvd.nist.gov/. [Online] 2011. http://nvd.nist.gov/.

32. Collman, Dieter. Computer Security. Third Edition. s.l.: WILEY, 2011.

33. An Overview of Anomoly Detection Techniques: Existing Solutions and Latest Technological Trends. Jung-Min Park, Animesh Patcha. 2007, Computer Networks.

34. Theodoro Garcia, et al. Anomaly-based network intrusion detection: Techniques, systems and challenges. s.l.: ELSEVIER, 2008.

35. James Cannady, Jay Harrel. A Comparative analysis of curent Intrusion Detection Technologies. Atlanta, Georgia Institute of Technologie.: s.n., 2001.

36. Wikipedia. Sandbox (computer security). http://en.wikipedia.org. [Online] 10 Dec 2011. [Cited: 10 Dec 2011.] http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29.

Дата добавления: 2015-11-04