The OpenSSL is an open source implementation of the Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) [7].The OpenSSL platform provides security when data is transferred from one point of the internet to another part [1]. The Secure socket layer (SSL) is the most popular protocol used on the Internet for secure transfer of data [4]. The OpenSSL protocol is used in two-thirds of all websites to prevent hackers from stealing sensitive information like passwords or credit card data [5]. If the data being transferred is edited/changed/ updated along the way, data integrity is compromised and if the data is accessed and falls into the wrong hands, confidentiality of data is lost. Data Integrity and confidentiality should be maintained as data moves from point to point. The OpenSSL protocol works by authenticating the server to the client and client to server through the use of digital certificates signed by a trusted third party. Private and public keys are also used in the OpenSSL to provide security. The OpenSSL protocol is however subject to vulnerabilities [2], [3] whether directly or indirectly. This can be seen by the trusted third parties who authenticate the identities of transacting individuals have been exposed to continuous attacks/threats. [6]. various other vulnerabilities have been found within the OpenSSL protocol and the most notable has been the Heartbleed bug.
The name ‘Heartbleed’ itself explains the vulnerability – ‘Heart’ of the Heartbleed came from Heartbeat protocol and ‘bleed’ stands for data leakage. That means data leakage in the Heartbeat protocol implementation, specifically the OpenSSL implementation of the protocol.
Naive Bayes is a kind of classifier which uses the Bayes Theorem. It predicts membership probabilities for each class such as the probability that given record or data point belongs to a particular class. The class with the highest probability is considered as the most likely class. This is also known as Maximum A Posteriori (MAP).
The MAP for a hypothesis is:
MAP(H) = max( P(H|E) )
= max( (P(E|H)*P(H))/P(E))
= max(P(E|H)*P(H))
P (E) is evidence probability, and it is used to normalize the result. It remains same so, removing it won’t affect.
Naive Bayes is a classification algorithm for binary (two-class) and multi-class classification problems. The technique is easiest to understand when described using binary or categorical input values [8].
Vulnerability, in information technology (IT), is a flaw in code or design that creates a potential point of security compromise for an endpoint or network.
Vulnerabilities create possible attack vectors, through which an intruder could run code or access a target system’s memory. The means by which vulnerabilities are exploited are varied and include code injection and buffer overruns; they may be conducted through hacking scripts, applications and free hand coding.
Vulnerabilities are constantly being researched and detected by the security industry, software companies, cybercriminals and other individuals. Some companies offer bug bounties for these discoveries. Nevertheless, when vulnerability disclosure is considered, the question of how much information to provide and when to make it public is a contentious issue.
Some people argue for full and immediate disclosure, including the specific information that could be used to exploit the vulnerability; others believe that vulnerability information should not be published at all because the information can be used by an intruder. A zero-day exploit, for example, takes place as soon as vulnerability becomes generally known. To mitigate risk, many experts believe that limited information should be made available to a selected group after some specified amount of time has elapsed since detection.
Both black hats and white hats regularly search for vulnerabilities and test exploits, however, and if a cybercriminal finds a useful and unreported security hole, he is likely to take advantage of it. Proponents of disclosure maintain that it leads to more patching of vulnerabilities and more secure software [2].
Most software security vulnerabilities fall into one of a small set of categories:
1.4.1 Buffer Overflows
A buffer overflow occurs when an application attempts to write data past the end (or, occasionally, past the beginning) of a buffer.
Buffer overflows can cause applications to crash, can compromise data, and can provide an attack vector for further privilege escalation to compromise the system on which the application is running.
Books on software security invariably mention buffer overflows as a major source of vulnerabilities. Exact numbers are hard to come by, but as an indication, approximately 20% of the published exploits reported by the United States Computer Emergency Readiness Team (US-CERT) for 2004 involved buffer overflows.
Any application or system software that takes input from the user, from a file, or from the network has to store that input, at least temporarily. Except in special cases, most application memory is stored in one of two places:
Class instances, data allocated with malloc, core foundation objects, and most other application data resides on the heap. (Note, however, that the local variables that actually point to the data are stored in the stack.)
Buffer overflow attacks generally occur by compromising the stack, the heap, or both [1].
1.4.2 Unvalidated Input
As a general rule, we should check all input received by our program to make sure that the data is reasonable.
For example, a graphics file can reasonably contain an image that is 200 by 300 pixels, but cannot reasonably contain an image that is 200 by -1 pixel. Nothing prevents a file from claiming to contain such an image, however (apart from convention and common sense). A naive program attempting to read such a file would attempt to allocate a buffer of an incorrect size, leading to the potential for a heap overflow attack or other problem. For this reason, we must check our input data carefully. This process is commonly known as input validation or sanity checking.
Any input received by our program from an untrusted source is a potential target for attack. (In this context, an ordinary user is an untrusted source.) Examples of input from an untrusted source include (but are not restricted to):
Hackers look at every source of input to the program and attempt to pass in malformed data of every type they can imagine. If the program crashes or otherwise misbehaves, the hacker then tries to find a way to exploit the problem. Unvalidated-input exploits have been used to take control of operating systems, steal data, corrupt users’ disks, and more. One such exploit was even used to “jail break” iPhones [1].
Validating Input and Inter-process Communication describes common types of input-validation vulnerabilities and what to do about them.
1.4.3 Race Conditions
A race condition exists when changes to the order of two or more events can cause a change in behavior. If the correct order of execution is required for the proper functioning of the program, this is a bug. If an attacker can take advantage of the situation to insert malicious code, change a filename, or otherwise interfere with the normal operation of the program, the race condition is security vulnerability. Attackers can sometimes take advantage of small time gaps in the processing of code to interfere with the sequence of operations, which they then exploit [2].
1.4.4 Inter-process Communication
Separate processes—either within a single program or in two different programs—sometimes have to share information. Common methods include using shared memory or using some messaging protocol, such as Sockets, provided by the operating system. These messaging protocols used for inter-process communication are often vulnerable to attack; thus, when writing an application, we must always assume that the process at the other end of our communication channel could be hostile.
1.4.5 Insecure File Operations
In addition to time-of-check–time-of-use problems, many other file operations are insecure. Programmers often make assumptions about the ownership, location, or attributes of a file that might not be true. For example, we might assume that we can always write to a file created by our program. However, if an attacker can change the permissions or flags on that file after we create it, and if we fail to check the result code after a write operation, we will not detect the fact that the file has been tampered with.
Examples of insecure file operations include:
1.4.6 Access Control Problems
Access control is the process of controlling who is allowed to do what. This ranges from controlling physical access to a computer— keeping our servers in a locked room, for example—to specifying who has access to a resource (a file, for example) and what they are allowed to do with that resource (such as read only). Some access control mechanisms are enforced by the operating system, some by the individual application or server, some by a service (such as a networking protocol) in use. Many security vulnerabilities are created by the careless or improper use of access controls, or by the failure to use them at all.
Much of the discussion of security vulnerabilities in the software security literature is in terms of privileges, and many exploits involve an attacker somehow gaining more privileges than they should have. Privileges, also called permissions, are access rights granted by the operating system, controlling who is allowed to read and write files, directories, and attributes of files and directories (such as the permissions for a file), who can execute a program, and who can perform other restricted operations such as accessing hardware devices and making changes to the network configuration.
Of particular interest to attackers is the gaining of root privileges, which refers to having the unrestricted permission to perform any operation on the system. An application running with root privileges can access everything and change anything. Many security vulnerabilities involve programming errors that allow an attacker to obtain root privileges. Some such exploits involve taking advantage of buffer overflows or race conditions, which in some special circumstances allow an attacker to escalate their privileges. Others involve having access to system files that should be restricted or finding a weakness in a program—such as an application installer—that is already running with root privileges. For this reason, it’s important to always run programs with as few privileges as possible. Similarly, when it is necessary to run a program with elevated privileges, we should do so for as short a time as possible [2].
Much access control is enforced by applications, which can require a user to authenticate before granting authorization to perform an operation. Authentication can involve requesting a user name and password, the use of a smart card, a biometric scan, or some other method. If an application calls the OS X Authorization Services application interface to authenticate a user, it can automatically take advantage of whichever authentication method is available on the user’s system. Writing our own authentication code is a less secure alternative, as it might afford an attacker the opportunity to take advantage of bugs in our code to bypass our authentication mechanism, or it might offer a less secure authentication method than the standard one used on the system.
Digital certificates are commonly used—especially over the Internet and with email—to authenticate users and servers, to encrypt communications, and to digitally sign data to ensure that it has not been corrupted and was truly created by the entity that the user believes to have created it. Incorrect or careless use of digital certificates can lead to security vulnerabilities. For example, a server administration program shipped with a standard self-signed certificate, with the intention that the system administrator would replace it with a unique certificate. However, many system administrators failed to take this step, with the result that an attacker could decrypt communication with the server. [CVE-2004-0927]
It’s worth noting that nearly all access controls can be overcome by an attacker who has physical access to a machine and plenty of time. For example, no matter what you set a file’s permissions to, the operating system cannot prevent someone from bypassing the operating system and reading the data directly off the disk. Only restricting access to the machine itself and the use of robust encryption techniques can protect data from being read or corrupted under all circumstances.
1.4.7 Secure Storage and Encryption
Encryption can be used to protect a user’s secrets from others, either during data transmission or when the data is stored. OS X provides a variety of encryption-based security options, such as
The list of security options in iOS includes
Each service has appropriate uses, and each has limitations. For example, FileVault, which encrypts the contents of a user’s root volume (in OS X v10.7 and later) or home directory (in earlier versions), is a very important security feature for shared computers or computers to which attackers might gain physical access, such as laptops. However, it is not very helpful for computers that are physically secure but that might be attacked over the network while in use, because in that case the home directory is in an unencrypted state and the threat is from insecure networks or shared files. Also, FileVault is only as secure as the password chosen by the user—if the user selects an easily guessed password, or writes it down in an easily found location, the encryption is useless.
It is a serious mistake to try to create our own encryption method or to implement a published encryption algorithm ourselves unless we are already an expert in the field. It is extremely difficult to write secure, robust encryption code that generates unbreakable cipher-text, and it is almost always a security vulnerability to try. For OS X, if we need cryptographic services beyond those provided by the OS X user interface and high-level programming interfaces, we can use the open-source CSSM Cryptographic Services Manager. For iOS, the development APIs should provide all the services we need.
1.4.8 Social Engineering
Often the weakest link in the chain of security features protecting a user’s data and software is the user himself. As developers eliminate buffer overflows, race conditions, and other security vulnerabilities, attackers increasingly concentrate on fooling users into executing malicious code or handing over passwords, credit-card numbers, and other private information. Tricking a user into giving up secrets or into giving access to a computer to an attacker is known as social engineering.
For example, in February of 2005, a large firm that maintains credit information, Social Security numbers, and other personal information on virtually all U.S. citizens revealed that they had divulged information on at least 150,000 people to scam artists who had posed as legitimate businessmen. According to Gartner (http://www.gartner.com), phishing attacks cost U.S. banks and credit card companies about $1.2 billion in 2003, and this number is increasing. They estimate that between May 2004 and May 2005, approximately 1.2 million computer users in the United States suffered losses caused by phishing [2].
Software developers can counter such attacks in two ways: through educating their users and through clear and well-designed user interfaces that give users the information they need to make informed decisions [1].