|
| 1 | +--- |
| 2 | +title: "Python-tuf source code audit" |
| 3 | +author: Joshua Lock |
| 4 | +--- |
| 5 | + |
| 6 | +We are pleased to announce completion of a source code audit of the recently |
| 7 | +refactored python-tuf codebase. |
| 8 | + |
| 9 | +# Background |
| 10 | + |
| 11 | +In February 2022 the python-tuf team [released version 1.0]( |
| 12 | + https://theupdateframework.github.io/python-tuf/2022/02/21/release-1-0-0.html |
| 13 | +). This release was the product of a significant refactoring effort with the |
| 14 | +code being rewritten from scratch to provide two new stable API’s: |
| 15 | +* A low-level interface for creating and consuming TUF metadata |
| 16 | +* A robust and pluggable client implementation |
| 17 | + |
| 18 | +Unifying both of these APIs is a focus on developer ergonomics and flexibility |
| 19 | +of the API. |
| 20 | + |
| 21 | +While the new python-tuf codebase is much leaner, a mere 1,400 lines of code at |
| 22 | +release, compared to the legacy code’s 4,700 lines, and builds on the lessons |
| 23 | +learned from development (and developers) on the prior versions of python-tuf, |
| 24 | +we were very conscious of the fact that our first major release of a security |
| 25 | +project was made up of newly authored code. |
| 26 | + |
| 27 | +To improve our confidence in this newly authored code we engaged with the Open |
| 28 | +Source Technology Improvement Fund (OSTIF) to have an independent security |
| 29 | +assessment of the new python-tuf code. OSTIF connected us with the team at X41 |
| 30 | +D-Sec who performed a thorough source code audit, the results of which we are |
| 31 | +releasing today. |
| 32 | + |
| 33 | +# Results and resolutions |
| 34 | + |
| 35 | +The report prepared by X41 included one medium severity and four low severity |
| 36 | +issues, we describe below how we are addressing each of those reported items. |
| 37 | + |
| 38 | +**Private Key World-Readable (TUF-CR-22-01) – Medium** |
| 39 | + |
| 40 | +This vulnerability is not in any code called by python-tuf, but was included in |
| 41 | +demonstrative code the python-tuf team provided to the X41 team. The underlying |
| 42 | +issue is in |
| 43 | +[securesystemslib](https://github.com/secure-systems-lab/securesystemslib), a |
| 44 | +utility library used by python-tuf which provides a consistent interface around |
| 45 | +various cryptography APIs and related functionality, where any files were |
| 46 | +created with the default permissions of the running process. |
| 47 | + |
| 48 | +We resolved this issue by [adding an optional restrict parameter]( |
| 49 | + https://github.com/secure-systems-lab/securesystemslib/pull/231/files) |
| 50 | +to the `storage.put()` interface and in the corresponding filesystem |
| 51 | +implementation of the interface ensuring that when `restrict=True` files are |
| 52 | +created with octal permissions `0o600` (read and write for the user only). |
| 53 | + |
| 54 | +This enhancement has been included in the recent release of |
| 55 | +[securesystemslib 0.25.0]( |
| 56 | + https://github.com/secure-systems-lab/securesystemslib/releases/tag/v0.25.0 |
| 57 | +). |
| 58 | + |
| 59 | +**Shallow Build Artifact Verification (TUF-CR-22-02) – Low** |
| 60 | + |
| 61 | +The `verify_release` script, run by python-tuf developers as part of the |
| 62 | +release process and available to users to verify that a release on GitHub or |
| 63 | +PyPI matches a build of source code from the repository, was only performing |
| 64 | +a shallow comparison of files. That is, only the type, size, and modification |
| 65 | +times were compared. We have [modified the script]( |
| 66 | + https://github.com/theupdateframework/python-tuf/pull/2122/files |
| 67 | +) to perform a deep comparison of the contents and attributes of files being |
| 68 | +verified. |
| 69 | + |
| 70 | +**Quadratic Complexity in JSON Number Parsing (TUF-CR-22-03) – Low** |
| 71 | + |
| 72 | +This issue was not in python-tuf itself, rather the problem was in Python’s |
| 73 | +built-in json module. |
| 74 | + |
| 75 | +Fortunately, we did not need to take any action for this issue as it was |
| 76 | +independently reported upstream and has been fixed in Python. Find more details |
| 77 | +in [CVE-2020-10735: Prevent DoS by large int<->str conversions]( |
| 78 | + https://github.com/python/cpython/issues/95778) on Python’s issue tracker. |
| 79 | + |
| 80 | +**Release Signatures Add No Protection (TUF-CR-22-04) – Low** |
| 81 | + |
| 82 | +python-tuf releases are built by GitHub Actions in response to a developer |
| 83 | +pushing a tag. However, before those releases are published to the project’s |
| 84 | +GitHub releases page and PyPI a developer must verify (using the |
| 85 | +`verify_release` script discussed earlier) and approve the release. Part of the |
| 86 | +approval includes creating a detached signature and including that in the |
| 87 | +release artifacts. While these do not add any additional protection, we do |
| 88 | +believe that the additional authenticity signal is worthwhile to users. |
| 89 | + |
| 90 | +Furthermore, along with the above notice and the recommendations in the |
| 91 | +informational notes we will continue to iterate on our build and release |
| 92 | +process to provide additional security for users of python-tuf. |
| 93 | + |
| 94 | +# Thank you |
| 95 | + |
| 96 | +We are extremely grateful to X41 for their thorough audit of the python-tuf |
| 97 | +code, to [Open Source Technology Improvement Fund](https://ostif.org) (OSTIF) |
| 98 | +for connecting us with the [X41 D-Sec, GMBH](https://x41-dsec.de) team, and to |
| 99 | +the [Cloud Native Computing Foundation](https://www.cncf.io) (CNCF) for funding |
| 100 | +the source code audit – thank you all. |
| 101 | + |
| 102 | +Read the full report here: [Source Code Audit on The Update Framework for Open Source Technology Improvement Fund (OSTIF)]( |
| 103 | + https://theupdateframework.io/audits/x41-python-tuf-audit-2022-09-09.pdf). |
0 commit comments