(untitled)

With the recent revelations about the Pegasus spyware, where do we even go from here? You have capabilities that you previously would only have had to worry about being leveled against you if you caught the attention of 1st world intelligence agencies being used by corrupt 3rd world soykaf holes and even cartels in Mexico, and the zero day exploits used for this are going to get a lot more mileage being used by defense contractors on behalf of various groups than if they were just being used by single intelligence agencies. There are already so little controls in place by these defense contractors that the Pegasus spyware has been used to target politicians, journalists, activists, security researchers, and software developers involved in the development of privacy focused software all both in the county's the people paying these defense contractors live in and abroad, and I can only see things getting worse going forward considering there's already a case of a cartel in Mexico having greased the right palms to use it at least once. The implications of getting hit with one of these attacks are also different from a normal hack. Considering this is malware developed by defense contractors who bring in big money rather than just individuals or small groups of people, it's quite possible that we'll see stuff like persistent infections targeting firmware from these defense contractors going forward just like 1st world intelligence agencies have deployed previously, so one slip up on your part and your hardware is toast unless you're running an SBC with no firmware to potentially be flashed and regularly replace your SD card or use something similar to an older Palm device where storage is dependent on a battery backup allowing it to be completely wiped with no flash-able firmware. It seems to me that the only way to defend against one of these attacks is to radically reduce ones attack surface, but given the massive complexity of modern software from developers who are seemingly constantly working to expose more attack surface (just consider the massive number of websites today that are impossible to use without JS enabled even if you're linked directly to the page with the information you want) I'm not sure how possible that would be while continuing to be able to use your device how you'd want.

I don't see how the situation you're describing is novel. Today's intelligence tools are tomorrow's criminal tools. People have been making that argument for about 30 years, since at least the clipper chip. You got to see it a few years ago with the Equation Group leak. The exploits themselves are self limiting. The more exposure they get the less effective they will become. The long-term solution might be provably correct software and treating all devices as hostile.

defense contractor labs are usually closed, meaning that there is no connection at all to any external network, and the electronics you bring in or out are strictly controlled. Even the electricity goes through special filters. My friend works in one. I could ask about it. His personal opsec is pretty soykaf though.

>>16726 Something like Pegasos is new to you? Welcome to the real world, Neo.

>>16729 >You got to see it a few years ago with the Equation Group leak. The exploits themselves are self limiting. The more exposure they get the less effective they will become. The difference here is that everyone had access to the Equation Group leak, allowing for security updates to be made. In the case of Pegasus, the hacking itself is done by NSO so whoever is purchasing it can't look at the inner workings themselves.

>>16726 I did a quick search on Wikipedia page for "software" and found nothing about affected "software developers involved in the development of privacy focused software". Care to elaborate? So far to my knowledge Richard Stallmann remains unaffected /sarcasm

I'm too old to remember Italian company named Hacking Team and their Da Vinci software. 500 gigs of documents. So what? Nobody cares.

>>16737 Probably the guy who started Telegram, but it might be a stretch to call him a software developer. https://www.theguardian.com/news/2021/jul/21/telegram-founder-pavel-durov-listed-spyware-targets-nso-leak-pegasus

>>16739 He's Elon Musk/McAfee/Zogerberg tier publicity figure wiggеr. All software is written by his assburger brother and ghostwriter russian programmers, Pavel only manages mafia bribes and FSB data sharing. >unhackable messaging app >Telegram offers end-to-end encrypted messaging Nice advertising from metropolitan newspaper, quality Bri'ish journalism innit. I'll be repeating words said billion times before me, but FSBgram is not a "privacy focused open source software". Stop believing this nonsense. - It's source code does not reproduce latest binary, it doesn't even adhere to git commit history, they just dump a chunk of files from their servers after some some time and call it a day. They were called out, nobody cares. Unlike Signal they don't even attempt to publish server-side software. - Their version of "end-to-end" is an ugly hack of OTR-like spaghetti functions that requires server-side intervention for key generation. For your privacy of course. Chats are not encrypted with this joke algorithm unless you specifically set them to, and it's only between two devices, one of which can not be a desktop app. Hello, 2006 called. Double ratchet is ratcheting in it's own grave. - Hence 99.9% of all chat history is kept on their servers. Uh, hello datamining department? At least it's not Google Cloud they say, right? - It appeared on hype of Snowden's revelations in 2013 without actually delivering any privacy features (phone numbers are registered with internal passport ID in Russia, and passport is not like SSN in United States anyone can make up from top of their head when applying forms) and a nasty history of "oopsie-woopsie" zero-days, all documented on habrahabr (russian version of hackernews), as a way to transition masses of Russian millenials who already praised him as their god for making a Facebook copy, in year when smartphone adoption rate made evident to focus social application development for, to honeypot Russian users from western messaging applications like WhatsApp, Signal and Tumblr/Twitter microblogs. Imagine Mark Zuckerberg playing a spectacle of "running away from NSA to protect user's fredumbs and privacey" while going to work at his new company office conveniently located on top floor of Facebook headquarters building every day like nothing changed, would you use a super privacy respecting messaging app made by Zuckerberg and Co.? For dull ones not into analogies, while LARPing as government-fighting libertarian buddhist free thinker exile, Comrade Lieutenant Pavel Durov was living in Russia, working in his new Russian registered LLC at the top of Singer Building in Saint Petersburg where VK headquaters are located. Based and Redpilled, roit?

