Perpetual IT

Researchers at Qualys have revealed a now-patched security hole in a very widely used Linux security toolkit that’s included in almost every Linux distro out there.

The bug is officially known as CVE-2021-4034, but Qualys has given it a funky name, a logo and a web page of its own, dubbing it PwnKit.

The buggy code forms part of the Linux Polkit system, a popular way of allowing regular apps, which don’t run with any special privileges, to interact safely with other software or system services that need or have administrative superpowers.

For example, if you have a file manager that lets you take care of removable USB disks, the file manager will often need to negotiate with the operating system to ensure that you’re properly authorised to access those devices.

If you decide you want to wipe and reformat the disk, you might need root-level access to do so, and the Polkit system will help the file manager to negotiate those access rights temporarily, typically popping up a password dialog to verify your credentials.

If you’re a regular Linux user, you’ve probably seen Polkit-driven dialogs – indeed the text-based Polkit man page gives an old-school ASCII-art rendition of the way they typically look:

Polkit as an alternative sudo

What you might not know about Polkit is that, although it’s geared towards adding secure on-demand authentication for graphical apps, it comes with a handy command-line tool called pkexec, short for Polkit Execute.

Simply put, pkexec is a bit like the well-known sudo utility, where sudo is short for Set UID and Do a Command, inasmuch as it allows you to switch temporarily to a different user ID, typically root, or UID 0, the all-powerful superuser account.

In fact, you use pkexec in much the same way as you do sudo, adding pkexec to the start of a command line that you don’t have the right to run in order to get pkexec to launch it for you, assuming that Polkit thinks you’re authorised to do so:

# Regular users are locked out of the Polkit configuration directory... $ ls -l /etc/polkit-1/rules.d/
/bin/ls: cannot open directory '/etc/polkit-1/rules.d/': Permission denied # Using an account that hasn't been authorised to run "root level"
# commands via the Polkit configuration files... $ pkexec ls -l /etc/polkit-1/rules.d/
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/ls' as the super user
Authenticating as: root
Password: polkit-agent-helper-1: pam_authenticate failed: Authentication failure
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorized This incident has been reported. # After adding a Polkit rule to permit our account to do "root" stuff,
# we get automatic, temporary authorisation to run as the root user... $ pkexec ls -l /etc/polkit-1/rules.d/
total 20
-rw-r--r-- 1 root root 360 Dec 31 2021 10-enable-powerdevil-discrete-gpu.rules
-rw-r--r-- 1 root root 512 Dec 31 2021 10-enable-session-power.rules
-rw-r--r-- 1 root root 812 Dec 31 2021 10-enable-upower-suspend.rules
-rw-r--r-- 1 root root 132 Dec 31 2021 10-org.freedesktop.NetworkManager.rules
-rw-r--r-- 1 root root 404 Dec 31 2021 20-plugdev-group-mount-override.rules
-rw-r--r-- 1 root root 542 Dec 31 2021 30-blueman-netdev-allow-access.rules # And if we put no command and no username on the command line, pkexec
# assumes that we want a shell, so it runs our preferred shell (bash),
# making us root (UID 0) until we exit back to the parent shell... $ pkexec bash-5.1# id
uid=0(root) gid=0(root) groups=0(root),...
exit
$ id
uid=1042(duck) gid=1042(duck) groups=1042(duck),...

As well as checking its access control rules (alluded to in the file listing above), pkexec also performs a range of other “security hardening” operations before it runs your chosen command with added privileges.

For example, consider this program, which prints out a list of its own command line arguments and environment variables:

/*----------------------------ENVP.C---------------------------*/ #include <stdio.h>
#include <string.h> void showlist(char* name, char* list[]) { int i = 0; while (1) { /* Print both the address where the pointer */ /* is stored and the address that it points to */ printf("%s %2d @ %p [%p]",name,i,list,*list); /* If the pointer isn't NULL then print the */ /* string that it actually points to as well */ if (*list != NULL) { printf(" -> %s",*list); } printf("\n"); /* List ends with NULL, so exit if we're there */ if (*list == NULL) { break; } /* Otherwise move on to the next item in list */ list++; i = i+1; } } /* Command-line C programs almost all start with a boilerplate */
/* function called main(), to which the runtime library */
/* supplies an argument count, the arguments given, and the */
/* environment variables of the process. */
/* argv[] lists the arguments; envp[] lists the env. variables */ int main(int argc, char* argv[], char* envp[]) { showlist("argv",argv); showlist("envp",envp); return 0;
}

