How will patch for wpa2 (krack) happen if at all? - Galaxy Tab S Q&A, Help & Troubleshooting

With this recent scare regarding the wpa2 vulnerability I was wondering if the fix would be in firmware or software.
Obviously for rooted devices without ota and Samsung possibly not interested (conveniently) in updating these 1st gen devices we could be stuck with this vulnerability. I'd be Interested in the thoughts of other owners.

You gotta be kidding me. Of course, Samsung has already washed its hands of this tablet. If we stand a chance of patching this problem, it's from the open source community.

All of the tab s varients do not have security patch updates, and no plans ever to introduce.
Here is the list of Samsung devices with quarterly or monthly updates
https://security.samsungmobile.com/workScope.smsb
AOSP/LIN should be applying security updates when available. But this is only for their current projects, they don't seem to maintain "stale" branches.
Is there an effective patch available ? MS claim to have patched, but remains to be seen, as has been stated its a deep vunrability.
I am waiting to see the patch war that will follow, if its a true problem in the wpa standard we will get a series of software firmware patches, each being breached in turn, untill everyone is forced to switch to a new standard. Anyone remember WEP? Lol.
If its not a real standards issue, we will see an effective patch within a month, Google are only behind the Linux kernel project in their responsiveness, and that's a compliment.

The sad reality is that Google itself hasn't made a coherent statement regarding what is it that needs to be patched. Is this a package that's part of the Android OS, the Linux kernel, or is this something that can be pushed through Play Store updates? According to the security advisories, a whole lot of Linux distributions deal with this security problem by updating the wpa_supplicant package. This package being open source clearly can be updated with root. So all we need is a flashable zip file, or just plain binaries that can be put in place.

As an update to last post
Its not that searious at all, not embedded in the standard, will not require hardware or firmware updates. A simple software patch will do.
Google have already patched it on 16th October, omnirom on the 23rd. Google released patch in Nov 6 security patch level update.
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
So that means Linage should also be patched if they merge security patches monthly.
For my Fenris Rom project I am desperately trying to port large sections of the tab s 2 refresh frameworks and binaries, which does get monthly security updates. Not an easy job, and that's going to be for the T705 only.

Related

Some questions about Lineage OS security and their CVE tracker

Hi XDA!
I have some questions about the current security level of Lineage OS and CVE info!
For example: Xiaomi / msm8956 has a 69% security and it's still vulnerable to the vulnerability of Broadcom Wifi-Driver and many more. (According lineage OS CVE tracker)
Is that the real status of security patches? Or are some of these vulnerabilities already patched?
who is responsible of patching this? Device maintainer? Manufacturer (Xiaomi)? Google with your security patches?
I just want to know how this works and who's in charge, I'm not judging anyone's work.
I just want to how this works and who's in charge, I'm not judging anyone's work.
Thanks for your help and time!
MrEncrypted said:
Hi XDA!
I have some questions about the current security level of Lineage OS and CVE info!
For example: Xiaomi / msm8956 has a 69% security and it's still vulnerable to the vulnerability of Broadcom Wifi-Driver and many more. (According lineage OS CVE tracker)
Is that the real status of security patches? Or are some of these vulnerabilities already patched?
who is responsible of patching this? Device maintainer? Manufacturer (Xiaomi)? Google with your security patches?
I just want to know how this works and who's in charge, I'm not judging anyone's work.
I just want to how this works and who's in charge, I'm not judging anyone's work.
Thanks for your help and time!
Click to expand...
Click to collapse
I've heard that they have to input all that manually to make it up to date. So it's basically way of date most of the time.
Sent from my XT1650-03 using Tapatalk
swejuggalo said:
I've heard that they have to input all that manually to make it up to date. So it's basically way of date most of the time.
Click to expand...
Click to collapse
Yes the main page of Lineage OS CVE Tracker says that they have to update the info manually.
I want know who's in charge of patching the vulnerabilities!

Is there a way to update the android security patch of a ROM easily yourself?

