Code Audit Report - Ut

Transcription

Code Audit ReportMuhammad UzairMay 25, 2017AbstractMany applications are being used by individuals and businesses thesedays. Also, these applications becoming a part of daily life. These applications use personal information and sometimes very important businesstransaction information. The security of that information is a very important issue. To make the information secure enough, it is required thatthe application is working as it should be. Code audit/review is done inthis regard. If there are any flaws, weaknesses, threats or any kind ofvulnerabilities found in the code, then actions are taken accordingly andfixes are applied. Some code audits examples are presented in this reportand then the code audit report of DigiDoc is presented, which is a moduleof Open-EID.1IntroductionSecurity of the applications being used is a major concern nowadays. Applications have become a very common part of our daily life. These applications arebeing used for business and for personal use. Personal data, internal organizational data is managed by these applications so it is critical and essential toprotect this data. There are many challenges when we talk about the protectionof this important data and the security of these applications. Also the exposureto internet has made these applications a prime target for the information theycontain. There are many advantages of Free and Open-Source Software (FOSS).One of them is that their source code is available which enables anyone to checkthe code and fix bugs, anyone can add new features and it is also importantfrom security point of that anyone can check the security of the code and makeit better. The free availability of the code also enables the organizations tofind any vulnerabilities in the code and allow them to refine the security whichresults into a safer user experience and also make the applications secure.2BackgroundHere are some of the code audits done by the EU-FOSSA (Free and Open-SourceSoftware Auditing). FOSSA focuses on the security aspects of the software.Following code audits are included in this report:1

Apache Core & APR (Apache Portable Runtime) KeePass Password SafeThe details of the code analysis are below:2.1Apache Core & APR Code ReviewApache HTTP server is one of the widely used HTTP and proxy server and itis a FOSS (Free and Open Source Software) [3]. It has become mature becausemany security flaws have been detected and corrected since it started runningin 1995. The objective of the code review was to examine the Apache Core &APR and the main focus was on security aspects.2.1.1ScopeApplication NameCode Reviewer ownerReview StartReview EndObjectiveNumber of LinesCode Review ModeApache Core & APREuropean Commission – Directorate-Generalfor Informatics (DIGIT)25/07/201622/08/2016Security Code Review61286 Managed Defined OptimizedLibraries Apache Core Apache Portable RuntimeExtensionsServices RequiredN/AN/ATable 1: Scope of Apache Core & APR2.1.2Executive SummaryThe Apache server is composed of many components. This code review onlyfocused on the core of Apache server and did not include any external moduleor extension.2

The reviewed modules are Apache HTTP core and the Apache Portable Runtime. The total number of reviewed lines were 61286 which makes nearly 20%of the total lines of Apache server. When doing code review, the Linux andWindows were considered because they are the most widely used operating systems. Talking about the code review, there were many findings discovered andall of those findings were within the Secure Code Design and Specific C controlscategories.Only 7 out of 160 controls had at least one finding detected in them which is alow percentage overall. Following is the summary of the findings and their risklevel:Risk LevelCriticalHighMediumLowInfoFinding00025Table 2: Summary of findings in Apache Core & APRIt is obvious that there were no critical or even medium or high risks. Thefindings were classified as low or informative, but they still should be fixed.2.1.3MethodologyThe methodology was consisting of four phases and each phase had 3 furtheractivities. Following are the phases and their activities:1. PlanningThe first phase is all about gathering the required information which canbe useful for code review. It includes the basic information about codereview, applicable test cases and the preparation of test environments ifthere is any need. Preparation – information is gathered to define the scope for the codereview. Test Design – test cases are defined once the scope is defined in orderto achieve the objectives. Environment Preparation – before starting the next phase, it is madesure that the environment is ready for conducting the test cases.2. ExecutionIn this phase, the test cases are executed which were selected in the previous phase. The execution was divided into three parts. Each part providedata as input for the other part.3

