Subscribe
A previously unknown contributor to the popular open-source Android app store F-Droid repeatedly pressured its developers to push a code update that would have introduced a new vulnerability to the software, in what one of the developers described on Mastodon as a “similar kind of attempt as the Xz backdoor.”
As the fallout of the Xz backdoor continues to rock the open source software community, people working on open source software are realizing (and reiterating) that a culture in which people often feel entitled to constant updates and additional features from volunteer coders presents a pretty large attack surface.
In the case of the Xz backdoor, a malicious actor was able to pressure the owner of a widely-used Linux compression utility called Xz Utils into making them a trusted maintainer of the project. They did this in part by arguing that the owner was letting the community of users down because they weren’t pushing new features and updates often enough, in the eyes of this malicious coder. You can read our full rundown here
Tuesday, Hans-Christoph Steiner, a longtime developer of F-Droid, explained that a very similar situation nearly led F-Droid to push an update that would have introduced a security vulnerability into the product three years ago: “Three years ago, F-Droid had a similar kind of attempt as the Xz backdoor,” he posted on Mastodon. “A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a SQL injection vulnerability. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think it’s relevant now.”
Other open source developers and security experts have pointed to the dynamic of bullying and the general reliance on a small number of volunteer developers. They explained that it’s a problem across much of the open source software ecosystem, and is definitely a problem for the large tech companies and infrastructure who rely on these often volunteer-led projects to build their for-profit software on top of.
Glyph, the founder of the Twisted python networking engine open source project, said the Xz Utils pressure campaign should “cause an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message.”
They then linked to an email in the Xz Utils listserv that shows a likely sockpuppet account arguing “Progress will not happen until there is new maintainer … The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this.”
Meredith Whitaker, the president of Signal, said “I keep brooding on the way the xz backdoor was enabled in significant part via weaponizing the FOSS [free and open source software culture of shitty behavior and abuse.”
“What is striking is that the uncool, mean standards of FOSS conduct that many of us have decried for years, and that many defended as authentic, tough, etc., ended up not just being exclusionary loser behavior, but a significant attack surface.”
In the case of F-Droid, Steiner linked to the GitLab thread where a specific potential update was discussed. This thread shows how a pressure campaign can potentially compromise an open source project.
In that thread, the now-banned developer who wanted to push code that would have added a vulnerability repeatedly demanded that their new feature be integrated into the live product immediately. As Steiner said, the new feature would have changed how people searched for apps on F-Droid. The potentially malicious user argued “the search results are pretty unusable currently,” and proposed new code. Over the course of months, that user kept writing things like “do we want to merge now?,” meaning push the code live and “I’d really like for this to get into the next release.”
When other users, including Steiner, pointed out that they still needed to review the code, tweak it, or make adjustments to improve its functionality, the original user became angry, and other users backed the original poster.
One other user, for example, argued “I’d like to get this merged for a release soon … is this perfect? No, but it doesn’t need to be. It just needs to be better than what we have now.”
“The second big reason why I think this should be merged soon, is about encouraging new contributors,” the person arguing for inclusion added. “And not by saying ‘we welcome contributions’ and then never allowing any changes because they are not perfect. If people never get anything merged they'll most likely never spend any more time diving deeper into the codebase and tackling more complex tasks later on.”
The original poster wrote “at risk of sounding rude, I believe that this is a great change as it stands, and we have spent too long debating alternative implementations that I am not going to work on (I have a full-time job, and I will not spend my time on work that I believe to be worse than what I have already made). Please consider leaving new details to a future discussion or change and merging what we have now.”
Steiner argued that the code wasn’t ready to go, and that pushing it could “break things for many 10s of thousands of users.”
“I haven't seen any evidence that there is a sudden crisis caused by bad search. It’s been that way since the beginning. So we have time to get this right,” Steiner wrote.
The original poster continued to pressure Steiner and other maintainers of the code, and eventually wrote “nah man, I’m tired of this … I'm not coming back to this project until I see that contributions made in good faith are welcomed instead of fought every step of the way.”
When Steiner was finally able to audit the code, he found that it would have introduced a vulnerability that would have allowed for SQL injections, which is a very basic type of hack that could have crashed the app and would have also potentially introduced other problems. Steiner wrote at the time that he was unsure whether this was actively malicious or just sloppy, but noted that it was a “security risk” either way.
“I wonder if this was an attempt to insert a SQL injection vuln? Or am I just paranoid?,” he wrote. “Anyone know anything about the original submitter?”
Steiner wrote this week that the original coder deleted their account as soon as F-Droid’s maintainers attempted to review the code, and that he thinks that the user’s behavior, as well as “all the attention from random new accounts” has led him to believe “it could be a deliberate attempt to insert the vuln.”
In this case, the vulnerability ultimately wasn’t pushed to a live product, but it’s a very specific example of the types of pressures and culture that open source projects are constantly dealing with. (An aside: While on the F-Droid forum, I happened to also see two long threads in which a user said Steiner was acting with “scandal behavior” and deep bias because F-Droid had failed to properly implement official support for the constructed artificial language Esperanto into the app; Steiner repeatedly explained that Android itself did not support Esperanto and that was the issue.)
Regardless of intent, Steiner wrote that “clear communication definitely suffers when maintainers are overloaded, stressed out and feel ganged up on. I think that's another key takeaway from this current incident. For a well resourced actor, it is not too hard to social engineer themselves into a trusted position when projects get into that position. That happens all too often, unfortunately.”
