[The Open Source Dilemma: Balancing innovation, security, and [sustainability
Kazuho suggests that this incident does not indicate an overall exhaustion or decline in the efforts of the OSS community, but rather reflects a broader problem with OSS adoption and maintenance.
Furthermore, he criticizes the indiscriminate addition of features and dependencies to OSS projects and uses systemd and its integration with sshd as a case study. according to Kazuho, the attack on sshd was possible because the distribution added systemd-inotify support to sshd, which, according to Kazuho, was made possible by the unintentional introduction of a vulnerability via xz (liblzma). He argues that systemdâs approach of supporting both traditional detached daemon management and its enhanced mode contributes to complexity and potential security issues, and that a more restrained approach in adding features and dependencies can mitigate such risks We suggest that a more restrained approach in adding features and dependencies can mitigate such risks.
Kazuho also mentions the risks inherent in shared libraries, noting that adding dependencies on these libraries may allow arbitrary code execution by executing initialization code that is executed at load time. This vulnerability also extends to indirectly loaded libraries, amplifying the potential for security breaches.
Despite these criticisms, Kazuho acknowledges that continuous development and innovation are necessary to ensure the spread and success of OSS. He references a statement by Yukihiro Matsumoto (Matz), founder of Ruby, about the importance of âkeeping swimmingâ and remaining relevant and useful by actively addressing new challenges and continuing to generate ânoise.
Finally, Kazuho reflects on the dual nature of the openness and ease of sharing of OSS as both a strength and a potential weakness. While this openness promotes cooperation and quality improvement, it also permits the rapid dissemination of flawed or vulnerable software. However, he suggests that the very act of sharing source code without the expectation of immediate profit improves quality, thereby contributing to the overall value and sustainability of OSS projects.
Through these observations, Kazuho offers a multifaceted perspective on OSS project management, the balance between innovation and security, and the broader implications of the open nature of OSS for software quality and community resilience.
kazuho Personally, I donât think itâs exhaustion, I think itâs inevitable due to the nature of OSS. If it is commercial software, if the maintenance cost is not worth it, it will not be released in the first place, and if it becomes difficult to maintain, it will be closed⊠In other words, it is a problem for those who adopt third-party OSS
kinu: xz backdoor, this is numbing⊠The attacker also forked zstd and lz4, which could have been next. the OSS world is tired and cannot sustain itself without welcoming dedicated contributors with technical skills. The fundamental risk is there: hooking from ifunc resolvers and being able to observe performance differences under specific articles. https://openwall.com/lists/oss-security/2024/03/29/4âŠ
kazuho So, I think the countermeasure is not to easily increase the number of functions and dependencies, and if you do, make plug-ins and separate permissions. I think the reason for the attack on sshd this time is that systemd is the opposite of that, a culture of âI want to do this and I want to do thatâ. In the first placeâŠ
kazuho 1. this time, I was able to create a backdoor to sshd via xz (liblzma) because distro companies added systemd-inotify support to sshd. systemd-inotify support to sshd.
- systemd-inotify is a mechanism to notify the completion of daemon startup, but it âenhancesâ the management of daemons that are detached in the old fashioned way. If the daemon does not detach, it is not neededâŠ
kazuho ⊠systemd should have been unified and guided to the non-detaching method, but chose to do âthis and thatâ by supporting both methods and âenhancingâ the detaching method as well.
The systemd-inotify protocol is about 10 lines even in the original implementation, but it is provided as a library (libsystemd). I provided it as 4. * systemd depends on liblzma for log compression, but external command linking is sufficient for that (and wasnât that more flexible?).
kazuho The result of all these factors is that liblzma is loaded through libsystemd at ssh startup, and the liblzma attack The condition that the code works was established.
kazuho What is often overlooked is that shared libraries (.so) can embed initialization code to be executed at load time, so adding a dependency on a library The moment you add a dependency on a library, you are allowing arbitrary code execution even if you do not call that library (and this includes libraries that are loaded indirectly).
kazuho However, even if this view is correct, in order to spread and succeed as OSS @yukihiro_matz As > pointed out, itâs important to âkeep swimmingâ (keep working on new things and making noise), and adding new features is the solutionâŠ
kazuho: So, I think the countermeasure is not to easily increase the number of functions and dependencies, or if you do, to make it a plugin and separate the permissions. In the first placeâŠ
kazuho Put another way, the advantage of OSS over commercial software is that it can be shared openly without second thoughts. Even if OSS is a bad currency with inferior quality, it is getting rid of commercial software which is a good currency. In fact, giving up monetization allows source code sharing, which results in quality improvement.
kazuho: Personally, I donât think itâs exhaustion, I think itâs inevitable due to the nature of OSS. If it is commercial software, if the maintenance cost is not worth it, it will not be released in the first place, and if it becomes difficult to maintain, it will be closed⊠In other words, it is a problem for those who adopt third party OSS x.com/kinu/status/17âŠ
This page is auto-translated from /nishio/ăȘăŒăăłăœăŒăčăźăžăŹăłăïŒă€ăăăŒă·ă§ăłăă»ăă„ăȘăăŁăăăăŠæç¶ćŻèœæ§ăźăă©ăłăč using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. Iâm very happy to spread my thought to non-Japanese readers.