Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix #1119: avoid unsafe approach to deserializing data#1141

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.

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

Already on GitHub?Sign in to your account

Draft
mhucka wants to merge9 commits intomain
base:main
Choose a base branch
Loading
frommh-fix-deserialization

Conversation

@mhucka
Copy link
Contributor

@mhuckamhucka commentedSep 24, 2025
edited
Loading

CodeQL securityscan report #567 flagged a data loading operation insrc/openfermion/utils/operator_utils.py as being usafe due because it uses a user-provided value. The warning is about lines 282-283, involving the code

withopen(file_path,'rb')asf:data=marshal.load(f)

Deserializing untrusted data using any deserialization framework that allows the construction of arbitrary serializable objects is easily exploitable and in many cases allows an attacker to execute arbitrary code. Even before a deserialized object is returned to the caller of a deserialization method a lot of code may have been executed, including static initializers, constructors, and finalizers. Automatic deserialization of fields means that an attacker may craft a nested combination of objects on which the executed initialization code may have unforeseen effects, such as the execution of arbitrary code.

The problem here is that loading serialized Python objects usingmarshal is inherently unsafe, because the format is not designed to be secure against malicious or corrupted data. Unfortunately, we probably can't simply switch to a safer serialization method (e.g., JSON or protobufs) because users may already have saved files in this format. We should maintain backward compatibility with people's existing files.

This PR adds more checks on the data read byload_operator(), including checks on maximum file size.

Note: the maximum file size values are hardwired as constants near the top of this file. I don't have much evidence for what would be reasonable max values, so made some guesses based on other files found in the repository. Someone with longer experiencing using OpenFermion should double-check the values.

CodeQL security [scan report#567](https://github.com/quantumlib/OpenFermion/security/code-scanning/567) flagged a data loading operation in `src/openfermion/utils/operator_utils.py` as being usafe due because it uses a user-provided value. The warning is about lines 282-283, involving the code```pythonwith open(file_path, 'rb') as f:    data = marshal.load(f)```> Deserializing untrusted data using any deserialization framework that allows the construction of arbitrary serializable objects is easily exploitable and in many cases allows an attacker to execute arbitrary code. Even before a deserialized object is returned to the caller of a deserialization method a lot of code may have been executed, including static initializers, constructors, and finalizers. Automatic deserialization of fields means that an attacker may craft a nested combination of objects on which the executed initialization code may have unforeseen effects, such as the execution of arbitrary code.This changes the code to use the `json` package instead of the `marshal` package and extracts the data more carefully.
@mhuckamhucka changed the titleFix security scan warning about deserialization of dataFix #1119: avoid unsafe approach to deserializing dataSep 25, 2025
@mhuckamhucka added the area/healthInvolves code and/or project health labelSep 26, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

area/healthInvolves code and/or project health

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@mhucka

[8]ページ先頭

©2009-2025 Movatter.jp