Malware infiltrates Pidgin messenger's official plugin repository | Hacker News Reader

Malware infiltrates Pidgin messenger's official plugin repository

bleepingcomputer.com

174 pointsmikece34 comments

Zerodium [0] [1] offered $100k for a remote code execution exploit for Pidgen about 3 years ago, the offer ran from June to September of 2021. Governments and a lot of bad agents must really want to get into that app.

I haven't used it for years since AIM and ICQ became unpopular to my peers, and most places like Google dropped XMPP support. Perhaps Pidgen added support and became a great chat client for some protocol on the rise that I am unaware. Is it still widely deployed in certain contexts or countries?

[0] https://twitter.com/rw_grim/status/1399817799657218059

[1] https://news.ycombinator.com/item?id=27371612

We're finally gearing up to have an experimental release of Pidgin 3.0 by the end of the year, but the goal right now only include the IRC protocol. But everything has been updated to support all of the newer chat features so support for other protocols should come quick.

(warning, heavily opinionated post follows)

I know it's asking for a lot, but it would be really cool if Pidgin would have 1st-class out-of-the-box support for Matrix.

I don't want to get into discussions if it's better than Jabber, because I don't really think it is, but since the momentum is on Matrix rather than XMPP, then I'd say that Pidgin could use the fact that currently Matrix lacks a proper client. By "proper client" I mean something that is feature-complete by standards of year 2000 (actually good software, like Pidgin), not 2020 (which features broken, half-ass web prototypes that people call software).

It would probably help with fighting the parasites like Discord, which is way too popular than it should be.

someone could certainly pick up https://github.com/matrix-org/purple-matrix and finish it.

The current state of purple-matrix for use in Pidgin leaves a lot to be desired. For example, it's quite slow to connect and missing a decent amount of features which aren't just nice to have. OTOH, the format of chats is a bit more streamlined and clearer to read.

Here's hoping the next version of Pidgin implements something that resolves the slow connection so I can begin using Pidgin as my preferred Matrix client over Fractal or the like.

That plugin was abandoned and we (the pidgin team) are unlikely to pick it up as we're planning our own implementation.

We have been planning a new from scratch version that'll be in tree, but with the retirement of libolm which is for good reasons, it means we're going to have to write our own OLM implementation at some point as well.

https://matrix.org/blog/2024/08/libolm-deprecation/

TL;DR it's on the list, going to be a bit before we get to it.

hm, you really shouldn’t have to write your own olm implementation(!)

