This Week In Security: Chat Control, Vulnerability Extortion, And Emoji Malware

Way back in 2020, I actually read the proposed US legislation known as EARN IT, and with some controversy, concluded that much of the criticism of that bill was inaccurate. Well what’s old is new again, except this time it’s the European Union that’s wrestling with how to police online Child Sexual Abuse Material (CSAM). And from what I can tell of reading the actual legislation (pdf), this time it really is that bad.

The legislation lays out two primary goals, both of them problematic. The first is detection, or what some are calling “upload moderation”. The technical details are completely omitted here, simply stating that services “… take reasonable measures to mitigate the risk of their services being misused for such abuse …” The implication here is that providers would do some sort of automated scanning to detect illicit text or visuals, but exactly what constitutes “reasonable measures” is left unspecified.

The second goal is the detection order. It’s worth pointing out that interpersonal communication services are explicitly mentioned as required to implement these goals. From the bill:

Providers of hosting services and providers of interpersonal communications services that have received a detection order shall execute it by installing and operating technologies approved by the Commission to detect the dissemination of known or new child sexual abuse material or the solicitation of children…

This bill is careful not to prohibit end-to-end encryption, nor require that such encryption be backdoored. Instead, it requires that the apps themselves be backdoored, to spy on users before encryption happens. No wonder Meredith Whittaker has promised to pull the Signal app out of the EU if it becomes law. As this scanning is done prior to encryption, it’s technically not breaking end-to-end encryption.

You may wonder why that’s such a big deal. Why is it a non-negotiable for the Signal app to not look for CSAM in messages prior to encryption? For starters, it’s a violation of user trust and an intentional weakening of the security of the Signal system. But maybe most importantly, it puts a mechanism in place that will undoubtedly prove too tempting for future governments. If Signal can be forced into looking for CSAM in the EU, why not anti-government speech in China?

This story is ongoing, with the latest news that the EU has delayed the next step in attempting to ratify the proposal. It’s great news, but the future is still uncertain. For more background and analysis, see our conversation with the minds behind Matrix, on this very topic:

Bounty or Extortion?

A bit of drama played out over Twitter this week. The Kraken cryptography exchange had a problem where a deposit could be interrupted, and funds added to the Kraken account without actually transferring funds to back the deposit. A security research group, which turned out to be the CertiK company, discovered and disclosed the flaw via email.

All seemed well, and the Kraken team managed to roll a hotfix out in an impressive 47 minutes. But things got weird when they cross referenced the flaw to see if anyone had exploited it. Three accounts had used it to duplicate money. The first use was for all of four dollars, which is consistent with doing legitimate research. But additionally, there were more instances from two other users, totaling close to $3 million in faked transfers — not to mention transfers of *real* money back out of those accounts. Kraken asked for the details and the money back.

According to the Kraken account, the researchers refused, and instead wanted to arrange a call with their “business development team”. The implication is that the transferred money was serving as a bargaining chip to request a higher bug bounty payout. According to Kraken, that’s extortion.

There is a second side to this story, of course. CertiK has a response on their x.com account where they claim to have wanted to return the transferred money, but they were just testing Kraken’s risk control system. There are things about this story that seem odd. At the very least, it’s unwise to transfer stolen currency in this way. At worst, this was an attempt at real theft that was thwarted. The end result is that the funds were eventually completed.

Report Bug, Get Nastygram

For the other side of the coin, [Lemon] found a trivial flaw in a traffic controller system. After turning it in, he was rewarded with an odd letter that was a combination of “thank you” and your work “may have constituted a violation of the Computer Fraud and Abuse Act”. This is not how you respond to responsible disclosure.

Emoji Malware

We don’t talk much about malware in South Asia, but this is an interesting one. DISGOMOJI is a malware attributed to a Pakistani group, mainly targeting government Linux machines in India. What really makes it notable is that the command and control system uses emoji in Discord channels. The camera emoji instructs the malware to take a screenshot. A fox triggers a hoovering of the Firefox profiles, and so on. Cute!

Using Roundcube to break PHP

This is a slow moving vulnerability, giving that the core is a 24-year old buffer overflow in iconv() in glibc. [Charles Fol] found this issue, which can pop up when using iconv() to convert to the ISO-2022-CN-EXT character set, and has been working on how to actually trigger the bug in a useful way. Enter PHP. OK, that’s not entirely accurate, since the crash was originally found in PHP. It’s more like we’re giving up on finding something else, and going back to PHP.

The core vulnerability can only overwrite one, two, or three bytes past the end of a buffer. To make use of that, the PHP bucket structure can be used. This is a growable doubly-linked list that is used for data handling. Chunked HTTP messages can be used to build a multi-bucket structure, and triggering the iconv() flaw overwrites one of the pointers in that structure. Bumping that pointer by a few bytes lands in attacker controlled data, which can land in a fake data structure, and continuing the dechunking procedure gives us an arbitrary memory write. At that point, a function pointer just has to be pointed at system() for code execution.

