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.
We’re well off the original issue here which, no harm repeating, we’ve established isnot a real problem. So we’re not debating that, but loose grand generalities. Still, that’s fun and evidently you triggered me so:
Important security fixes come on a timescale of ~ a day, which means unpatched is not an unusual case (I even had to restart my browser because of an update while I was writing this!). The details you mention here don’t change that. You say that often you need two problems - whether bugs or alleged user misbehaviour - but since the problems are so frequent, that still results in frequent opportunity. We mostly rely on the threat of punishment and the fact that not many people want to harm others in the first place to prevent this actually happening more often.
The conventional wisdom is that the scale of the current red-queen bug-patching race is inevitable, but the truth is better than that! Security failures are inevitable, but our systems don’t need to be anywhere near as fragile to them as they are.
I guess that machine learning may make this situation more pressing. It will also change defences: Some sort of arms race is inevitable, but the scale of it is not. For that reason, neither is embedding authoritarian solutions to these problems in our society inevitable. I imagine “we have to run Google AI software on all your devices, else you’ll be vulnerable to AI attacks” is coming not so far in the future unless we take steps to prevent it.
I imagine you must intend this as advice for an individual who expects to be the subject of a targeted attack from somebody with large resources AND believes they can only solve their problems all at once – fair enough (though even from an individual point of view I don’t think that’s the only relevant situation). Looking at it from another direction though, the idea “Many things need fixing to fully fix this problem, therefore we should not fix the problem” is also a general-purpose means of making security (or anything else) incrementally worse. We should make it incrementally better instead. That works! We shouldn’t expect it to work immediately, fully, and just for us as individuals.
You might say you don’t adopt the “progress is impossible” attitude to security I describe above: fine, but that has in fact broadly been the attitude of the IT industry, which has caused us not to make any. That attitude is often defended in terms similar to what you write above (or the broader view of the problem is systematically neglected).
All those things you list can and should be fixed. At the moment, fixing this kind of very basic security issue (not this one in particular!) often requires inordinate, punishing effort and is prone to failure. There’s no fundamental reason for that, and it creates dangerous instability in our society, risk to individuals, and lost opportunities for co-operation, so it should be our goal to change that. It’s possible (and hard) to make real incremental progress in security, without trying to do so by making changes that only address individual bugs. The way to do that is to make the effect of bugs less severe, using the principle of least authority – this issue we were talking about is an example of that (again, my position from the start is that “can turn speaker into mic given root” isn’t the most important such issue right now!).
Incidentally: I’m not going to comment much about my own personal security but I do expect that people here are much more like than average to actually take action on all the things you list, and I don’t think success at reducing risk on the individual level is all-or-nothing either (not even if we’re talking about the state, which effectively does have limited resources in many cases, for now at least).
This is very much standard “IT professional” fare again but I think there’s a lot missing from that, in our different context here:
Use of hand-planted bugs is quite defensible, because they’re expensive and come with social / political / legal norms that restrict their use, mass surveillance by local or foreign governments, activist groups, etc. less so (even companies, who haven’t been entirely innocent of going to those lengths, and are more “your data is our data” every day)
“unless your physical security is as good as your ITC security” – but these two categories of risk aren’t simply comparable in this way. Again, local physical security isn’t fragile in the same way to, for example, a large-scale attack using machine learning-derived exploits
As above, it neglects progress (or decline) and the context outside of individual people, companies, etc. Optimizing for one company, or one person, etc. is what an IT person does, but people whose motivations have a larger context (like us, I’d like to say) do need an eye on making larger scale progress. Contrary to popular opinion, I think that usually involves people working on things that are not local optimisations (again, I mean that the standard “oh, it’s naive to want to improve that, because this other thing is just as bad” hinders progress).
Really? In what sense? I thought Linux is the most secure, especially PureOs. iOS has a great vulnerability which cannot be fixed and it is called “Apple”.
Yes, I suggested that most likely the “criminal” is your own government, for this scenario - so both targeted and large resources. There is of course no certainty in that.
Random criminals are mostly looking at identity theft and/or ransomware and/or financial theft. Random criminals targeting real microphones or repurposed speakers would I think be a niche activity against the average home user. Maybe you can imagine a scenario involving extortion (blackmail) but how many houses would a criminal have to compromise a microphone in and how many hours of recording before finding something that will yield a payoff?
Not exactly. I was just pointing out all the real microphones that might be in your house already. I consider it more important to address all those real microphones, which don’t require fancy repurposing of speakers that may or may not even be possible.
Sure, that’s a judgement call as to which is higher priority.
I guess I’ve already commented at painful length about this, so I won’t repeat it!
For an individual’s own particular security, yes, I think so – but the inability to immediately solve a large problem in one piece doesn’t mean we – especially as a group – should rate the value of solving parts of it at zero. As I said, whatever your particular view about that, what you said about it is commonly used in defence of (unwarranted) pessimistic positions about security that claim (wrongly) that the sophisticated position is that we should continue to make it worse.
so: