Free software activities in February 2024

Here is my monthly update covering what I have been doing in the free software world during February 2024 (previous month):

Reproducible Builds

One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes.

This month, I:

In Debian:
- Kept isdebianreproducibleyet.com up to date. [...]
- I submitted 3 patches to fix specific reproducibility issues in geophar, klepto& pytest-repeat.
Categorised a large number of packages and issues in the Reproducible Builds notes.git repository.
Drafted, published and publicised our monthly report.

Updated the main Reproducible Builds website and documentation:
- Improve the relative sizing of headers. [...]
- Re-order and "punch" up the introduction and documenation on the SOURCE_DATE_EPOCH page. [...]
- Update SOURCE_DATE_EPOCH documentation re. datetime.datetime.fromtimestamp. Thanks, James Addison. [...]
- Add a post about Reproducible Builds at FOSDEM 2024. [...]

diffoscope

Elsewhere in our tooling, I made the following changes to diffoscope, including preparing and uploading versions 256, 257& 258 to Debian:

Use a deterministic name instead of trusting gpg's --use-embedded-filenames. Many thanks to Daniel Kahn Gillmor dkg@debian.org for reporting this issue and providing feedback. [...][...]
Don't error-out with a traceback if we encounter struct.unpack-related errors when parsing Python .pyc files. (#1064973). [...]
Don't try and compare rdb_expected_diff on non-GNU systems as %p formatting can vary, especially with respect to MacOS. [...]
Fix compatibility with pytest 8.0. [...]
Temporarily fix support for Python 3.11.8. [...]
Use the 7zip package (over p7zip-full) after a Debian package transition. (#1063559). [...]
Bump the minimum Black source code reformatter requirement to 24.1.1+. [...]
Expand an older changelog entry with a CVE reference. [...]
Make test_zip black clean. [...]

Debian

bfs:
- 3.1-1— New upstream release.
- 3.1.1-1— New upstream bugfix release.
python-django:
- 4.2.10-1— New upstream security release.
- 5.0.2-1— New upstream security release.

I performed the following QA uploads:

Finally, I also performed a sponsored upload of adminer version 4.8.1-2.

Debian LTS

This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project.

Investigated and triaged: python-django (CVE-2024-24680), bind9 (CVE-2023-4408, CVE-2023-50387, CVE-2023-50868, CVE-2023-5517& CVE-2023-5679), exiv2 (CVE-2024-24826& CVE-2024-25112), glewlwyd (CVE-2024-25715), libhibernate-validator-java (CVE-2023-1932), nodejs (CVE-2023-46809, CVE-2024-21892& CVE-2024-22019), unbound (CVE-2023-50387& CVE-2023-50868), lucene-solr (CVE-2023-50291, CVE-2023-50292, CVE-2023-50298& CVE-2023-50386), filezilla (CVE-2023-48795) & ghostscript (CVE-2020-36773).
Frontdesk duties, responding to user/developer questions, reviewing others' packages, participating in mailing list discussions, etc.
Issued DLA 3738-1 as it was discovered that there was an authentication bypass issue in iwd, the Intel Wireless Daemon. Adversaries could have gained unauthorised access to a protected 'home' (ie. non-WPA2-Enterprise) WiFi network. This problem was addressed in version 0.14-2+deb10u1.
Issued DLA 3743-1 because, similar to the above issue in iwd, there was a potential authentication bypass vulnerability in wpa, a set of tools including the widely-used wpasupplicant client for authenticating with WPA and WPA2 wireless networks. For an attack to have been successful, however, wpasupplicant must have been configured to not verify the network's TLS certificate during Phase 1 of the authentication cycle; the vulnerability could have been used to skip Phase 2 authentication by sending an EAP-TLV "Success" packet instead of actually starting Phase 2. This problem has been fixed in wpa version 2:2.7+git20190128+0c1e29f-6+deb10u4.
Addressed four CVEs in DLA 3744-1 for Django, a popular Python-based web development framework:
- CVE-2021-28658: Prevent a directory traversal issue which could have been exploited by maliciously crafted filenames. However, the built-in upload handlers were not affected by this vulnerability. (#986447)
- CVE-2021-31542: Fix a potential directory-traversal vulnerability that could have been exploited by uploaded files. The MultiPartParser, UploadedFile and FieldFile classes allowed directory-traversal via uploaded files with suitably crafted file names. In order to mitigate this risk, stricter basename and path sanitation is now applied. Specifically, empty file names and paths with dot (.) segments are rejected. (#988053)
- CVE-2021-33203: Prevent a potential directory traversal via admindocs. Staff members could use the admindocs' TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by the developers to also expose the file contents, then not only the existence but also the file contents would have been exposed. As a mitigation, path sanitation is now applied and only files within the template root directories can be loaded. (#989394)
- CVE-2021-33571: Prevent possible SSRF, RFI (Remote File Inclusion) and LFI (Local File Inclusion) attacks, since validators accepted leading zeros in IPv4 addresses. URLValidator, validate_ipv4_address() and validate_ipv46_address() did not prohibit leading zeros in octal literals. (#989394)