Not a developer, but wanted to use an AOSP CAF 7.1. ROM I found. Problem is, the android security patch is way back in July. Any way for me to update it myself?
Fork the source,sync it,patch it and compile by urself.I don't think there is a single method easier than this...

[UNOFFICIAL][MAGISK MODULE] Active Edge Mod for Edge Sense Plus - continuation for patch levels 2021-01-05 and later

EDIT: It's too annoying to maintain and edit 6 separate threads. The installer works across all devices, so please visit this post for the latest version: https://forum.xda-developers.com/t/...or-patch-levels-2021-01-05-and-later.4226343/
Thanks!
NOTE: Download link in the OP will install mod for the current patch level down to January 2021. It will detect your current patch level and install the correct file. For earlier system builds from 2020 and prior, please use the official discontinued module on the Magisk Manager repo. I did not clone the entire Active Edge Mod repository; my unofficial repository only hosts January 2021 and later builds.
Changes:
I know, I know... I said I was done with releasing my Unofficial Active Edge Mod installer, yet here's another month's update. I might keep doing it for those that update immediately and want it a bit sooner, so long as it's fortunate enough to happen on a day when I'm able to do it relatively quickly. Since I'm building these anyway and sending them over to the dev, for now, to upload to the official Magisk repo, for now I don't mind also updating it here a bit sooner. Anyway, more on this below and some of the headache involved moving forward...
04-05-2021: Soooo... the script I wrote to churn these out as quickly as possible as Google releases the updates, relied on system image dumps on GitRip... unfortunately the domain was seized by the FBI (lol) and so it looks like the old dumper is no longer updating his Android dumps repo on GitRip. Fortunately, mikalovtch pointed me over to a new source that hosts such system dumps, and I was able to get these done relatively quickly afterwards. OP is updated with the 04-05-2021 installer now!
03-02-2021: Meant to post an update a week or two ago. Noticed the magisk module on the official Magisk repo now says [RE-CONTINUED], so there really isn't much need for me to continue updating this anymore! As a final gift, I ran my batch builder script and built the modded apk's for all variants for the 2021-03-05 patch level, and download link for the module installer is in the OP.
02-02-2021: February 2021 mod is now uploaded. Updated installer is in the link in the OP.
02-01-2021: Modified and uploaded modded SystemUIGoogle.apk files for 3 / 3 XL / 3a / 3a XL to GitHub repository. Updated Magisk installer slightly to accommodate this, and removed a few unnecessary lines. Won't make any difference if you already installed the first release.

Assessing binary blob patch level

Dear community,
I am wondering how to assess the security of needed binary blobs for lineageos. As far as I understood there is no possibility to update these blobs, when the device becomes unsupported by the vendor.
So this proprietary code would be a weak attack surface, or? At least when some of the code runs in priviledged mode, it seems to be dangerous...
I only have found this aged presentation on how to assess the security of these blobs, is there any newer stuff, or some standardized methodology for doing this?
https://recon.cx/2013/slides/Recon2013-Joshua%20J.%20Drake-Reversing%20and%20Auditing%20Android%27s%20Proprietary%20Bits-public.pdf
I think there should be warnings for using blobs that are known to have security relevant bugs...

Development [ROM][13][UNOFFICIAL][Raven/Oriole] Magisk Patched GrapheneOS + Lockable Bootloader