That’s a great theoretical attack chain, but actually getting there in the wild is less straightforward. There has been a notable web application identified that is vulnerable: Roundcube. Upon sending an email, the user can specify the addresses, as well as the character set parameter. Roundcube makes an iconv() call, triggering the core vulnerability. And thus an authenticated user has a path to remote code execution.

Bits and Bytes

Speaking of email, do you know the characters that are allowed in an email address? Did you know that the local user part of an email address can be a quoted string, with many special characters allowed? I wonder if every mail server and email security device realized that quirk? Apparently not, at least in the case of MailCleaner, which had a set of flaws allowing such an email to lead to full appliance takeover. Keep an eye out for other devices and applications to fall to this same quirk.

Nextcloud has a pair of vulnerabilities to pay attention to, with the first being an issue where a user with read and share permissions to an object could reshare it with additional permissions. The second is more troubling, giving an attacker a potential method to bypass a two-factor authentication requirement. Fixes are available.

Pointed out by [Herr Brain] on Hackaday’s Discord, we have a bit of bad news about the Arm Memory Tagging Extensions (MTE) security feature. Namely, speculative execution can reveal the needed MTE tags about 95% of the time. While this is significant, there is a bit of chicken-and-egg problem for attackers, as MTE is primarily useful to prevent running arbitrary code at all, which is the most straightforward way to achieve a speculative attack to start with.

And finally, over at Google Project Zero, [Seth Jenkins] has a report on a trio of Android devices, and finding vulnerabilities in their respective kernel drivers. In each case, the vulnerable drivers can be accessed from unprivileged applications. [Seth]’s opinion is that as the Android core code gets tighter and more secure, these third-party drivers of potentially questionable code quality will quickly become the target of choice for attack.

13 thoughts on “This Week In Security: Chat Control, Vulnerability Extortion, And Emoji Malware

    1. I rather doubt that will be allowed to function for long if at all – The ‘reasonable measures’ to detect the material can easily contain detection for pre-encryption, and clearly you won’t be doing that if you are not sharing child sex or whatever other illegal content…
      Stenography type stuff might work, as then it passes that filter looking like one of the millions of cat photos or a ‘normal’ compressed archive, but straight up encryption is usually going to spotted.

  1. Re: messaging. Would it comply with the law to have the local device app check against known hashes, and then just refuse to send such material across its network, without reporting to anyone?

    Also, I’m sure it’s not lost on most people that you can password protect an archive that could contain anything – how does this new law prevent this elementary step that would defeat it?

    I know “thin end of the wedge” is a logical fallacy, but it sure sounds like a foot in the door…

    Besides, if the rozzers even think you have CSAM they can totally just smash down your door and RIPa you to death in court until you hand over any and all passwords to any and all devices/accounts they know you have.

    Given how this obviously wouldn’t work as written, one might almost suspect this isn’t actually about catching pedos…

    1. It’s *definitely* lost on most people that you can encrypt stuff before sending it.

      And even if they get there, they likely send one or two unencrypted first.

      So yeah, whilst it wouldn’t catch everyone, it’d catch a lot of low hanging fruit.

      1. But not if the reaction of these companies is to tell everyone to double encrypt everything first…

        As a CCNP, I used to have to monitor traffic from potentially naughty people, but if you make the naughty list in your own home state, there really is no hiding from them. Trust me on this.

        I didn’t crucify people, but I did hand out that nails.

        Don’t do crimes would be my friendly advice – and if one is on the list, all bets are off, no matter how technically adept one might thing they are.

        If I seem conflicted, it’s because I believe in the rule of law, but don’t want to live in a police state.

        1. I get your point, but, given how much publicity there is on WhatsApp/signal etc being E2E, and criminals are still getting caught for using text… there’s enough stupid ones.

          It’s not going to catch committed and knowledgeable CSAM users, but from what I’ve heard from an ex-colleague who got caught for it, it’s not a sudden jump into the dark web, it’s a slow movement into increasingly nasty stuff whilst he was in denial about the issue. Whilst technology has changed since back when he was caught, I suspect something like this would have caught him early and stopped him.

          The whole “China could use it for evil” things is a red herring. They already ban tech they can’t snoop on.

  2. The concept that any other government regime in the world who wishes to spy on its citizens is waiting for the EU to open the door for them to act by skirting app encryption is a wild take on end to end encryption laws.

  3. It would behoove the EU government to actually make the code they want included public /before/ specifying it needs to be included. This avoid the carte blanche scenario that the current legislation provide.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.