If you compile this progam and run it, you’ll see something like this, with a laundry list of environment variables that reflect your own preferences and settings:

$ LD_LIBRARY_PATH=risky-variable GCONV_PATH=more-risk ./envp first second
argv 0 @ 0x7fff2ec882c8 [0x7fff2ec895b8] -> ./envp
argv 1 @ 0x7fff2ec882d0 [0x7fff2ec895bf] -> first
argv 2 @ 0x7fff2ec882d8 [0x7fff2ec895c5] -> second
argv 3 @ 0x7fff2ec882e0 [(nil)]
envp 0 @ 0x7fff2ec882e8 [0x7fff2ec895cc] -> GCONV_PATH=more-risk
envp 1 @ 0x7fff2ec882f0 [0x7fff2ec895e1] -> LD_LIBRARY_PATH=risky-variable
envp 2 @ 0x7fff2ec882f8 [0x7fff2ec89600] -> SHELL=/bin/bash
envp 3 @ 0x7fff2ec88300 [0x7fff2ec89610] -> WINDOWID=25165830
envp 4 @ 0x7fff2ec88308 [0x7fff2ec89622] -> COLORTERM=rxvt-xpm
[...]
envp 38 @ 0x7fff2ec88418 [0x7fff2ec89f07] -> PATH=/opt/redacted/bin:/home/duck/...
envp 39 @ 0x7fff2ec88420 [0x7fff2ec89fb9] -> MAIL=/var/mail/duck
envp 40 @ 0x7fff2ec88428 [0x7fff2ec89fcd] -> OLDPWD=/home/duck
envp 41 @ 0x7fff2ec88430 [0x7fff2ec89fe8] -> _=./envp
envp 42 @ 0x7fff2ec88438 [(nil)]

Note two things:

• The pointer arrays for the arguments and environment variables are contiguous in memory. The NULL pointer at the end of the argument array, shown at memory address 0x7fff2ec882e0 as [(nil)], is followed immediately by the pointer to the first environment string (GCONV_PATH) at 0x7fff2ec882e8. Pointers are 8 bytes each on 64-bit Linux, and the argv and envp pointer lists run from 0x7fff2ec882c8 to 0x7fff2ec88438 in contiguous steps of 8 bytes each time. There is no unused memry between argc[] and envp[].
• Both the argv list and the envp list are entirely under your control. You get to choose the arguments and to set any environment variables you like, including adding ones on the command line to use when running this command only. Some environment variables, such as LD_PRELOAD and LD_LIBRARY_PATH, can be used to modify the behaviour of the program you’re executing, including quietly and automatically loading additional commands or executable modules.

Let’s run the command again as root, by using pkexec:

$ LD_LIBRARY_PATH=risky-variable GCONV_PATH=more-risk pkexec ./envp first second
argv 0 @ 0x7ffdf900fc98 [0x7ffdf9010eec] -> /home/duck/Articles/pwnkit/./envp
argv 1 @ 0x7ffdf900fca0 [0x7ffdf9010f0e] -> first
argv 2 @ 0x7ffdf900fca8 [0x7ffdf9010f14] -> second
argv 3 @ 0x7ffdf900fcb0 [(nil)]
envp 0 @ 0x7ffdf900fcb8 [0x7ffdf9010f1b] -> SHELL=/bin/bash
envp 1 @ 0x7ffdf900fcc0 [0x7ffdf9010f2b] -> LANG=en_US.UTF-8
envp 2 @ 0x7ffdf900fcc8 [0x7ffdf9010f3c] -> LC_COLLATE=C
envp 3 @ 0x7ffdf900fcd0 [0x7ffdf9010f49] -> TERM=rxvt-unicode-256color
envp 4 @ 0x7ffdf900fcd8 [0x7ffdf9010f64] -> COLORTERM=rxvt-xpm
envp 5 @ 0x7ffdf900fce0 [0x7ffdf9010f77] -> PATH=/usr/sbin:/usr/bin:/sbin:/bin:/root/bin
envp 6 @ 0x7ffdf900fce8 [0x7ffdf9010fa4] -> LOGNAME=root
envp 7 @ 0x7ffdf900fcf0 [0x7ffdf9010fb1] -> USER=root
envp 8 @ 0x7ffdf900fcf8 [0x7ffdf9010fbb] -> HOME=/root
envp 9 @ 0x7ffdf900fd00 [0x7ffdf9010fc6] -> PKEXEC_UID=1000
envp 10 @ 0x7ffdf900fd08 [(nil)]