So really the only thing we can do is setup our own xmpp/matrix server.

>revelations As if anything here is new. The only reason there is upset and outrage is because non-peasants were spied on.

>>16747 The only thing we can do is pick a glowie to side with.

Don't use cellphones you fuarrrking idiots. They are inherently designed to track you.

>>16726 What's an SBC anon?

>>16759 Single board computer.

>>16755 Do you think other computers that don't have a cellular connection are incapable of being hacked?

>>16803 cell phones can track you even if they aren't hacked. It's pretty easy to triangulate somebody's position from cell tower pings (unless you're in the middle of nowhere and there are < 3 cell towers in range). The same cannot be said about a typical laptop or desktop.

>>16810 >unless you're in the middle of nowhere and there are < 3 cell towers in range Even a single cell tower can calculate roughly how far away you are and in what direction based on the way your radio waves get distorted over space. https://en.wikipedia.org/wiki/Multilateration#Example_applications Figuring out where you are and compensating for these distortion effects is actually part of the GSM, 3g, 4g, 5g protocols to get better quality service. https://media.ccc.de/v/32c3-7412-running_your_own_3g_3_5g_network

>>16829 If you're being really bad FBI will just stingray you. But yes cell towers allow you to be tracked to within a zip code. Also I wonder about wifi/bluetooth tracking.

>>16848 >Also I wonder about wifi/bluetooth tracking. It's shorter range, but I have heard that some stores log MAC addresses of devices that come within range.

Cellphones are pretty much a lost cause. Until they stop being so idiotic about non-free drivers and non-free firmware, and replace Linux and most of the userland with seL4 and properly-designed userland, respectively, that isn't going to change. Secure isolation by design is now mandatory, and having anything below or within your trusted layer known to be some insecure easily-compromised piece of soykaf isn't acceptable. So the current generation of mobile modems needs to fuarrrk off.

>>16858 >replace Linux and most of the userland with seL4 and properly-designed userland Ah, the seL4 meme. I hear when seL4 is used on phones, it will also be the year of the Linux desktop.

>>16859 It could happen on something like pinephones and other quasi-diy models, but yes, I'm not really hopeful for any sort of industry change. They seem to revel in the insecurity and take it as a badge of pride that their systems can be pwn'd thoroughly.

>>16873 Let's say a phone is produced which runs seL4. What about the baseband layer? https://www.osnews.com/story/27416/the-second-operating-system-hiding-in-every-mobile-phone/ https://threatpost.com/baseband-zero-day-exposes-millions-of-mobile-phones-to-attack/124833/ https://techcrunch.com/2019/11/08/android-baseband-flaws/

>>16874 That is in fact what I meant when referencing the "modem" here >>16858. Effectively it needs to be isolated from other components so that it runs as its own thing, and it should not have a direct communication line to anything, instead using some secure message proxying for microphone input/audio output. Such physical separation of the baseband/modem security nightmare is effectively a fact for the pinephone and librem 5. That should be the case for every single phone.

>>16875 cont I'm envisioning it much like Qubes userspace, where there would be a VM or process (roughly similar isolation security in seL4) responsible for acting as a gateway for every baseband interaction. When the process/vm isn't running, no interaction occurs/it's all denied by default. The main point of making it native seL4 processes instead of VMs is that it'd take significantly less resources to run, security-wise it's supposed to be equivalent.

