Edit: turns out this isn’t a vulnerability affecting the Librem 5
As I understand it, speakers can easily be retasked in software as microphones, given root access: https://arxiv.org/ftp/arxiv/papers/1611/1611.07350.pdf
To be clear: a mic killswitch is still an advance over no killswitch, because it means software not running as root can’t directly read audio.
The librem 5 doesn’t have any countermeasures for this, as I understand. Seems like for that reason the “kill switch” is likely not effective against root exploits, which Linux is arguably relatively vulnerable to compared to iOS for example.
(the “just avoid being hacked” advice from the third thread there I think is of limited usefulness to be honest: exploits will leak the data on your phone, but not the 24x7 audio, if the 24x7 audio isn’t available)
The solution discussed in the first of those was “add another kill switch” – but the paper discusses other countermeasures, and I can imagine others:
From the paper: Add an amplification circuit to make the overall system one-way even when the DAC/ADC circuit is reconfigurable in software.
Are there DACs/ADCs that aren’t reconfigurable in software like this?
I also wonder if a solution on the level of “wrapping” the sound circuitry on the hardware level to prevent it from switching output DACs to function as input ADCs is practical (but I know nothing about this!).
A bit way-out-there at the moment I think, but: Reliable software: have seL4 look after hooking up these inputs and outputs. A lot of work to do on a lot of different levels to make that function I’m sure, but extremely worthwhile work for the goals of this community I think because it benefits all kinds of security goals, not just this one. Any progress here may well eventually get picked up by people investing for mainstream purposes, which potentially boosts the effectiveness of investment by us hugely. And I’m sure there are other and intermediate goals along these lines (seL4 and capability security), even if it’s difficult work. Would love to support this in my small way!
Are any alternative solutions to adding another killswitch – like those above – practical in the near/medium term? If not, why is that and how could steps be taken in that direction?
I contest that this isn’t exactly an “easy” thing to do. And while I’ve seen POC material that’s hardly proof of viability.
On top of that, if a threat actor has targeted you with the sophistication gained root access to your system, with the intent of re-purposing the speaker as a microphone the repurposing of the speaker is likely the least of your concerns.
Also, generally there are much easier ways to listen to a target than using their own hardware against them.
That sounds like great news! Then probably I misread Todd’s post here, which seemed to suggest it’s a potential issue? (maybe it’s about another Purism product? or just out of date? or I just misunderstood what he said completely?)
What makes you say root access needs a lot of sophistication? I don’t work in security, but my understanding as a programmer who’s paid some attention over the decades is they’ve been basically routine my whole career. Rust seems to be starting to make a dent though!
I don’t know how to respond to this without more specificity than “viability” and “easy”
For sure it’s harder than “all apps can just read from the mic”, which is a big step up, I agree there!
For sure this is often true, but it depends on the threat model of course – I’m sure you’d agree. Fragile software – which is what we have (not Purism’s fault!) – creates a fragile situation in which, some combination of both large scale and cheap exploitation is possible.
This in part is on my poorly worded statement. I’m saying the combination of gaining root access and exploiting the speaker as a microphone is sophisticated.
Though most exploits to get root access are also sophisticated or need to be paired with a sophisticated attack to get access before using an easier exploit for privilege escalation.
If it were truly easy to gain root access to systems they’d all be compromised all the time. Instead most systems are compromised by getting the human to hand over legitimate creds then getting lucky that there are bad patching policies (or no policies at all) and utilizing an old unpatched exploit. That however tends to be the result of a very targeted attack which is outside most people’s threat model.
Sure, there are exceptions to all of everything. But the point is, gaining root access to a remote system via technical exploits alone is generally not an easy task and is actually quite difficult. Adding the difficulty of utilizing root access to reverse the speaker to behave as a microphone and record that information then exhilarated that information all without impacting the user in a way that is noticeable is not easy at all.
Might there be some threat model where this is relevant, sure I won’t say it’s impossible… but it’s going to very much be the exception.
I find software to be much less fragile and rather that there is loud noise made about theoretical exploits that often have pre-requisites that are worse than the “exploit” itself, such as this case where the exploit of the speaker is dependant on having root access.
I don’t think ability to configure jack routing or to pass unamplified speaker lines as audio input is very common on such platforms. It’s only common on laptops because these days they often combine functionality like stereo line-in into a single jack together with headphone output, so it’s an intended feature there.
There have indeed been many Linux exploits over the years that would in theory get root access. However you then have to filter out those exploits that won’t directly work in your specific environment e.g. because you don’t even have the vulnerable software installed or it is installed but is not in use (and needs to be in use in order to be exploited) or e.g. because it’s a privilege escalation vulnerability that needs authorised unprivileged local access in the first place (and hence requires a blended attack to work against at least some home users).
Yes.
If your attacker even wants to listen to you then your attacker is most likely a government. If it’s your own government then most likely they can install a dedicated bug (i.e. they have the lawful authority to do so, and they have the expertise to do so, and they have the access to do so) - unless your physical security is as good as your ITC security.
(The one obvious exception to the claim in the previous paragraph would be if there is someone with a personal vendetta against you, including some kind of domestic violence / coercive control situation.)
Even if using your own hardware against you, these days you had better make sure that you have covered all the other points of listening e.g. mainstream (spy) phones, TVs, networked surveillance cameras, home automation devices, smart speakers, … Basically you would either need to be low tech or you need a wholesale purge of technology.
We’re discussing the librem 5, which has a kill switch. (but again for bystanders: we’ve established the librem 5 is not affected by this problem)
If you’re talking about other devices: “Many things need fixing to fully fix this problem” is a general-purpose argument in favour of making security (or anything else) incrementally worse. We should make it incrementally better instead.
The context was that there’s a killswitch for the microphone but not the speaker so theoretically bypassing the killswitch by using the speaker as a microphone.
Won’t work for the Librem5 but may theoretically work with some device somewhere.
See the top right of my post to see the post I’m replying to (gavaudan not you). This one won’t have a link to where I’m replying because it’s to the most recent post in the thread.
My point was more that if someone was going to be listened to, there is almost always a microphone nearby. I guess I would go so far as to say worrying about the speaker would be a waste of time, but going there isn’t within the scope of this thread since I now understand we’re talking about L5s.
Yes! Let’s make it so it doesn’t matter that there’s almost always a microphone nearby! We can do that incrementally!
“There’s always a microphone nearby, so it’s inevitable we’ll make no progress in microphone security” is just a recipe for not making any progress there, and isn’t true.
I wasn’t saying that, if that’s what it sounded like. Just that microphone security ought to take precedence over speaker security (because, where there’s a speaker there’s a microphone [generally] which would be easier and more effective to take control over in order to listen to someone).
Priority 1: Get rid of all actual microphones (or at least give them hardware kill switches)
Priority 2: Deal with some speakers that might under some attack conditions be able to be repurposed into becoming microphones.
But you basically said that subsequently.
To look back at the original comment, I don’t think it would be reasonable to make the microphone kill switch also kill the speaker - so that might leave you with a solution of adding a fourth kill switch and Purism has somewhat indicated that they wouldn’t want to do that (for usability reasons).
So the best option in this case, as implemented in the Librem 5, is that the hardware doesn’t support that repurposing.