Magisk Patched Unofficial GrapheneOS for the Pixel 6 / 6 Pro (oriole/raven)
This ROM will allow you to lock the boot loader. Do not ever disable the OEM unlocking checkbox when using a locked bootloader with root.
This is critically important. With root access, it is possible to corrupt the running system, for example by zeroing out the boot partition.
In this scenario, if the checkbox is turned off, both the OS and recovery mode will be made unbootable and fastboot flashing unlock will not be allowed.
This effectively renders the device hard bricked.
I am not responsible for any harm you may do to your device, follow at your own risk etc etc, Rooting your device can potentially introduce security flaws, I am not claiming this to be secure. If you would like to have more security and peace of mind then I highly recommend you follow This Guide to build this rom using your own encryption keys.
GrapheneOS is a privacy and security focused mobile OS with Android app compatibility developed as a non-profit open source project. It's focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. It was founded in 2014 and was formerly known as CopperheadOS.
The features page provides an overview of the substantial privacy and security improvements added by GrapheneOS to the Android Open Source Project (AOSP). Many of the past features were contributed to AOSP, Linux and other projects to improve privacy and security for billions of users so they're no longer listed on the features page.
More info:
Official releases are available on the releases page (Not Magisk Patched) and installation instructions are on the install page.
GrapheneOS also develops various apps and services with a focus on privacy and security. Vanadium is a hardened variant of the Chromium browser and WebView specifically built for GrapheneOS. GrapheneOS also includes our minimal security-focused PDF Viewer, our hardware-based Auditor app / attestation service providing local and remote verification of devices, our modern privacy / security focused camera app, and the externally developed Seedvault encrypted backup which was initially developed for inclusion in GrapheneOS.
No Google apps or services​GrapheneOS will never include either Google Play services or another implementation of Google services like microG. It's possible to install Play services as a set of fully sandboxed apps without special privileges via our sandboxed Google Play compatibility layer. See the FAQ section for more details on our plans for filling in the gaps from not shipping Play services and Google apps.
Installation Instructions: Fashing-factory-image
Locking the bootloader is Optional but does increase the device security Locking-the-bootloader
Update Instructions: simply follow these instructions Updates-sideloading to sideload the latest patched OTA update package (You can update from any previous version if using full ota update)
Android OS Version: 13
Current Version: See Post #2
Download: See Post #2
Sources: GrapheneOS - AVBRoot - Magisk - Patch Guide
PayPal Donation Link
Builds for Pixel 6 Pro (Raven)
Magisk-Patched GrapheneOS Factory Install Build
Full system install builds for clean and new installs
Build based on release#2023061402 (2023-06-14)
SourceForge_Download
Build based on release#2023050100 (2023-05-01)
SourceForge_Download
Build based on release#2023041100 (2023-04-11)
SourceForge_Download
Build based on release#2023032000 (2023-03-20)
SourceForge_Download
Build based on release#2023022300 (2023-02-23)
SourceForge_Download
Build based on release#2023020600 (2023-02-06)
SourceForge_Download
Build based on release#2023020200 (2023-02-02)
SourceForge_Download
Build based on release#2023012500 (2023-01-25)
SourceForge_Download
Build based on release#2023011000 (2023-01-10)
SourceForge_Download
Build based on release#2023010300 (2023-01-03)
Anonfiles Download | 1fichier Download | SourceForge_Download
Build based on release#2022122000 (2022-12-20)
Anonfiles Download | 1fichier Download
Build based on release#2022121400 (2022-12-14)
Anonfiles Download | 1fichier Download
Build based on release#2022121100 (2022-12-11)
Anonfiles Download | 1fichier Download
Build based on release#2022120300 (2022-12-03)
Anonfiles Download | 1fichier Download
Build based on release#2022113000 (2022-11-30)
Anonfiles Download
Build based on release#2022112500 (2022-11-25)
Anonfiles Download
Build based on release#2022111800 (2022-11-18)
Anonfiles Download
Build based on release#2022111000 (2022-11-10)
Anonfiles Download
Build based on release#2022101800 (2022-10-18)
Anonfiles Download
Click to expand...
Click to collapse
Magisk Patched OTA Update packages
Full OTA Builds will let you update from any older version
Patched OTA based on release#2023061402 (2023-06-14)
SourceForge_Download
Patched OTA based on release#2023050100 (2023-05-01)
SourceForge_Download
Patched OTA based on release#2023041100 (2023-04-11)
SourceForge_Download
Patched OTA based on release#2023032000 (2023-03-20)
SourceForge_Download
Patched OTA based on release#2023022300 (2023-02-23)
SourceForge_Download
Patched OTA based on release#2023020600 (2023-02-06)
SourceForge_Download
Patched OTA based on release#2023020200 (2023-02-02)
SourceForge_Download
Patched OTA based on release#2023012500 (2023-01-25)
SourceForge_Download
Patched OTA based on release#2023011000 (2023-01-10)
SourceForge_Download
Patched OTA based on release#2023010300 (2023-01-03)
Anonfiles Download | 1fichier_Download | SourceForge_Download
Patched OTA based on release#2022122000 (2022-12-20)
Anonfiles Download | 1fichier_Download
Patched OTA based on release#2022121400 (2022-12-14)
Anonfiles Download | 1fichier Download
Patched OTA based on release#2022121100 (2022-12-11)
Anonfiles Download | 1fichier Download
Patched OTA based on release#2022120300 (2022-12-03)
Anonfiles Download | 1fichier Download
Patched OTA based on release#2022113000 (2022-11-30)
Anonfiles Download
Patched OTA based on release#2022112500 (2022-11-25)
Anonfiles Download
Patched OTA based on release#2022111800 (2022-11-18)
Anonfiles Download
Patched OTA based on release#2022111000 (2022-11-10)
Anonfiles Download
Patched OTA based on release#2022110800 (2022-11-08)
Anonfiles Download
Click to expand...
Click to collapse
Builds for Pixel 6 (oriole)
Always do a backup of your data before flashing any updates, just in case.
I make no promises that this works or that I will provide regular updates. I will attempt to provide updates when they are available and I have time, you may have issues with this rom, you could lose your data or brick your device (although it's very unlikely if you follow the instructions and use common sense)
#Reserved
Isn't there already an official build for graphene for Raven?
iBe.Jacob said:
Isn't there already an official build for graphene for Raven?
Click to expand...
Click to collapse
Yes. But not for a rooted version of it.
New Release 2022111800
Changes since the 2022111000 release:
don't skip ahead-of-time (AOT) compilation of apps that weren't recently used since we depend on full AOT compilation being done for performance rather than JIT compilation with background JIT profile guided AOT compilation like Android
battery usage UI: use fallback name for unknown components
change minimal value of battery saver schedule to 5% again as it was before Android 13
enable the post-upgrade "Optimizing apps" progress indication UI
app crash UI: show process uptime and optional extra text
Sandboxed Google Play compatibility layer: show version of GmsCompatConfig in the crash UI
Sandboxed Google Play compatibility layer: stop splitting multi-package PackageInstaller sessions
Sandboxed Google Play compatibility layer: improve handling of activity starts
Sandboxed Google Play compatibility layer: bugfix: Parcel position wasn't reset by dynamic stubs
Sandboxed Google Play compatibility layer: bugfix: missing handling of ListSlices in dynamic stub
GmsCompatConfig: make sure Play Store PhenotypeFlags are overridable by Gservices flags (further deterring Play Store trying to update Play services / Play Store beyond supported versions)
Pixel 7, Pixel 7 Pro (adevtool): drop unused face unlock components since we have no plans to enable support for an insecure face unlock implementation incapable providing reasonable security due to lack of dedicated face unlock hardware (Pixel 4 and Pixel 4 XL had dual infrared cameras, IR dot projector and IR flood illuminator providing a more secure biometric unlock system than fingerprint unlock as opposed to simply using the front camera in a way that could be done on any device)
Pixel 4, Pixel 4 XL, Pixel 4a, Pixel 4a (5G), Pixel 5, Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 7, Pixel 7 Pro: include gril library to avoid qns crash on Pixel 7 and Pixel 7 Pro
Pixel 7, Pixel 7 Pro: include vendor_kernel_boot partition requirement in factory images metadata to force an error with an incompatible fastboot such as the currently buggy Arch Linux package
kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): update GKI to Linux 5.10.150
Auditor: update to version 66
Click to expand...
Click to collapse
Download in Post #2
I don't see a real value in locking the bootloader. In theory, the only thing it protects is undetectable modification being made when the device is out of your direct control. However, strong security practices require you to assume that *anything* could have been done to the device when it is outside of your direct control, so the "security" you get from the locked bootloader is artificial.
ANY time a device leaves your physical control, you have to assume it to be compromised. No exceptions.
I would also like to point out that, no offense to OP, but using a "high security" operating system that *HAS* been modified by an unknown 3rd party.... is insane. I'd recommend that anyone interested in this actually take the time to understand the process and reproduce it on their own.
96carboard said:
I don't see a real value in locking the bootloader. In theory, the only thing it protects is undetectable modification being made when the device is out of your direct control. However, strong security practices require you to assume that *anything* could have been done to the device when it is outside of your direct control, so the "security" you get from the locked bootloader is artificial.
ANY time a device leaves your physical control, you have to assume it to be compromised. No exceptions.
I would also like to point out that, no offense to OP, but using a "high security" operating system that *HAS* been modified by an unknown 3rd party.... is insane. I'd recommend that anyone interested in this actually take the time to understand the process and reproduce it on their own.
Click to expand...
Click to collapse
Sorry but I am not interested in arguing about this stuff
I didn't create this thread to argue about potential security issues or how secure phones really are
it seems you have more of an issue with the security of Android in general
I would recommend everyone who just wants to share opinions like this which are essentially unrelated to the ROM, please just don't
I am not claiming rooting your phone to be perfectly secure and I am not interested in arguing about it
Although as explained here https://forum.xda-developers.com/t/...pdated-november-9-2022.4343431/#post-85733797
there are advantages to using a locked bootloader, even with root.
optimumpro said:
The rom could be used on locked bootloader with ROOT (donate feature) with or without Gapps.
The benefits of LOCKED BOOTLOADER combined with WORKING AVB-2 protection are:
Get back your DRM L1 certificate. Most banking apps will work regardless of Magisk.
Security: Nobody and nothing can modify Kernel, Recovery and Virtual Partitions without triggering a red screen of death with the message 'your device is corrupted and cannot boot'.
At that point, the only option is to unlock bootloader. But, if a user had previously disabled OEM unlock in Developer settings, then unlocking becomes unavailable, and so does flashing via fastboot. In other words, if your phone gets into the hands of an adversary, their only option is to use MSM tool to make the phone work again, but no access to your data or any other partition.
Why prebuilt Magisk? Because you can't modify kernel or recovery on locked bootloader post installation, and that's exactly what Magisk does.
Click to expand...
Click to collapse
I am offering this as a free feature, not a donate feature and I have also created a guide so that anyone is able to build the rom and sign it using their own keys for even greater security than trusting me.
Magisk isn't just some unknown third party, Graphene, Magisk, AVBRoot, they are all open source projects
FireRattus said:
Sorry but I am not interested in arguing about this stuff
I didn't create this thread to argue about potential security issues or how secure phones really are
it seems you have more of an issue with the security of Android in general
I would recommend everyone who just wants to share opinions like this which are essentially unrelated to the ROM, please just don't
I am not claiming rooting your phone to be perfectly secure and I am not interested in arguing about it
Click to expand...
Click to collapse
I'm not talking about the utility or security of root (hint: Its perfectly safe and secure when used RESPONSIBLY). I'm talking about the value of using a security hardened OS with modifications made by someone who you don't know and can't trust. Doing so throws away ALL security because there is no way to tell what else someone has changed.
96carboard said:
I'm not talking about the utility or security of root (hint: Its perfectly safe and secure when used RESPONSIBLY). I'm talking about the value of using a security hardened OS with modifications made by someone who you don't know and can't trust. Doing so throws away ALL security because there is no way to tell what else someone has changed.
Click to expand...
Click to collapse
So just follow the guide I provided so you can build the rom yourself, you can inspect all the source code and work out exactly what it's all doing if you are so inclined
https://forum.xda-developers.com/t/...-using-rooted-grapheneos-magisk-root.4510295/
FireRattus said:
So just follow the guide I provided so you can build the rom yourself, you can inspect all the source code and work out exactly what it's all doing if you are so inclined
https://forum.xda-developers.com/t/...-using-rooted-grapheneos-magisk-root.4510295/
Click to expand...
Click to collapse
Yes exactly!
@FireRattus is there any chance we can see pre-build images for Oriole in the future? I'm having trouble building it myself.
KainoaK said:
@FireRattus is there any chance we can see pre-build images for Oriole in the future? I'm having trouble building it myself.
Click to expand...
Click to collapse
What are the troubles you are having with building it yourself? I can try my best to help
I would be able to build images for Oriole probably but I wouldn't be able to test them myself and building for more variants would take more time making updates slower so I don't want to invest in that currently.
I do think it's best to build it yourself if you are able so I am glad you have tried already
> What are the troubles you are having with building it yourself? I can try my best to help
My computer just doesn't have enough RAM + Disk space to build it, plus I seem to keep getting stuck at getting all the tools to work together
I'd be happy to donate monthly or whatnot to help keep up oriole builds though
KainoaK said:
> What are the troubles you are having with building it yourself? I can try my best to help
My computer just doesn't have enough RAM + Disk space to build it, plus I seem to keep getting stuck at getting all the tools to work together
I'd be happy to donate monthly or whatnot to help keep up oriole builds though
Click to expand...
Click to collapse
I will try to build it for you, since the pixel 6 and 6 pro share the same Build ID, I should be able to build it without needing to download everything again
New Release #2022112500
Changes since the 2022111800 release:
Sandboxed Google Play compatibility layer: fix missing handling of APEX ListSlices in dynamic stubs (improves compatibility when granting Nearby devices permission to Play services with a WearOS device connected)
Sandboxed Google Play compatibility layer: mark PackageInstallerStatusForwarder as not exported
Settings: avoid OBB toggle unnecessarily force stopping app
extend original-package renaming to static launcher shortcuts to fix Vanadium new tab shortcut for users with an install predating the package rename
Camera: update to version 57
Vanadium: update Chromium base to 107.0.5304.141
Contacts: add support for dark mode
kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro): restore fix for CVE-2022-3176 which was reverted upstream (GKI LTS branch) due to not being marked as a security fix and changing the GKI ABI
Pixel 4, Pixel 4 XL: set frozen patch level string to 2022-11-01 (has been provided since the 2022110800 release but we initially left the patch level string at the previous value)
port GrapheneOS changes to Linux 5.15 GKI LTS branch in order to prepare for 6th/7th generation Pixels potentially moving to the Linux 5.15 LTS and late 2023 devices which will be based on it
Click to expand...
Click to collapse
Download in Post #2
KainoaK said:
My computer just doesn't have enough RAM + Disk space to build it, plus I seem to keep getting stuck at getting all the tools to work together
I'd be happy to donate monthly or whatnot to help keep up oriole builds though
Click to expand...
Click to collapse
I am not able to test them myself but I have provided a patched, signed build which should work
just check post #3 for the download links, I would appreciate a donation if you feel it's worth it but no pressure
Edit: Moved it to post #2 with the other downloads
96carboard said:
I don't see a real value in locking the bootloader. In theory, the only thing it protects is undetectable modification being made when the device is out of your direct control. However, strong security practices require you to assume that *anything* could have been done to the device when it is outside of your direct control, so the "security" you get from the locked bootloader is artificial.
ANY time a device leaves your physical control, you have to assume it to be compromised. No exceptions.
I would also like to point out that, no offense to OP, but using a "high security" operating system that *HAS* been modified by an unknown 3rd party.... is insane. I'd recommend that anyone interested in this actually take the time to understand the process and reproduce it on their own.
Click to expand...
Click to collapse
To be fair you'll always be using something done by a third party, including android itself, unless it's you writing and compiling your own OS.
MidnightDevil said:
To be fair you'll always be using something done by a third party, including android itself, unless it's you writing and compiling your own OS.
Click to expand...
Click to collapse
Android is open source. Open source code is auditable. Compiled binaries are NOT.

Categories

Resources