>>16875 >>16876 seL4 has absolutely no functionality to serve as a 3G, 4G, or 5G baseband. Making it do so would require the addition of *at least* hundreds of thousands of lines of code, with additional hundreds of thousands or millions of lines of proof code. You're dreaming. It's a cute dream, though. Just like it's been for the past 10+ years. >seL4 for servers >seL4 for desktops >seL4 for phones lol seL4 for nothing. Obscure research applications. Join us in the real world whenever you like.

>>16877 Whatever gave you the idea that seL4 itself needs to have anything to manage the baseband? Its role is to isolate software that does have those bits from other parts of the system it should not be able to access arbitrarily with no warning. So you're looking a lot more at something that gets added to whatever already contains those lines of codes so that it proxies what the baseband expects into something managed by other programs running on seL4 with properly controlled message flow. Have you even bothered to read their documentation or lookup how Qubes/Xen does PCI/USB isolation? It's the same idea, except that unlike the Xen hypervisor, seL4 is formally verified.

>>16878 (NTA) >seL4 is formally verified *in part, which is still very impressive

>>16878 >Whatever gave you the idea that seL4 itself needs to have anything to manage the baseband? If it doesn't, then running it at the kernel/userland level is pointless. Baseband firmware is proprietary mysteryware with direct memory access.

>>16885 Yes, which is why physically isolating it is necessary. IOMMU-unconstrained access is simply unacceptable. I am not quite sure how the baseband communicates with the rest of the system. Depending on how stupid the design is, the only option might be introduce a proxy processor with its own small memory running solely the interface/software the baseband expects and software required for communicating with a seL4 process over some serial connection. The seL4 process would then manage the interactions with the rest of the system. This is only if it actually expects some blackbox blob to be running in the main CPU. This depends on just how the insanity is done. If non-integrated rpc-based communication with the baseband is feasible, then all that needs to be done is to run the process responsible for that in an isolated space. If it isn't, then lying to the baseband about it being connected to the main cpu (instead of a proxy) is required.

Israel raided NSO group https://therecord.media/israeli-government-raids-nso-group-offices/ What do you think they found? Or was the malware possibilities too good to pass up. >The raids today are not an indication that the company might have violated its export license, and that Israeli officials are going through regular investigative steps in a case that has received international attention Too much bad press around the world caused the IRL b& hammer to drop. >several news outlets reported that NSO’s customers might have targeted the personal smartphones of several heads of state, including French President Emanuel Macron A private company hacking literal heads of government. We achieved full Neruomancer.

>>16885 >with direct memory access This is not a requirement, just cost cutting. There is no reason you can't separate the baseband out and connect it over some protocol (e.g. SPI) which as others have pointed out has already been done with some phones. Of course the baseband can still do "naughty" stuff like ping towers even when software has turned it off. You can mitigate that by adding the ability to totally cut power to the modem when you don't want it doing stuff, and at that point all the security problems are the same problems as you have from the towers. You're just moving the security boundary from between the phone and the tower to between the CPU and the modem.

>>16907 >This is not a requirement, just cost cutting. And it's not going to change. What is the motivation for companies to redesign their baseband software and go through the difficult FCC certification process again to please a handful of customers who care about this? The whole point of the objections I've made is not to say that cell phones couldn't in theory be made reasonably secure, just that they won't be. Ever. seL4 will never run on a significant number of cell phones, and if it ever runs on a few, it won't be isolated from the baseband.

>>16912 You do know they make self-contained baseband units for IoT electronics that are certified right? Why not reuse those?

>>16913 >You do know they make self-contained baseband units for IoT electronics that are certified right? No. I guess a lot has changed since this question was asked? https://security.stackexchange.com/questions/64337/do-cell-phones-exist-with-open-source-baseband-processors Post links? They have to be open source, of course, or we have no guarantee about any of the claims made about them. >Why not reuse those? Why not, indeed? Assuming these exist, get to work. I look forward to buying an open-source, isolated baseband phone running seL4 (with the proofs extended to cover the new code that will be required to port it) from Cereal Killer Secure Phones, LLC.

>>16914 > They have to be open source, of course, or we have no guarantee about any of the claims made about them. They aren't and they don't have to be if you only care about the claim of them using a specific serial protocol & line connection. So long as it is a connection type that doesn't allow you to casually takeover the rest of your system, it's fine. For that matter DMA is only a problem because of the modem being the master controller in most phones, instead of a slave device subject to proper IOMMU restrictions controlled by the CPU. https://wiki.pine64.org/index.php/PinePhone#Modem https://www.quectel.com/product/lte-eg25-g-mpcie/ The use of /dev/tty2 suggests that it is being connected as little more than yet another USB device to the PinePhone, which is supported by the product page's protocol support claims.

