Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document security expectations #1623

Merged
merged 7 commits into from
Feb 8, 2024
Merged

Document security expectations #1623

Changes from 2 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
b2a9350
Document security expectations
cary-ilm Feb 1, 2024
c69ce22
Menion Imath as a dependency
cary-ilm Feb 1, 2024
810b37d
Update SECURITY.md
cary-ilm Feb 2, 2024
019de19
change 'Threat Model' to 'Potential Vulnerabilties'
cary-ilm Feb 2, 2024
4bb9788
Mention GitHub issue as fallback security contact
cary-ilm Feb 7, 2024
6e1deb5
github security advisory
cary-ilm Feb 8, 2024
3131083
mention exrcheck
cary-ilm Feb 8, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 95 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,3 +57,98 @@ These vulnerabilities are present in the given versions:

See the [release notes](CHANGES.md) for more information.

## Supported Versions

This gives guidance about which branches are supported with patches to
security vulnerabilities.

| Version / branch | Supported |
| --------- | ---------------------------------------------------- |
| main | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
| 3.2.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. |
| 3.1.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| 3.0.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| 2.5.x | :warning: Only the most critical fixes, only if they can be easily backported. |
| <= 1.x | :x: No longer receiving patches of any kind. |

## Security Expectations

### Software Features

- The OpenEXR project implements the EXR image file format, used
throughout the motion picture industry and beyond, on Linux, macOS,
and Windows.

- The project consists of a software run-time library, implemented in
C/C++ and built via cmake, that reads and writes image data
files. The project also distributes python wrappings for the C/C++
I/O API.

- The library reads and writes binary image data and text-based
metadata, treated as blind data, none of which is executable code.

- Other than the website and online technical documentation, the
project implements no web/online services or network communication
protocols. The library never requests any security or
authentication creditials or login information from users.
cary-ilm marked this conversation as resolved.
Show resolved Hide resolved

The website implements no interactive features and requires no login
credentials.

- The library reads and writes only to file paths specificly requested
via the C/C++ API. The runtime library uses no system configuration
files or sidecar data files. Access to data files uses only standard
file I/O system calls.

- The library compresses/decompresses data via standard compression
algorithms but uses no cryptographic or confidentiality protocols.

### Software Dependencies

OpenEXR depends on
[Imath](https://github.com/AcademySoftwareFoundation/Imath), a library
of basic math operations also maintained and distributed by the
OpenEXR project. Imath follows the same security conventions
documented here for OpenEXR itself. The core Imath library has no
external dependencies. The Imath python bindings depend on python and
boost.

The only
external library dependency of OpenEXR is
[libdeflate](https://github.com/ebiggers/libdeflate), which implements
standard deflate/zlib/gzip compression and decompression.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Imath not count as an 'external library dependency'?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the records: c-blosc2 could also become a dependency of OpenEXR soon, which has dependencies to lz4, zlib-ng, and zstd.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering Imath a part of the "OpenEXR Project", but yes, better to call that out explicitly.

And yes, we'll need to keep this statement up to date if/when we add dependencies.


The project uses
[Snyk](https://github.com/AcademySoftwareFoundation/openexr/blob/main/.github/workflows/snyk-scan-pr.yml)
to scan for dependency vulnerability.

### Threat Model

The primary threat to OpenEXR is software faults in the form of heap
buffer overflows, out-of-memory faults, or segmentation faults that
could be exploitable as denial-of-service attacks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like the threat model would more be looking at trust boundaries, inputs, outputs etc. What's described here is more potential vulnerabilities.

The goal of a threat model and threat analysis is to really analyze how a pice of software of system could be used in malicious or non expected ways, see if there is enough protection in place and how possible issues could/can be mitigated, how things could be exploited and what would happen if something bad was to happen. It's also used as a way to weight the severity and likelihood of possible defects, etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to work up some verbiage with the help of AI, and the result looks good to me. I am not sure if you are suggesting we should describe the threat model better, which I have requested of the AI, or if you are suggesting we should undertake an analysis. If the latter, I would counter that it is perhaps out of scope for this PR, as that would be, if done properly, a very large project. Perhaps we could refine this with more specific facts about OpenEXR and less of the generalities the AI has proposed from general principles.

The threat model of OpenEXR, a high-dynamic-range (HDR) image file format, primarily revolves around potential vulnerabilities that could compromise the confidentiality, integrity, or availability of data stored in OpenEXR files. While OpenEXR itself is a well-established and widely used format, like any software, it may have certain considerations in terms of security. Here are some aspects to consider:

Trust Boundaries:

Identify and define trust boundaries within the OpenEXR ecosystem. This includes interactions with external systems, libraries, and user inputs.
Evaluate the trustworthiness of components interacting with OpenEXR, considering factors such as data sources, processing modules, and external dependencies.

Inputs and Outputs:

Analyze the types of inputs OpenEXR processes and ensure robust validation mechanisms are in place to handle potentially malicious or unexpected input.
Assess the security of output data to prevent information disclosure, unintended leakage, or exploitation of sensitive information.

Misuse Scenarios:

Enumerate potential misuse scenarios, considering both intentional and unintentional misuse of OpenEXR functionality.
Evaluate the impact of scenarios where OpenEXR is used as part of an attack chain or where it unintentionally facilitates malicious activities.

Protection Mechanisms:

Evaluate existing protection mechanisms to determine their effectiveness in mitigating identified threats.
Identify areas where additional security measures, such as input validation, encryption, or access controls, may be necessary to enhance the overall security posture.

Severity and Likelihood Assessment:

Weigh the severity and likelihood of identified threats to prioritize mitigation efforts. Consider the impact of successful exploitation and the likelihood of occurrence.

Defects and Vulnerabilities:

Conduct a thorough analysis of potential defects and vulnerabilities in the OpenEXR software, assessing their potential impact on the overall security of the system.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry if my comment wasn't clear. I'm not suggesting to do a threat model and/or threat analysis. I am more pointing to the fact that the current paragraph isn't describing a threat model per say and I'm describing what a threat model is.

As for the output from the AI, it's a little bit vague and not very useful I think. It's basically describing what a threat model is and how to write/define one and not what the threat model is. But it has some bits that could be useful.

So how about maybe something like:

The entry point is any images being loaded using the library. Malformed images could caused issues (list issues). OpenEXR has tests (fuzz tests, unit tests, etc) to mitigate against these. (does it also set sane default compiler flags to protect against some of these errors?), etc...

Would that make sense?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the AI blurb really says anything significant. I change "Thread Model" to "Potential Vulnerabilities" and lifted @JeanChristopheMorinPerso verbiage, thanks. The next section mentions tests, this is just to state what the vulnerabilities are.

This is my take on what's required for the "security expectations", but it's not (yet) the "assurance case" the badgeapp also requires, that's for later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for proposing some text @JeanChristopheMorinPerso, I was puzzling over what we could possibly write there, so thought maybe the AI quote would help jostle up some ideas.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good to me!


### Hardening

#### Testing

The OpenEXR project implements a comprehensive suite of validation
tests, including fuzz testing to harden against malicious input data.

The project also uses the [OSS
Fuzz](https://bugs.chromium.org/p/oss-fuzz) service for continuous
fuzz testing.

#### Development Cycle and Distribution

OpenEXR is downloadable and buildable by C/C++ source via GitHub. Only
members of the project's Technical Steering Committee, all veteran
software engineers at major motion picture studios or vendors, have
write permissions on the source code repository. All critical software
changes are reviewed by multiple TSC members.

The library is distributed in binary form via many common package
managers across all platforms.