This time, you will notice that:

• The command name (argv[0]) has been converted to a full pathname. The pkexec program does this right at the outset, to avoid ambiguity when the program runs with superuser powers. Note that this conversion happens before the underlying Polkit system intervenes to check whether you’re allowed to run the chosen program, and thus before any password prompts appear.
• The list of environment variables has been trimmed and adjusted for security reasons. In particular, the operating system itself automatically prunes several known-bad environment variables from any program, such as pkexec, that has the privilege to promote other software to run as root. (In technical jargon, this means any program with the setuid bit set, of which pkexec is an example.)

Beware the buffer overflow

So far, so good.

Except that Qualys discovered that if you deliberately launch the pkexec program in such a way that the value of its own argv[0] parameter (by convention, set to the name of the program itself) is blanked out and set to NULL…

…then in the process of converting the command name you want to run (./envp above) into a full pathname (/home/duck/Articles/pwnkit/./envp), the pkexec startup code will perform a buffer overflow.

For security reasons, pkexec ought to detect that it was unusually launched with no command line arguments at all, not even its own name, and refuse to run.

Instead, pkexec blindly looks at what it thinks is argv[1] (usually, this would be the name of the command you are asking it to run as root), and tries to find that program on your path.

But if argv[0] was already NULL, then there are no command line arguments, and what pkexec thinks is argv[1] is actually envp[0], the first environment variable, because the argv[] and envp[] arrays are directly adjacent in memory.

So, if you set your first environment variable to be the name of a program that can be found on your PATH, and then run pkexec with no command arguments at all, not even argv[0], then the program will combine your path with value of the environment variable it mistakenly thinks is the name of the program you want to run…

…and write that “more secure” version of the “filename” back into what it thinks is argv[1], ready to run the chosen program via its full pathname, rather than a relative one.

Unfortunately, the modifed string written into argv[1] actually ends up in envp[0], which means that a rogue user could, in theory, exploit this argv-to-envp buffer misaligment to reintroduce dangerous environment variables that the operating system itself had already taken the trouble to expunge from memory.

Full elevation of privilege

To cut a long story short, Qualys researchers discovered a way to use a dangerously “reintroduced” environment variable of this sort to trick pkexec into running a program of their choice before the program got as far as verifying whether their account was entitled to use pkexec at all.

Because pkexec is a “setuid-root” program (this means that when you launch it, it magically runs as root rather than under your own account), any subprogram you can coerce it into launching will inherit superuser privileges.

This means that any user who already has access to your system, even if they’re logged in under an account with almost no power at all, could, in theory, use pkexec to promote themselves instantly to user ID 0: the root, or superuser, account.

The researchers wisely didn’t provide working proof-of-concept code, although as they wryly point out:

We will not publish our exploit immediately; however, please note that this vulnerability is trivially exploitable, and other researchers might publish their exploits shortly after the patches are available.

What to do?

• Patch early, patch often. Many, if not most, Linux distros should have an update out already. You can (safely) run pkexec --version to check the version you’ve got. You want 0.120 or later.
• If you can’t patch, consider demoting pkexec from its superpower privilege. If you remove the setuid bit from the pkexec executable file then this bug will no longer be exploitable, because pkexec won’t automatically launch with superuser powers. Anyone trying to exploit the bug would simply end up with the same privilege that they already had.

FIND AND FIX PKEXEC – HOW TO USE THE WORKAROUND

Finding pkexec on your path:

$ which pkexec
/usr/bin/pkexec <---probable location on most distros

Checking the version you have. Below 0.120 and you are probably vulnerable, at least on Linux:

$ /usr/bin/pkexec --version
pkexec version 0.120 <-- our distro already has the updated Polkit package