either you could swap primitives in libolm (eg fork libolm and merge https://gitlab.matrix.org/matrix-org/olm/-/merge_requests/24) or use vodozemac via wrappers.

libolm was not using battle tested crypto. That's one of their main reasons for abandoning it. Our plan is to use gcrypto for it which is battle tested.

As far as vodozemac goes, we're not pulling rust into our build system.

I guess it's notable how the offer was only up for 4 months...

XMPP is still used here and there. You can just use your own server and encryption and stay secretive, which explains the interest of certain actors.

Original announcement: https://pidgin.im/posts/2024-08-malicious-plugin/

LWN: https://lwn.net/Articles/987320/

The plugin provided some kind of screen sharing.

A more in-depth post will be coming soon. I'm working on the first draft of it tonight on everything that happened.

I used to use pidgin years ago before social media ruined the internet as a central place to message people across different services. I didn't know it was still going in the social media/walled garden age.

Yeah we're still here and trying to get an experimental pre-alpha release of Pidgin3 out by the end of the year. Unfortunately basically everything had to change to support modern chat features, so initial protocol support is going to be very light.

Former Trillian user here. It all went to shit when AOL started the AIM Wars, and then Trillian gradually changed from cool to enshittified. It was an awesome time when interoperability was a thing, though.

> To prevent similar incidents from happening in the future, Pidgin announced that, from now on, it will only accept third-party plugins that have an OSI Approved Open Source License, allowing scrutiny into their code and internal functionality.

This is an understandable policy, but how would it have stymied the attacker in this case? It's unlikely that Windows users would be building from source (and Darkgate appears to be Windows only). Unless there's a policy that Pidgin extensions are strictly reproducible, it seems unlikely that the presence of an adjacent, benign source artifact would have increased the likelihood of early discovery.

> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.

— Ken Thompson, Reflections on Trusting Trust, 1984

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

I think quoting RoTT in this context is a little cliche: as a practical matter, we're all trusting immense amounts of code that we haven't read. The question is what to do about that practical reality, other than "give up because of the existential threat of a compiler backdoor."

The answer is to procure your binaries from sources you trust:

* Commercial vendors like Microsoft, Intel, Valve, etc. who have a vested financial interest in your continued patronage.

* Private vendors like the guys behind WINE, Notepad++, ffmpeg, etc. who are reputable and have that reputation on the line.

Speaking practically, if you don't trust your source to begin with you aren't going to waste your time auditing their code and compiling it yourself either.

I know Gentoo Linux is not for everyone and doesn't fix the issue of there being wayy too much source to ever personally be able to check it all, however I think there is something to be said for the fact that the source is indeed readable in-the-clear with most parts of the system and lots of it has even been looked-over by the package/ebuild maintainers. Not trying to say there's no risk, but I think it might reduce it quite a bit if you have the patience! The #gentoo IRC channel is in-my-experience incredibly helpful, totally smashing most types of support from corporate companies out of the water! (Of course that's also only working like that because hardly anyone uses Gentoo.. but I think the point still stands!)

And you can't trust code that you totally created yourself to be free from grave security bugs, but that's not a useful moral either

Or, you can run untrusted code in a restricted sandbox. Sadly, Linux distributions do not implement it out of the box for unclear reasons, unlike browsers for example which run every app in a sandbox.

What I want is a system where I can run anything without any risk.

>Linux distributions do not implement it out of the box

There are several distributions that _do_ implement by-default restrictions to all running software with stuff like Cgroups and GRSecurity. There are even distributions dedicated to isolating even the drivers, like Qubes.

The idea is to slow them down and make it harder. We don't have the time, resources, or expertise to examine every plugin which is precisely why we don't host or provide binaries for external plugins.

Pidgin (and its OTR plugin) used to be the most popular client for OTR (Off-The-Record, an encryption protocol) messaging. That was my experience about 10 years ago and back then I think the plugins were known to be a weak point in its security.

> A red flag is that ss-otr only provided binaries for download and not any source code, but due to the lack of robust reviewing mechanisms in Pidgin's third-party plugin repository, nobody questioned its security.

Opaque binaries without deterministic builds are an open source supply chain security hole that we will slowly, inevitably narrow. There will be much kicking and screaming along the way, though.

oh wow. I have become fond of pidgin over the years. There is a slack plugin that makes life a lot better. It seems for plugins, extensions, app stores, and general third-party repositories (pip, npm, crates, etc) risks are increasing. Centralization breeds certain risks that are tough to mitigate. So far, mitigating these risks involve trusting a central steward, cryptographic signing, and contributor reputation.I wonder if we can ever truly mitigate the contributor or steward aspects?

Intersting. Pidgin and variations are used by some gov orgs.

Surprise! In-app plugin repos are a supply-chain disaster zone. I had to walk away from a project that wouldn't take the threat seriously lest I get caught up in the fallout when it all goes horribly wrong.

Surprise, this is just an index of plugins on a webpage and not in app at all...

Is Pidgen still the default IRC client bundled with Tails?

That's Pidgin not "Pidgen". And yes.

was this the malicious plugin? (from the reddit thread [0])

https://github.com/jabberplugins/pidgin-screenshare

   The plugin uses a reverse-tunneling SocketIO-server (to bypass NAT) on https://jabberplugins.net (*hosted by me*) which is used for routing OTR-encrypted (if enabled) screenshare packets between you & your buddy.

It also includes the libotr lib, modified by the author.

I'd love to read the analysis by Johnny Xmas, the report from 0xfffc0000 and even the binary so other people can test it with other tools and/or analyze it.

[0] https://www.reddit.com/r/linux/comments/1f1jv08/comment/lk1o...

Reply on news.ycombinator.com