>>16914 > I look forward to buying an open-source, isolated baseband phone running seL4 (with the proofs extended to cover the new code that will be required to port it) from Cereal Killer Secure Phones, LLC. The code managing the device isn't part of seL4, it is a set of programs running atop it in userspace (one connected and directly-exposed server, one control client, talking via rpc). I also wouldn't implement it in C, if I were to do it, so different proof tools would be required (if I proofed). At that point it's just reimplementing the AT Commands for the modem, and the server itself doesn't need to be proofed. Only the client needs to not allow nonsense, since the client is the one actually getting other parts of the system to interact by proxy with the modem-server.

>>16915 >So long as it is a connection type that doesn't allow you to casually takeover the rest of your system, it's fine. If the baseband software is not open source, you don't know that it implements only the functionality that it claims to. So we're back to square one. >>16916 >The code managing the device isn't part of seL4 seL4 is a kernel; in this scenario, it IS the code managing the device (except the cellular hardware, which is what the baseband software is for).

>>16917 >If the baseband software is not open source, you don't know that it implements only the functionality that it claims to. So we're back to square one. You don't own the cell towers right? You don't know that they implement only the functionality they claim to. It's probably best to assume anything you send to the cell tower or give it access to is going to be shared with every foreign and domestic spy agency. The goal is not to stop the cell tower from snooping your data (you can't) but to avoid giving it access to your private data. The baseband is a little chunk of cell tower that lives in your phone. Like the big cell tower, you don't know what it's going to do with any information you give it, so the goal is to give it only the information that you are comfortable sharing. That information is bound for the cell tower anyway, so there is no way you can stop it being snooped. And when you don't want to share anything the baseband should be shut down. Even the most proprietary of software doesn't cause electronics to function without power. In summary, you have no choice but to let the tip in, but just the tip.

>>16917 > If the baseband software is not open source, you don't know that it implements only the functionality that it claims to. So we're back to square one. If you plug it into a PCI<->USB setup, it can't just magically do things that don't work in USB. More so if you use a USB version that didn't support PCIe passthrough at at all (<3). > seL4 is a kernel; in this scenario, it IS the code managing the device (except the cellular hardware, which is what the baseband software is for). seL4 is a microkernel and all it is doing is managing the IOMMU and a few interrupt remapping operations to set up the passthrough to the software actually managing the serial/usb/whatever connection.

>>16918 >You don't own the cell towers right? You don't know that they implement only the functionality they claim to. Irrelevant if you control the baseband software, since you can choose what to send to the tower and what not to accept from it. >If you plug it into a PCI<->USB setup, it can't just magically do things that don't work in USB. Plug what into a PCI<->USB setup? The baseband software? How? I assume you have a working proof of concept? This is just handwaving until you do. >seL4 is a microkernel A microkernel is a type of kernel. >and all it is doing is managing the IOMMU and a few interrupt remapping operations to set up the passthrough to the software actually managing the serial/usb/whatever connection. Ez pz. Get on it and let us know when you spin up mass production of the Dozer Secure Phone, LLC secure phone.

>>16920 >Irrelevant if you control the baseband software, since you can choose what to send to the tower and what not to accept from it. Sure, but you don't control the baseband software. And it's unlikely you will unless you're willing to risk the FCC shooting your dog or whatever it is they do to people that run unapproved baseband firmware. This is an alternative way of accomplishing the same thing. It's like sticking a nice pfsense router with VPN in between the soykafty modem the cable company gave you and your real network - the cable modem is just there to shuffle data back and forth, it doesn't need to have unrestricted access to your network. >Plug what into a PCI<->USB setup? The baseband software? How? USB modems have been a thing for a really long time.

>>16921 >Sure, but you don't control the baseband software. Learn to follow the conversation, champ. That's what I've been saying all along.

>>16920 > Plug what into a PCI<->USB setup? The baseband software? How? I assume you have a working proof of concept? This is just handwaving until you do. Right, my bad there, that's a feature of mPCIe that PCIe itself doesn't have.