Checking the file mode bits. Note that the letter s in the first column stands for setuid, and means that when the file runs, it will automatically execute under the account name listed in column three as the owner of the file; in this case, that means root. In terminals with colour support, you may see the filename emphasised with a bright red background:

$ ls -l /usr/bin/pkexec
-rwsr-xr-x 1 root root 35544 2022-01-26 02:16 /usr/bin/pkexec*

Changing the setuid bit. Note how, after demoting the file by “subtracting” the letter s from the mode bits, the first column no longer contains an S-for-setuid marker. On a colour terminal, the dramatic red background will disappear too:

$ sudo chmod -s /usr/bin/pkexec Password: ***************
$ ls -l /usr/bin/pkexec
-rwxr-xr-x 1 root root 35544 2022-01-26 02:16 /usr/bin/pkexec* <-- setuid bit removed

Turning setuid back on. If you need to re-enable the root-acquiring powers of pkexec before getting the latest update, or if updating the Polkit package doesn’t restore the setuid bit automatically, you can use the chmod +s ... command (in a similar way to how you used -s above) in order to “add back” the letter s to the mode bits:

$ sudo chmod +s /usr/bin/pkexec Password: ***************
$ ls -l /usr/bin/pkexec
-rwsr-xr-x 1 root root 35544 2022-01-26 02:16 /usr/bin/pkexec* <-- setuid bit restored

Many countries have taxation forms with names that have entered the general vocabulary, notably the abbreviations of documents that employers are obliged to provide to their staff to show how much money they were paid – and, most importantly, how much tax was already witheld and paid in on the employee’s behalf.

In the UK, for example, the form name P45 is often used as a synonym for getting fired, given that it’s a final tax summary that you get when you leave a job, willingly or otherwise.

In South Africa, you get an IRP5 at the end of the tax year – an archaic term that we are guessing is short for Inland Revenue/Personal, Form #5, even though the South African tax office hasn’t been called the Inland Revenue for nearly 25 years.

In the USA, the earnings form is a W-2, short for Wages and Tax Statement, Version 2. (It seems that there used to be a form W-1, but it was superseded back in the 1950s.)

Here at Naked Security, we know the names of these forms, amongst numerous others, because they often show up in tax scam emails, presumably to give those messages an air of realism.

Anyway, given that it’s the last week in January, and thus that US tax filing season is about to get underway, we weren’t surprised to receive a tax-related scam email today, and to see the W-2 form mentioned explicitly.

We were, however, intrigued by the “less is more” nature of today’s phishing message: there was no traditional call to action, just a simple request for further information.

Phishing without links

Usually, when we write about tax scams, we’re warning about traditional phishing campaigns where the idea is to trick you into “logging in” to a bogus site where your tax office account details and password get captured by cybercriminals.

Sometimes, the crooks use the high-pressure tactic of warning you that you could get into trouble if you don’t act right away (and who would willingly undertake a tax office audit?); often, however, the scam relies on the lure of a refund, like this one we received via text message a year ago:

But, as regular readers will know, quite a few cybercrime groups are moving away from pure-play “technohacks” these days, such as email scams that rely entirely on you clicking a fake link.

Instead, many cybercriminals are adopting the “human led” approach that has served criminals such as advance fee fraudsters and romance scammers so well over the years.

Ransomware scammers, for example, used to rely heavily on automatically catching out hundreds or thousands of independent victims at a time by spamming out links or attachments that directly unleashed the ransomware and then demanded somewhere from $300 to $1000 from anyone who got hit.

These days, the human-led approach means that although ransomware criminals still rely on scrambling hundreds or thousands of computers in a single attack, there’s rarely any obvious or widespread spam campaign that gives away the attack in advance.

LEARN MORE ABOUT HOW MODERN CYBERCRIMINALS ATTACK

Click-and-drag on the soundwaves below to skip to any point in the podcast.
You can also listen directly on Soundcloud, or read a full transcript of the recording.

These days, ransomware criminals typically break into (or buy their way into) your network very quietly, and then carefully plan for an attack that’s co-ordinated and kicked off manually, at a time to suit the crooks and to disadvantage you.

Similarly, tech support scammers are increasingly relying on persuading you to call them, rather than bombarding the world with spammy links or phishy attachments and then trying to filter out the people or computers that seem to respond.

Many victims are willing to call the scammers back – they often provide a convenient toll-free number, so it doesn’t even cost you anything – because it feels like a low-risk approach.

After all, hackers can’t directly push malware onto your computer or inject an exploit into your browser if you’re just talking to them.

Of course, the crooks use that to their own advantage, often giving you a level of personal attention and hand-holding that you wish you could get from other IT vendors…

…at which point, the criminals don’t need an exploit to run code on your computer, because they’ll helpfully and patiently talk you through doing that job all by yourself: they sneakily trick you into creating a cybersecurity problem for yourself under the guise of fixing one.

A little politeness goes a long way

Today’s tax scammers have done a “let’s ask nicely” job, carefully avoiding links and attachments, and presumably hoping that someone on their mailing list will be willing to reply in the hope of investigating what feels like a new business opportunity:

I actually intend to change cpa for my 2021 tax return, Would like to know if your firm is open to accept new clients for the next tax year, All my documents are completed, all I am yet to have is just my W2.

Kindly advise on how to proceed and if I can send forth all the available documents and whats are your fees for individual returns

[REDACTED]
Managing Director

(CPA is short for Certified Public Accountant, the US equivalent of what people in many Commonwealth countries refer to as a CA, or Chartered Accountant.)

On one hand, the fact that many scammers are avoiding links and attachment these days suggests that we are, as a digital society, learning to be more cautious before blindly believing in unsolicited websites or files.

On the other hand, we need to remember that engaging with a scammer in any way at all is the first step that any cybercrook wants to you take.

What to do?

Not least because it’s Data Privacy Week this week, and Data Privacy Day on Friday 28 January 2022, always keep in mind our simplest advice when deciding whether to engage with people you don’t already know online:

• Be aware before you share. Every little bit you give away about yourself makes it easier for a scammer to charm you, threaten you, or entice you into an online relationship you didn’t ask for in the first place.
• If in doubt, don’t give it out. If it feels like a scam, back yourself and assume that it is.
• No reply is a often good reply. Never feel compelled to reply out of politeness or completeness. It’s easier to stay out of a wheedler’s clutches if you don’t open the door for a reply-to-your-reply.
• Listen to friends and family. Especially when money is involved – whether it’s you sending it to a romance scammer who falsely claims to love you, or receiving it from newfound “business associates” who have fraudulently pitched you a “job” in their organisation.

Stay safe online, everyone!

Russian news agency Tass reported over the weekend that the “purported founder” of a notorious cybercrime group known as Infraud Organisation has been arrested.

Naked Security first wrote about law enforcement action against this crime crew almost three years ago, back in February 2018, when the US Department of Justice (DOJ) unleashed indictments against 36 defendants alleged to be part of what the DOJ described at the time as:

[A] cybercriminal enterprise engaged in the large-scale acquisition, sale, and dissemination of stolen identities, compromised debit and credit cards, personally identifiable information, financial and banking information, computer malware, and other contraband.

As a side-effect of the American indictment, 13 people were arrested in seven different countries: Australia, France, Italy, Kosovo, Serbia, the UK and the US.

The DOJ claimed to have evidence at the time that Infraud Org, operating under the unrepentant motto In Fraud We Trust, was responsible for more than $500 million in actual losses, and more than $2 billion in what law enforcement referred to as “intended losses”.

The 36 defendants went by an eclectic range of online nicknames, including Best4Best, Goldenshop, Guapo1988, Moneymafia, Moviestar, Renegade11, Secureroot, Skizo, Validshop and Zo0mer.

One of those indicted back in 2018 was a certain Andrey Sergeevich Novak, also known as Unicc, also known as Faaxxx, also known as Faxtrod.

Novak, claims this weekend’s Tass report, which quotes an “informed source”, is one of four suspects now under arrest in Russia.

He was allegedly arrested two months ago – the report implies that he’s still in custody – along with three other members of the group whom Tass describe as “detained under house arrest”. (We’re assuming that the US equivalent would be that Novak didn’t make bail, while the other three did.)

None of the latter three were listed by name in the 2018 US indictment, although six of the 36 defendants were entered simply as John Doe, US jargon for “name unknown”.

“The investigation continues,” states Tass, “to establish the other members of the international hacking group.”

Maltese cryptocoin broker Foris DAX MT Ltd, better known by its domain name Crypto.com, experienced a multi-million dollar “bank robbery” earlier this month.

