[Michael Lynch]’s adventures in configuring Nix to automate fuzz testing is a lot of things all rolled into one. It’s not only a primer on fuzz testing (a method of finding bugs) but it’s also a how-to on automating the setup using Nix (which is a lot of things, including a kind of package manager) as well as useful info on effectively automating software processes.

[Michael] not only walks through how he got it all up and running in a simplified and usefully-portable way, but he actually found a buffer overflow in pdftotext in the process! (Turns out someone else had reported the same bug a few weeks before he found it, but it demonstrates everything regardless.)

[Michael] chose fuzz testing because using it to find security vulnerabilities is conceptually simple, actually doing it tends to require setting up a test environment with a complex workflow and a lot of dependencies. The result has a high degree of task specificity, and isn’t very portable or reusable. Nix allowed him to really simplify the process while also making it more adaptable. Be sure to check out part two, which goes into detail about how exactly one goes from discovering an input that crashes a program to tracking down (and patching) the reason it happened.

Making fuzz testing easier (and in a sense, cheaper) is something people have been interested in for a long time, even going so far as to see whether pressing a stack of single-board computers into service as dedicated fuzz testers made economic sense.

A British journalistic trope involves the phrase “The pound in your pocket”, a derisory reference to the 1960s Prime Minister Harold Wilson’s use of it to try to persuade the public that a proposed currency devaluation wouldn’t affect them. Nearly six decades later not so many Brits carry physical pounds in their pockets as electronic transfers have become more prevalent, but the currency remains. So much so that the governor of the Bank of England has had to reassure the world that the pound won’t be replaced by a proposed “Britcoin” cryptocurrency should that be introduced.

Normally matters of monetary policy aren’t within Hackaday’s remit, but since the UK is not the only country to mull over the idea of a tightly regulated cryptocurrency tied to their existing one, there’s a privacy angle to be considered while still steering clear of the fog of cryptocurrency enthusiasts. The problem is that reading the justification for the new digital pound from the Bank of England, it’s very difficult to see much it offers which isn’t already offered by existing cashless payment systems. Meanwhile it offers to them a blank regulatory sheet upon which they can write any new rules they want, and since that inevitably means some of those rules will affect digital privacy in a negative manner, it should be a worry to anyone whose government has considered the idea. Being at pains to tell us that we’ll still be able to see a picture of the King (or a dead President, or a set of bridges) on a bit of paper thus feels like an irrelevance as increasingly few of us handle banknotes much anyway these days. Perhaps that act in itself will now become more of an act of protest. And just when we’d persuaded our hackerspaces to go cashless, too.

Header: Wikitropia, CC BY-SA 3.0.

Leading off the week is the controversy around the Linux kernel and an unexpected change in maintainership. The exact change was that over a dozen developers with ties to or employment by Russian entities were removed as maintainers. The unfortunate thing about this patch was that it was merged without any discussion or real explanation, other than being “due to various compliance requirements”. We eventually got more answers, that this was due to US sanctions against certain Russian businesses, and that the Linux Foundation lawyers gave guidance that:

If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file.

So that’s that. One might observe that it’s unfortunate that a single government has that much control over the kernel’s development process. There were some questions about why Russian entities were targeted and not sanctioned Chinese companies like Huawei. [Ted Ts’o] spoke to that, explaining that in the US there are exemptions and different rules for each country and business. This was all fairly standard compliance stuff, up until a very surprising statement from [James Bottomley], a very core Kernel maintainer:

We are hoping that this action alone will be sufficient to satisfy the US Treasury department in charge of sanctions and we won’t also have to remove any existing patches.

I can only conclude from this that the US Treasury has in fact made this threat, that code would need to be removed. Now this is genuinely surprising, given the legal precedent that code is 1st Amendment protected speech. That precedent was established when dealing with encryption code that was being export restricted in the 90s. It seems particularly problematic that the US government believes it can specify what code does and does not belong in the Linux kernel.

SELinux

Since we’re in Kernel land, let’s talk SELinux. Many modern Linux systems, and Android in particular, use SELinux to provide an extra security layer. It’s not an uncommon troubleshooting step, to turn off SELinux to see if that helps with mysterious issues. What we have here in the klecko Blog is an intro to bypassing SELinux. The setup is that an exploit has achieved root, but is in a unprivileged context. What options does an attacker have to try to bypass SELinux?

The first, most obvious solution is to just disable SELinux altogether. If you can write to memory, the SELinux enabled bit can just be set to false. But that might not work, if you can’t write to memory, or have a hypervisor to wrestle with, like some Android systems. Another option is the set of permissive flags that can be overwritten, or the AVC cache that can be poisoned, both approaches resulting in every SELinux request being approved. It’s an interesting overview.

Printer Root

Xerox printers with the “Network Troubleshooting” feature have some unintended hidden functionality. The troubleshooting is done by calling tcpdump as root, and the configuration allows setting the IP address to use for the troubleshooting process. And as you might expect, that IP address was used to create a command line string, and it isn’t properly escaped. You can sneak a $(bash ...) in as part of the address, allowing code execution. The good news is that access to this troubleshooting function is locked behind the web admin account. Xerox has made fixed firmware available for this issue.

Fix Your Roundcube

The Roundcube email web client has a Cross-Site Scripting (XSS) vulnerability that is actively being exploited. The flaw is the processing of SVGs, and the addition of an extra space in an href tag, that the browser ignores. Sneaking this inside an SVG allows for arbitrary Javascript to run when opening this malicious email.

Roundcube has released 1.5.7 and 1.6.7 that address the issue. This is under active exploitation, currently being used against the Russian aligned CIS countries. It’s a simple exploit, so expect to see it more widely used soon.

The Archive

The Internet Archive continues to be under siege. The Distributed Denial of Service (DDoS) attacks were apparently done by SN-Blackmeta. But the hacker behind the data breach is still a mystery. But the news this week is that there is still someone with access to Internet Archive API keys. Specifically Zendesk, illustrated by the fact that when Mashable reached out via email, the hacker answered, “It’s dispiriting to see that even after being made aware of the breach 2 weeks ago, IA has still not done the due diligence of rotating many of the API keys that were exposed in their gitlab secrets.”

It’s obviously been a terrible, horrible, no good, and very bad month for the Internet Archive. As it’s such an important resource, we’re hoping for some additional support, and getting the service back to 100%.

Quantum Errata

You may remember last week, that we talked about a Quantum Annealing machine making progress on solving RSA cryptography. In the comments, it was pointed out that some coverage on this talks about RSA, and some talks about AES, a cryptography thought to be quantum-resistant. At least one source is claiming that this confusion is because there were actually two papers from the same team, one discussing RSA, and the other techniques that could be used against AES. This isn’t confirmed yet, and there are outstanding questions about both papers.

Bits and Bytes

SQL injection attacks are old hat by this point. [NastyStereo] has an interesting idea: Polyglot SQL injection attacks. The idea is simple. A SQL query might be escapable with a single quote or a double quote. To test it, just include both: OR 1#"OR"'OR''='"="'OR''='. There are more examples and some analysis at the link.

Kaspersky researchers found a Chrome exploit, that was being delivered in the form of an online tank battle game. In reality, the game was stolen from its original developers, and the web site was a crypto stealing scam, making use of the browser 0-day. This campaign has been pinned on Lazarus, the APT from North Korea.

And yet another example of fake software, researchers at kandji discovered a fake Cloudflare Authenticator campaign. This one is a MacOS malware dropper that does a reasonably good job of looking like it’s an official Cloudflare app. It’s malware, and places itself in the system crontab, to get launched on every boot. Follow the link for Indicators of Compromise if you need them.