>>16726 The problem isn't a technical problem but a political problem that is actually quite old. Its "The Military Industrial Complex" again . Private Companies are producing software for Intelligence agencies, but, they are private, and are seeking to expand their sources of revenue. Because they are private, and there isn't any particular regulation on these technologies (which I don't want anyway), they can and will sell them to abusive actors. The danger is that intelligence agency grade tools are being sold to anyone. The obvious solution to this problem is such a poison pill, I hope it never happens: You could make various types of software illegal to distribute or possess or w/e. Some restrictions already exist inside the US under the DMCA to prevent reverse engineering and creation of tools that effect DRM. What happens when congress makes opensource port scanners or metasploit illegal? An alternate approach, is perhaps to destroy the market, by mandating that the intelligence agencies fund the creatation of their own tools, or purchase rights exclusively. This may drive up cost, or prevent acquisition of competative capabilities - IE. opposing state buys all tools/vulns/exploits non-exclusively, and you have nothing. Its already illegal for the cartel to hack a journalists phone and listen in. They don't care.

>>16923 >That's what I've been saying all along. Yes you've been repeating it over and over when it isn't going to change, while ignoring/doubting the existence actual solutions which already exist. The closed source software is a legal/regulatory problem and not a technical problem. There have been proofs of concept of alternate firmware and SDR decoders. You will never be able to buy a phone with these legally.

>>16930 >The closed source software is a legal/regulatory problem and not a technical problem It doesn't matter what kind of problem it is. It's a problem. >You will never be able to buy a phone with these legally. Correct. Which means none of the people in this thread will ever own one and all of the proposed "solutions" are at best idle fantasies and at worst an obnoxious LARP. Sing it with me, kids. From the back to the middle And around again I'm gonna be there till the end 100% pure LARP

>>16933 > pinephone > idle fantasy try harder plz

>>16933 >It doesn't matter what kind of problem it is Because a problem that is against the laws of physics is exactly the same as a problem that is against the laws of the united states. >none of the people in this thread will ever own one Just because you can't buy a pre-flashed device doesn't mean you can't buy stock and then flash it yourself. What do you think the Osmocom people have been doing all these years. >Sing it with me, kids. >kids Always accuse others of what you are guilty of yourself.

>>16935 >pinephone >uses the Quectel EG25-G >this runs a proprietary, closed source OS >it is supposedly isolated from the rest of the phone through USB but >because the baseband is closed source it could be issuing commands that pinephone developers didn't anticiipate >over USB >which has direct memory access womp womp >>16936 >Because a problem that is against the laws of physics is exactly the same as a problem that is against the laws of the united states. I don't recall anyone saying that it couldn't be done. Just that it won't be.

>>16937 > issuing commands that pinephone developers didn't anticiipate Solution: Whitelist commands that you deign to respond to. Magic. *jazz-hands* The easiest way to deal with the unexpected is to only allow the expected. >over USB which has direct memory access > womp womp Only from v3 and up (it's v2 if you didn't notice), and it's not a mandatory part of the spec, so you can find controllers that do not implement it. At that point the only part where that's a problem is if the controller itself is vulnerable and gets pwn'd. Mind you that's simply an argument for the proxy-cpu & serial communication if you were to use a USB version that cannot be easily locked away from that. Of course it's probably easier to just find another baseband unit that is directly compatible with SPI or some other serial connection.

>>16939 >Magic. *jazz-hands* Okay, I imagined Krieger from Archer saying that, which is funny and takes some of the sting out of admitting you're right. I guess it should have been obvious to me that the developers of the layer above the baseband wouldn't ack unexpected commands, and that a compromise would depend on the baseband exploiting a flaw in the USB hardware or driver. Which isn't a problem with the security model per se.

>>16940 Yep. Technically driver failure can be isolated by the OS as well. Firmware/hardware failure in the controller cannot, which is one of the aspects that make me somewhat leery of having it use something as complicated as USB instead of something simpler.

>>16943 continued Although this also depends on just how USB is implemented on the host side. If they went with PCI-connected USB controller for ease of implementation, then it represents a non-neglectable risk.

Those USB LTE modems run full-blown Android these days. You'd expect them to be itty bitty devices like SDIO cards 10 years ago: cheap low-power hardware, a real-time OS that interacts with drivers, or at most OpenWRT-like router firmware with webpage and virtual Ethernet, but no - it has to be Android, dinosaur versions with lots of exploits to attack from cellular network of course.

>>16950 Yikes, I have no idea how that was ever thought to be a good idea. That's basically going "lol, let's maximize attack surface as much as possible".