According to a brief security report published yesterday, 483 customers experienced ghost withdrawals totalling just over 4800 Ether tokens, just over 440 Bitcoin tokens, and just over $66,000 in what are listed only as “other cryptocurrencies”.

Using approximate conversion rates for 17 January 2022 (ETH1=$3300 and BTC1=$43,000), which is when the spurious transactions were spotted, puts the total loss due to this heist at about $35,000,000.

What went wrong?

Crypto.com claims that “all accounts found to be affected were fully restored”, which we assume to mean that customers with phantom withdrawals were reimbursed by Crypto.com itself.

Details of how the crooks pulled off the attack aren’t given in the report, which says simply that “transactions were being approved without the 2FA authentication control being inputted by the user.”

What the report doesn’t explain, or even mention, is whether 2FA codes were entered by someone – albeit not by customers themselves – in order to authorise the fraudulent withdrawals, or whether the 2FA part of the authentication process was somehow bypassed entirely.

This means we can’t easily tell how or why the 2FA process didn’t work properly, though several possible explanations spring to mind.

If you’re interested in looking at how your own 2FA system might fail, you will need to consider a long list of possibilities, including:

• A fundamental flaw in the underlying 2FA system. For example, an SMS-based system of one-time numeric codes that was based on a defective random generator might produce guessable sequences that could allow attackers to predict the right code to enter for some or all users.
• A breach of the 2FA authentication database. For example, an app-based code generator system typically relies on a shared secret known as a seed, which can’t be stored as a hash like a regular password. Both client and server must have access to the plaintext of the seed at login time, so a server-side breach could give an attacker the details needed to compute the one-time code sequences for some or all users.
• Poor coding in the online login process. A badly-configured authentication server might inadvertently allow the client-side login request to manipulate the configuration settings used, for example by including undocumented HTTP headers or adding special URL parameters that unexpectedly override existing security precautions.
• Weak internal controls to detect risky behaviour by support or IT staff. For example, overly helpful (or wilfully corrupt) insiders might not be subjected to peer review, or second sign-off, for critical account changes. This is how the infamous Twitter hack of 2020 happened: high-profile accounts such as Joe Biden, Elon Musk, Barack Obama, Bill Gates, Apple and others were taken over due to helpful support staff allowing the attackers to alter the email addresses used to secure those accounts.
• Fail-open behaviour in the authentication process. Access control system sometimes need to fail closed, for example so that no one can sneak in if the system breaks, and sometimes need to fail open, for example so that no one gets locked in during an evacuation emergency. Unexpected reasons for a system to break can lead to incorrect failure modes that leave the system incorrectly configured, such as unlocked for everyone when it should be shut down entirely.

What happened next?

Crypto.com claims that it has “migrated to a completely new 2FA infrastructure”, apparently out of “an abundance of caution”.

We’ve never quite understood what the words “an abundance of caution” are supposed to mean, given that cybersecurity overreactions can be as costly and as counterproductive as underreactions, but it seems to be a must-say phrase in contemporary breach reports, as if thoughtfully taking appropriate precautions is no longer good enough.

After all, if the root cause of your 2FA failure was reason (1) above – an intrinsic shortcoming in the 2FA system itself – then making a root-and-branch change by swapping it for a whole new 2FA technology seems appropriate.

But if the root cause was reason (5) above – support staff too easily able to authorise account resets – then changing the underlying 2FA technology might make little or no difference.

What to do?

• If you’re a Crypto.com customer, you’ll need to re-configure your account to use the new system. Notably, there’s apparently now a 24-hour sunrise period for adding new accounts for balance transfers. This is intended to add extra time for you to spot, or to be warned about, unexpected account changes attempted by crooks.
• If you’re looking at adding 2FA to your own online services, don’t just test the obvious parts of the system. Make sure you consider all points of interaction with the rest of your system, and consider hiring penetration testers to probe for unexpected types of failure.
• If you’re in PR or marketing, make the whole company practise how it will react if a breach should occur. This doesn’t imply you are expecting to fail. But it does mean that if you get caught out, the legally and morally necessary process of communicating with your unfortunate customers won’t suck up planning time that would be better spent on researching and properly fixing the problem.

LISTEN NOW

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT