401–410 of 424 posts
Is there a way I can install an open source phone OS on my old Android phones to keep them patched? I'm not prepared to keep buying new phones just because manufacturers only provide intermittent updates for a year or two. Anyone got any suggestions for options?
Also fairly actively developed and supports a wide range of devices.
Earlier quoted context omitted.
Not quite: The attacker watches for the initial client->AP encryption negotiation (or forces it by forcing a disassociate), records one step of that negotiation and replays it to the client. That has the side-effect of causing the client->AP traffic to re-use encryption keys. Since WPA2 encryption is a stream cipher, re-using keys opens it up to a known-traffic analysis attack, which allows a listener to decrypt the…
>There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients. How would you drop packet 3 without a new AP?
Earlier quoted context omitted.
SafetyNet doesn't actually detect custom ROMs, a stock LineageOS will pass it on most devices at least. It attempts to detect root or modifications to the ROM by malicious software. Certain newer devices have secure boot attestation that may cause SafetyNet to fail unless spoofed to be a different device which does not have such attestation.
It also detects unlocked bootloaders, even if nothing is modified. And you need either root or an unlocked bootloader to make proper backups.
Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
Earlier quoted context omitted.
It also detects unlocked bootloaders, even if nothing is modified. And you need either root or an unlocked bootloader to make proper backups.
No. It only cares about unlocked bootloaders on devices that shipped with Android 7 because a requirement of shipping with that was hardware support facilitating dm_verity, which is essentially a check that the bootloader wasn't tampered with. Without the necessary hardware there's simply no way to perform this check in anything resembling a reliable fashion. Also, neither root not an unlocked bootloader is required…
So in other words "yes, that is a requirement that will eventually be on all android phones"? Am I misunderstanding something? Older phones being an exception does me little good going forward.
> Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.
The last time I tried adb backup and restore, it was a mess. Multiple apps like Skype had no data. And authenticator explicitly opts out of being backed up.
Titanium backup, on the other hand, works perfectly.
Ideally I would just have a rooted phone, but then safetynet complains, and I can't even use Netflix and pokemon. As an alternative I could accept an unrooted but unlocked phone, and root it only when making and/or restoring backups. But having neither is a big hassle.
Earlier quoted context omitted.
The thing is, not every protocol offers TLS. Take SMB (network shares) for example... encryption is only offered as of v3 and if a company/university wants to allow Windows 7 clients, they're capped to SMB v2.1.
That's a good example. I guess there's other mitigation at work here. In my case if I'm in a public wifi area and connecting to my work PC then I'm using VPN to access smb. Smb just isn't open to the wifi attacker. In a case that it is, its curious how you would inject data into a smb stream and not fail checksums from client-side chechking. Maybe its trivial to deal with this, not sure. If the WPA2 protected wifi ne…
Earlier quoted context omitted.
>There's no need for a second AP in all this, just someone in range of the client who can replay packets to the clients. How would you drop packet 3 without a new AP?
You don't. You record it and replay it. You want the client to get the same packet 3 over and over.
> Note that the adversary cannot replay an old message 3, because its EAPOL replay counter is no longer fresh.
And a related update from the TLDR post you originally referenced (which I believe is causing confusion):
> Update: An early version of this post suggested that the attacker would replay the message. Actually, the paper describes forcing the AP to resend it by blocking it from being received at the client. Thanks to Nikita Borisov for the fix.
Earlier quoted context omitted.
Pray for a vendor patch. The fix landed today in the hostap repository: https://w1.fi/cgit/hostap/commit/?id=a00e946c1c9a1f9cc65c729...
Does this resolve the issue on the AP side of things? Could I theoretically have an AP update that would resolve this with no need to update clients?
[0]: "Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!"
[1]: "you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming)."
Earlier quoted context omitted.
Can one install their own web rendering engine on iOS?
In principle yes (if it is not against the app store guidelines). But if submitted as an app, it cannot use JIT compiling for security reasons. This will make the speed of JavaScript execution very non-competitive to WebKit.
Apps should be self-contained in their bundles, and may
not read or write data outside the designated container
area, nor may they download, install, or execute code,
including other apps.
And section 2.5.6:
Apps that browse the web must use the appropriate WebKit
framework and WebKit Javascript.
As far as I can tell, you can install a web rendering engine that is not the built-in WebKit, as long as you only use it for HTML/JS that come with your app. At that point the JIT caveat applies.
Matthew Green's blog on why it happened and how it escaped detection is a really good read. https://blog.cryptographyengineering.com/2017/10/16/falling-...
"One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access." While I'm sure this can't take much of the blame, it sure strikes a chord. The IEEE standards process seems insanely archaic and broken in the open-source era.