38
top 20 comments
sorted by: hot top controversial new old
[-] waterSticksToMyBalls@lemmy.world 31 points 1 week ago

Tin hat time! The NSA has a new backdoor rolling out to everyone's phones but they need to reboot for it to finish installing.

[-] Luci@lemmy.ca 9 points 1 week ago

Ha! I refuse to reboot anything

Well now I'm not doing it

[-] GlassHalfHopeful@lemmy.ca 9 points 1 week ago

Doesn't actually describe how it helps...

[-] henfredemars@infosec.pub 28 points 1 week ago* (last edited 1 week ago)

Basically, the secure boot process of your smartphone ensures that only validated software has been loaded. The chip itself validates the bootloader, which validates the kernel, which then successfully forces validation on every app that gets loaded. Most exploits work by corrupting memory or injecting code that shouldn’t be on the system. By rebooting, you are forcing a revalidation of everything that runs, which is going to exclude the attacker’s code unless the attacker can come up with an additional bug to bypass the validation on boot. Any software that doesn’t have a valid digital signature from a trusted source simply won’t get executed.

You can see this in the jailbreak scene on iPhones. Jailbreaks are classified into tethered and untethered categories. A tether jailbreak is such an exploit that can inject code but can’t survive the validation process upon reboot, so it goes away, meaning the user has to tether to a computer and repeat the process every time. Untethered requires two bugs: The bug to inject the code, and the bug that dodges verification and is capable of injecting code when the system is starting. There’s also a class of jailbreak called semi-untethered that goes away when you reboot, but it’s possible to exploit again manually by the user using tools left behind on the phone, but the same basic principle applies that injected code goes away upon rebooting unless you have another trick up your sleeve.

[-] sloppy_diffuser@sh.itjust.works 11 points 1 week ago* (last edited 1 week ago)

GrapheneOS provides an auto-reboot feature which reboots locked devices after a set period of time to put data at rest. A countdown timer is started each time the device is locked, and the device will reboot if a successful unlock doesn't occur before the timer reaches zero.

https://grapheneos.org/features#auto-reboot

Essentially it drops the decryption key derived from your unlock pattern / code. Attacks to access files while the decryption key is loaded, even if the phone is locked, are mitigated. The only things that works after a reboot are phone calls, SMS, and the alarm clock. I have mine set to reboot every 4 hours of inactivity.

I believe this feature is to not only to mitigate your average attacker but also law enforcement threat levels who purchase exploit kits. Can't do much without the decryption key so they are left with slow brute force attacks.

[-] henfredemars@infosec.pub 6 points 1 week ago

I really wish this was adopted as a general Android feature.

[-] unexposedhazard@discuss.tchncs.de 4 points 1 week ago* (last edited 1 week ago)

Pretty sure it is part of AOSP so yeah, if your OS doesnt have it, its because the company removed it. CalyxOS has it too.

[-] GlassHalfHopeful@lemmy.ca 4 points 1 week ago

This has all been a very interesting thread. Thank you. I'm thinking I need to set something up with my phone. It does force the password every 72 hours, but it won't do anything about the boot loader since it doesn't reboot automatically.

[-] henfredemars@infosec.pub 3 points 1 week ago

I wonder why Pixel would remove this feature in that case.

[-] FiskFisk33@startrek.website 5 points 1 week ago

if your phone compromised, chances are the code is running in volatile memory , a reboot would clean such infections.

[-] copygirl@lemmy.blahaj.zone 4 points 1 week ago

My uneducated guess is, some threats will burrow themselves in active memory but have no way of persisting beyond a reboot. Or perhaps it just shuts down background software you don't need that could be vulnerable.

[-] henfredemars@infosec.pub 1 points 1 week ago* (last edited 1 week ago)

This is also true because of fileless malware. Not all malware attempts to write to the disk because it leaves behind artifacts that could get captured or detected. Depending on what the attacker goals are, they may prefer to have the malware simply disappear if memory gets reset.

Or like you wrote it is possible they just didn’t bother implementing a survival strategy because most people don’t reboot their phones very often.

[-] GlassHalfHopeful@lemmy.ca 1 points 1 week ago

Makes sense and gives a compelling reason for regular reboots.

[-] BlazarNGC@lemm.ee 3 points 1 week ago

Still waiting for the reasoning 🤷‍♂️

[-] henfredemars@infosec.pub 5 points 1 week ago

In case you’re still waiting, I made another comment on this post explaining why it makes a difference. It’s a shame they didn’t go into any detail in the article. Best wishes.

[-] BlazarNGC@lemm.ee 2 points 1 week ago* (last edited 1 week ago)

Nice 👍. I’d zap you if we were on nostr ⚡️

[-] henfredemars@infosec.pub 2 points 1 week ago

I do not know what that is but it sounds like a good thing! Thank you!

[-] BlazarNGC@lemm.ee 2 points 1 week ago

https://nostr.org/

You have choice of clients and there’s a lot of “other stuff” than just posts and replies

[-] Rin@lemm.ee 2 points 1 week ago
this post was submitted on 24 Oct 2024
38 points (93.2% liked)

Infosec News

180 readers
58 users here now

A community posting Cybersecurity related articles.

founded 3 weeks ago
MODERATORS