Managed Mode – this phase uses the automated tools for the executionof test cases. Following categories were analyzed: Data/Input Management (DIM)Authentication Controls (AUT)Session Management (SMG)Authorization Management (ATS)Cryptography (CPT)Error Handling/Information Leakage (EHI)Software communication (COM)Logging/Auditing (LOG)Secure Code DesignAll of the above mentioned categories have further sub-categories butthose are not important to mention here. Defined Mode – the results are gathered from automated tools andcompared with manual tests results for final results. Optimized Mode – in this section the riskiest parts are evaluated. Theyare divided into following sub-categories: Concurrency (CCR)Denial of Service (DOS)Memory and resource management (MRM)Code Structure (COS)Role-privilege matrix (RPM)There were also language specific controls in the optimized mode asfollows: Pre-Processor (PRE)Variable Management (VMG)Memory Management (MEM)File I/O Management (FIO)Environment (ENV)Signal and Error Handling (SEH)Concurrency (CON)Miscellaneous (MSC)3. AssessmentThe risk analysis of the findings from the previous steps was done in thisphase. The score was calculated on the basis of threat and vulnerabilitylevel of the findings.Following are the scores that were assigned to the findings:The findings were marked as Low, Medium or High based on their averagenumeric results.Following are the sub-categories of assessment phase:4

Numerical Value0 to 34 to 67 to 9ImpactLowMediumHighTable 3: Assessment of findings Technical Report Impact Analysis Finding Prioritization4. Reporting Report Report Dissemination Post-auditThe controls were divided into two main groups:1. Common controls – these controls are applicable regardless of the languageof the code.2. Language specific controls – for C, C , JAVA or PHP.The combination of both groups should be used for accurate results.2.1.4Detailed ResultsThere were findings in 7 controls. Following are those controls: Secure Code design– Framework Requirement: SCD-FWK-001 (info) Specific C Controls– Variable Management: CBC-VMG-004 (info), CBC-VMG-011 (info)– Memory Management: CBC-MEM-001 (low), CBC-MEM-005 (info)– File I/O Management: CBC-FIO-001 (low)– Signal and Error Handling: CBC-SHE-007 (info)There were evidences provided for every control and the recommendations toovercome that risk.5

2.1.5ConclusionMost of the findings were language-specific. It is because the reviewed part didnot include as many functionalities as other parts of the Apache server. Themain focus was on the APR as it is very important from the security point ofview.The final conclusion stated that both Apache Core & APR have a good levelfrom a security point of view. There were only few controls with findings andthose were not of high severity. Also those findings cannot be considered asdirectly security flaws because security is a set of layers and therefore severalrisky findings are necessary to compromise the software.2.2KeePass Code ReviewKeePass is a free and open source software tool that helps to manage passwordsin a secure way [4].The passwords can be stored in one database which is locked with one masterkey or a key file. So only one password or key file is required to unlock thedatabase.AES and Twofish encryption algorithms are used to encrypt the databases.2.2.1ScopeApplication NameCode Reviewer ownerReview StartReview EndObjectiveNumber of LinesCode Review ModeKeePass Password SafeEuropean Commission – Directorate-Generalfor Informatics (DIGIT)24/08/201623/09/2016Security Code Review84622 Managed Defined OptimizedLibrariesExtensionsServices RequiredMFC v 9.0 (It was not in the scope of codereview because it is not open source)N/AN/ATable 4: Scope of KeePass Password Safe6

2.2.2Executive SummaryThere were 84622 lines to be reviewed. To speed up the process, the totalwas divided into 33 sub-sections and it was handed over to the review team.Following are the categories in which the team discovered findings: Error Handling/Information Leakage Logging/Auditing Secure Code Design Specific C Controls Specific C Controls2.2.3MethodologyThe same methodology was adopted for KeePass as it was used for the codereview of Apache Core & APR.2.2.4AssessmentThe same assessment method was adopted for KeePass as it was used for thecode review of Apache Core & APR.2.2.5Detailed ResultsThere were 14 controls with findings. Following are those categories and subcategories with findings: Error Handling/Information Leakage– Error Handling (1 info) Logging/Auditing– Log Configuration Management (1 info) Secure Code Design– Framework Requirements (1 low)– Variable types/operations (1 low) Specific C Controls– Variable Management (1 medium, 1 low)– Memory management (1 medium)– Environment (1 medium)– Miscellaneous (1 medium)7

Specific C Controls– Variable Management (2 info)– Object-Oriented Programming (2 info)– Miscellaneous (1 medium)2.2.6ConclusionAgain most of the findings were language specific. Main focus was on the encryption algorithm as it is critical section from the security point of view. GUIwas also considered for code review.The final conclusion states that the code has a good level from a security pointof view. There were no findings with critical or high risk in nature.2.3Effort and Cost EstimationThe following activities were conducted in order to estimate the code effort:Lines of Code Around 61000 in C Around 84000 in C Code Review Team 3 Members for C Code 4 Members for C CodeTime-lineNumber of ControlsFour Weeks 160 for C Language 218 for C LanguageTable 5: Effort and Cost EstimationThe above data resulted in: 145000 lines of code in total 28 reviewers per week 129.5 lines of code per reviewer per hour8

These examples are taken from the project named EU-FOSSA. It was initiatedby the European Parliament in October 2014. It started proper execution atthe end of 2015. The budget of the project was 1 million euros. The budgetwas increased for the year of 2016 and it was set to 1.9 million euros [8].This project was for one year and if we want to calculate the hourly cost forone code reviewer, then it would be as follows:Hourly Cost 1 Million/7 reviewers 160 hours per month 12 monthsHourly Cost 74.4 Euro2.4Tools used for Code Review1. CodeLite – CodeLite is an open source cross platform for developmentand it supports many popular languages like C, C and PHP etc [5].2. F lawf inder – it is an open source software to examine C/C sourcecode. It also reports the “flaws” in code if there are any [9].2.5Static Code AnalysisStatic code analysis is done to verify the quality, reliability and security of asoftware. Defects and security vulnerabilities can be identified which can compromise the security of the software. Some code analysis methods also enablesto diagnose run-time errors such as overflows, divide by zero, and illegally dereferenced pointers. Static code analysis can is a cost-effective approach becauseit eliminates the need to write test cases. It is also automated, which meansthat the analysis can be done even without executing the program[7].Basic static code analysis techniques include: Generating code quality metrics, such as counting the number of lines ofcode, determining comment density, and assessing code complexity[7] Verifying compliance with coding standards such as MISRA C R /C orJSF (Joint Strike Fighter Air Vehicle C )[7]There are also sophisticated techniques which combines the formal methodswith static code analysis.The combination of static code analysis and formal methods enables to: Detect software defects and security vulnerabilities[7] Comply with MISRA, CWE, CERT C, ISO/IEC 17961, and other standards and cybersecurity guidelines[7] Prove the absence of certain run-time errors[7]9

Usually, the static code analysis tools find vulnerabilities at a high rate butit is not guaranteed that they will be able to find different kinds of securityflaws. So, these tools can be considered as aids for code/security analysts sothat they can find security flaws more efficiently.Some tools are built-in into the Integrated Development Environment (IDE).These tools can provide immediate feedback during the development cycle. Thisimmediate feedback is very useful as compared to finding vulnerabilities muchlater in the development cycle.2.5.1Strengths Scalability Some tools are very good at finding vulnerabilities like buffer overflow,SQL Injection, etc.2.5.2Weaknesses Many type of security vulnerabilities are very difficult to find automatically such as authentication problems, access control issues, insecure useof cryptography, etc. High numbers of false positives. Not very good at finding configuration issues. It is hard to prove that the found vulnerability is an actual security flaw.2.5.3Tools for Static code analysis1. Multi-language Axivion Bauhaus Suite - C, C , C#, and Java Cigital - Java, .NET, and PHP Codacy - Python, Ruby, PHP, Java, JavaScript

Code audit/review is done in this regard. If there are any aws, weaknesses, threats or any kind of vulnerabilities found in the code, then actions are taken accordingly and xes are applied. Some code audits examples are presented in this report and then the code audit report of DigiDoc is presented, which is a module of Open-EID. 1 Introduction Security of the applications being used is a .