generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #195 from openrefactory/main
Basic README and July Report from OpenRefactory
- Loading branch information
Showing
3 changed files
with
110 additions
and
1 deletion.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| # Alpha Engagement: OpenRefactory | ||
|
|
||
| OpenRefactory thanks Alpha-Omega for supporting the project to report vulnerabilities at scale. | ||
|
|
||
| OpenRefactory will work alongside with Alpha-Omega project’s principals to report security vulnerabilities at scale in open source projects and work with the maintainers to get the vulnerabilities fixed: | ||
|
|
||
| 1. OpenRefactory will analyze open source software written in two languages: Java and Python. The goal is to analyze top 10,000 open source projects in these languages with OpenRefactory’s own [Intelligent Code Repair (iCR)](https://www.openrefactory.com/technology/) tool as well as the [Omega Analyzer](https://github.com/ossf/alpha-omega/tree/main/omega/analyzer). | ||
| 2. OpenRefactory will concentrate on the following critical security categories: [SQL Injection](https://cwe.mitre.org/data/definitions/89.html), [Cross-Site Scripting (XSS)](https://cwe.mitre.org/data/definitions/79.html), [Command Injection](https://cwe.mitre.org/data/definitions/77.html), [Path Manipulation](https://cwe.mitre.org/data/definitions/22.html), [Deserialization](https://cwe.mitre.org/data/definitions/502.html), [XML External Entity (XXE) Injection](https://cwe.mitre.org/data/definitions/611.html). In future, the proposed work will extend into security hardening and other kinds of bugs as well. | ||
| 3. OpenRefactory will use a portal to triage bug reports from their proprietary tool iCR (Intelligent Code Repair) and other tools from the Omega toolchain. | ||
| 4. Reports will include a range of problems which will require manual review. | ||
| 5. OpenRefactory will triage manually and follow the model outbound vulnerability disclosure policy to report the bugs in a responsible manner. | ||
| 6. OpenRefactory will follow the submissions and work with the maintainers to correct the issues. | ||
|
|
||
|
|
||
| The following KPIs will be tracked: | ||
|
|
||
| * The total number of projects that have ben analyzed | ||
| * The total number of issues that have been reported as True Positives | ||
| * The number of those reported issues for which exploit code was created | ||
| * The number of those reported issues for which fixes have been generated | ||
| * How many reports have been accepted? | ||
| * How many reports have been rejected? | ||
| * The number of "clean" projects where no security issues were uncovered | ||
|
|
||
|
|
||
| ## Timeline | ||
|
|
||
| This engagement started in July 2023. The metrics will be reviewed in December 2023 and the project is expected to continue in 2024 and 2025. | ||
|
|
||
| ## Monthly Updates | ||
|
|
||
| * [July 2023](update-2023-07.md) | ||
|
|
||
| ## Primary Contacts | ||
|
|
||
| * Munawar Hafiz - CEO, OpenRefactory | ||
| * Ataf Ahmed - Secure Software Engineer, OpenRefactory | ||
|
|
||
| ## Announcements / News | ||
|
|
||
| * [Blog post on early results: How to serve open source maintainers without annoying them?](https://www.openrefactory.com/how-to-serve-open-source-software-maintainers-without-annoying-them/) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| # OpenRefactory Update: July 2023 | ||
|
|
||
|
|
||
| ## Automate Scanning Process | ||
|
|
||
| We created scripts to automatically scan projects and store results in a database. Two separate scripts were written. | ||
|
|
||
| 1. A script that accepts a list of GitHub URLs, clones the projects, scans the projects with iCR and stores the results in a database. | ||
| 2. A script that accepts a list of GitHub URLs, clones the projects, scans the projects with the Omega Analyzer and stores the results in a database. The results generated from the Omega Analyzer is in SARIF format. This is converted to the internal database schema of the OpenRefactory Triage Portal. Some of the tools inside the Omega Analyzer generate too many low priority results that are outside the scope of the project. For example, in the Quarkus project, DevSkim generates 4,976 low priority results. Also, in the Apache Flink project, oss-detect-backdoor reports 93,602 low priority results. The script was modified to allow only results from Semgrep and CodeQL. Even that is hard to manage for many projects. For example, in the Quarkus project, Semgrep generates 2,765 results and in the Apache Flink project, Semgrep generates 2,085 results. We further limited the results to focus on the following CWEs: | ||
|
|
||
| * CWE 22 - Improper Limitation of a Pathname to Restricted Directory | ||
| * CWE 23 - Relative Path Traversal | ||
| * CWE 35 - Path Traversal: '.../...//' | ||
| * CWE 36 - Absolute Path Traversal | ||
| * CWE 59 - Improper Link Resolution Before File Access | ||
| * CWE 77 - Improper Neutralization of Special Elements Used in a Command (Command Injection) | ||
| * CWE 78 - Improper Neutralization of Special Elements Used in an OS Command (OS Command Injection) | ||
| * CWE 79 - Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting) | ||
| * CWE 80 - Improper Neutralization of Script Related HTML Tags in a Web Page (Basic XSS) | ||
| * CWE 81 - Improper Neutralization of Script in an Error Message Web Page | ||
| * CWE 82 - Improper Neutralization of Script in Attributes of IMG Tags in a Web Page | ||
| * CWE 83 - Improper Neutralization of Script in Attributes in a Web Page | ||
| * CWE 84 - Improper Neutralization of Script in URI Schemes in a Web Page | ||
| * CWE 85 - Double Character XSS Manipulations | ||
| * CWE 86 - Improper Neutralization of Invalid Characters in Identifiers in a Web Page | ||
| * CWE 87 - Improper Neutralization of Alternate XSS Syntax | ||
| * CWE 88 - Improper Neutralization of Argument Delimiters in a Command (Argument Injection) | ||
| * CWE 89 - Improper Neutralization of Special Elements Used in an SQL Command (SQL Injection) | ||
| * CWE 502 - Deserialization of Untrusted Data | ||
| * CWE 611 - Improper Restriction of XML External Entity Reference | ||
|
|
||
|
|
||
| ## Determine Scan Subjects | ||
|
|
||
| The target applications come from this list: | ||
| https://storage.googleapis.com/ossf-criticality-score/index.html?prefix=2022-06-07/per_lang/ | ||
|
|
||
| There are updates of this list available, but we are sticking with this since this is categorized based on the programming language used. | ||
|
|
||
| We will focus on top 10,000 applications written in Java and Python. | ||
|
|
||
|
|
||
| ## Update OpenRefactory Triage Portal | ||
|
|
||
| OpenRefactory expects to use the triage portal created by the Alpha-Omega team. OpenRefactory's team met with the Alpha-Omega team to understand the state of the Alpha-Omega triage portal. We found that the Alpha-Omega triage portal is still under development and is missing many key features. As such, OpenRefactory's team decided to start working using their own triage portal. The portal is password protected and is accessible from: https://pypi.openrefactory.com/. | ||
|
|
||
| The triage portal was used in March 2023 to demonstrate some early results. At that point, the reporting was done by creating pull requests. Since then, OpenSSF created policies to disclose vulnerabilities. | ||
|
|
||
| * https://github.com/ossf/open-auto-vuln-disclose | ||
| * https://lucid.app/users/login?returnUrlOverride=%2Flucidchart%2F65a0acea-0e4f-432c-a74f-344b4a6efc3b%2Fedit%3Fpage%3D0%26v%3D4964%26s%3D612#/login?referredProduct=lucidchart | ||
|
|
||
| The major change was to use GitHub's private vulnerability reporting feature to report vulnerabilities. So, OpenRefactory's triage portal was updated to support bug reporting using the private vulnerability repository. In addition, we implemented a subset of the workflow to allow our engineers to report vulnerabilities quickly. The full workflow will be implemented by the Alpha-Omega team and we will use it when available. | ||
|
|
||
| OpenRefactory also demonstrated its triage portal to the Alpha-Omega team and illustrated how the portal is likely to be used. At this point, OpenRefactory will probably be the only user of the Alpha-Omega triage portal when it is ready. So, the use cases provided by OpenRefactory are important in designing the Alpha-Omega triage portal. | ||
|
|
||
| At this point, the triage portal update is mostly done. The security researchers will be starting to use the portal from early August. | ||
|
|
||
| ## Assist in triaging a bug in Nginx | ||
|
|
||
| On July 3, there was a [blog post](https://labs.hakaioffsec.com/nginx-alias-traversal/) that discussed a long-standing alias traversal vulnerability in Nginx. This vulnerability was previously discussed by Detectify in a [blog post](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/) in 2020. The origin of this vulnerability was from 2018: https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf | ||
|
|
||
| The particular config pattern found over 2,200 matches in a naive GitHub search. OpenRefactory's security team worked with Alpha-Omega's Jonathan Leitschuch to triage over 200 cases. Jonathan may run an autofix campaign. We recommended the following for the autofix campaign. | ||
|
|
||
| * Majority of the bugs are in documentation. These can be easily filtered out with the file type. The autofix campaign should state in the report that the fix is in the documentation and the main intent of fixing this is to make sure that people are not misinformed. | ||
| * There are a few bugs in actual config files. In such cases, the projects can be categorized based on the GitHub stars. The more popular ones should get a stronger message. Even this category can be handled by OpenRefactory, where we will manage the relationship and make sure that the bugs get fixed. For the projects with low popularity, the autofix campaign can just send messages and then not track that often. Note that if the total number of bugs in actual configurations is only a handful (which it may be), we may not need to categorize them at all. | ||
|
|
||
| These suggestions make the autofix campaign more practical and the fixes are more likely to be accepted. | ||
|
|
||
|
|