Mod edit: This thread is a copy of a thread originally posted in the "development discussion" section. General posts should be made in this thread (and not in the original.) Only posts which follow the guidelines of the Development Discussion section should be made in the original thread (located here: http://forum.xda-developers.com/showthread.php?t=2048511)
Now find a one-click root application at http://forum.xda-developers.com/showthread.php?t=2130276. More exploits coming.
Hi,
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory ... what's wrong with Samsung ?
Its like /dev/mem but for all.
Three libraries seems to use /dev/exynos-mem:
/system/lib/hw/camera.smdk4x12.so
/system/lib/hw/gralloc.smdk4x12.so
/system/lib/libhdmi.so
Many devices are concerned :
Samsung Galaxy S2
Samsung Galxy Note 2
MEIZU MX
potentialy all devices who embed exynos processor (4210 and 4412) which use Samsung kernel sources.
The good news is we can easily obtain root on these devices and the bad is there is no control over it.
Ram dump, kernel code injection and others could be possible via app installation from Play Store. It certainly exists many ways
to do that but Samsung give an easy way to exploit. This security hole is dangerous and expose phone to malicious apps.
Exploitation with native C and JNI could be easily feasible.
Edited
Some details :
/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi.
By activating pid display in kmsg, surfaceflinger do mmap on the device (via one of the three shared libraries above ?? I have not see reference in binary to these libraires)
The operations allowed on the device are (from linux/drivers/char/mem.c) :
Code:
static const struct file_operations exynos_mem_fops = {
.open = exynos_mem_open,
.release = exynos_mem_release,
.unlocked_ioctl = exynos_mem_ioctl,
.mmap = exynos_mem_mmap,
}
and the default permissions (from linux/drivers/char/mem.c) :
Code:
#ifdef CONFIG_EXYNOS_MEM
[14] = {"exynos-mem", S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH
| S_IWOTH, &exynos_mem_fops},
#endif
ioctl request on /dev/exynos-mem permit to clean / flush L1 and L2 cache, set non cacheable page memory and set physical memory address for use with mmap.
Now the interesting part : mmap operation.
The only limit is to restrict access to lowmem (from linux/drivers/char/exynos-mem.c) :
Code:
/* TODO: currently lowmem is only avaiable */
if ((phys_to_virt(start) < (void *)PAGE_OFFSET) ||
(phys_to_virt(start) >= high_memory)) {
pr_err("[%s] invalid paddr(0x%08x)\n", __func__, start);
return -EINVAL;
}
The comment in above code could be frightening.
And an eye in Documentation/arm/memory.txt say :
Code:
Start End Use
--------------------------------------------------------------------------
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
In other words, this device only permit to own the physical memory including kernel code.
The question is why permissions are set to read/write for all in kernel AND in ueventd.smdk4x12.rc:
samsung developper in charge of this would lose his job
some samsung apps with basic rights need to access it (I doubt it)
a huge mistake
A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.
In attachment, binary and source to obtain for root shell.
Removing either read or write permissions will kill the camera. I didn't see any other deterioration in anything else.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My guess the best fix would be to limit the access to the DMA memory spaces which this thing actually needs, the definition of the different CMA areas are in /arch/arm/mach-exynos/mach-midas.c for the S3 and N2.
Front camera for example:
Code:
#ifndef CONFIG_USE_FIMC_CMA
{
.name = "fimc1",
.size = CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1 * SZ_1K,
#if defined(CONFIG_MACH_GC1)
.start = 0x5ec00000,
#else
.start = 0x65c00000,
#endif
},
#endif
Generally all memory areas allocated through s5p_cma_region_reserve in /arch/arm/plat-s5p/reserve_mem.c would be treated as exceptions and everything else needs to be blocked.
Update: Low-level kernel fix for developers posted here.
A kernel based fix as I posted above is the only method to fix the security hole while also not breaking the camera. In all other cases if you are not able or willing to flash a kernel, use Chainfire's application.
Very interesting. Thanks for bringing that up. (Have also flagged some Samsung engineers to read this)
Also, I'm building an APK for this to make it easy.
EDIT: APK posted here: http://forum.xda-developers.com/showthread.php?t=2050297, download, install, run, and your device is rooted with SuperSU.
EDIT#2: This app now also lets you disable the exploit
would this trip the flash counter? my guess says no.
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
I'm not very good with Linux, but I did
Code:
chmod 600 /dev/exynos-mem
on my GSII international with CM10 and the camera still works. Am I safe for now?
I'm guessing no, considering /dev/exynos-mem (why would they do that?) but does any similar vulnerability exist for the Qualcomm S3?
thread cleaned. "thanks", "nice", "oooh", "ahh" and remarks about code comments are off topic.
(If you want to discuss what is/isn't of topic, please reply go here: http://forum.xda-developers.com/showthread.php?t=2017367)
supercurio said:
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
Click to expand...
Click to collapse
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
[Edit: to OP, NICE FIND!]
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
Please explain how this is a remote exploit? This looks entirely local to me. Vulns happen, every vendor gets hit with them. Google does, Apple does Motorola does, HTC does, LG does, Samsung does, ASUS does, Nvidia, Qualcomm etc etc, it is all part of the game. Hell go look at the recent qualcomm disclosures, almost every qualcomm since 2009, wide open! Sh*t happens. Any device with root on it, be it exploit or whatever is open to permanent damage from malicious, want to nuke an htc with root? dd if=/dev/zero of=/dev/block/mmcblk0p4. Pantech/LG/Mostqualcoms hit all the bootloaders. Hell system user is enough on LG phones, and most other brands to brick them.
I'm not sure about rewards, but I have reported vulns and bugs to every major vendor, and the only three who ever respond to me are Google, Samsung and Motorola. All three respond promptly and polite, and occasionally follow up if requested. Vendor not getting back to you? [email protected] is quite good at getting them to respond, just tell them the vendor is not responding. More than once they have gotten a dialog with a vendor opened with me.
Understanding update timelines is another issue, vendor updates generally have to go through development, QA at the vendor (sent back if major issues found), then in the case of Sprint and other carriers, sent to carrier QA (returned to OEM if major issues found) . Major changes to the radio? Yep off to the FCC as well! Updates can take considerable time. Not excusing the "superbrick" bug, just pointing out a few weeks (or in the case of sprint or Vernon a few months) can be expected. Want faster updates? Buy an international device, and get a GSM carrier.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" (Samsung's attitude regarding it) - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
I think we all got the point you're not happy with Samsung.
The issue discussed here is off topic.
Also I'm sorry to observe that your "It'll never happen" on security sounds more like bad-mouthing than an informed comment.
On a more technical aspect, as soon as you have root permissions there's a large choice of method allowing to hard-brick or damage hardware without relying on a bug present in some eMMC controllers that I won't of course describe here.
supercurio said:
Okay thanks, I confirm that people at Samsung have just made aware of it.
I also suggested to open an easy way to contact their security team, possibly with reward so such vulnerability (as cool as dangerous) would be reported to them instead of published on XDA as-is next time.
@alephzain, did you tried to report it to people able to fix this serious security issue before publishing it here?
Click to expand...
Click to collapse
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .
I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.
Entropy512 said:
That was suggested to them months ago in the aftermath of the Superbrick disaster. It was completely rejected within days.
It'll never happen.
Looks like Superbrick is no longer just "an open source problem" - Samsung devices vulnerable to Superbrick have been one non-local (as in does not require USB) root exploit away from market apps being able to do permanent unrecoverable damage to devices. Samsung has not cared about that fact and allowed Superbrick to remain unfixed for months, even though they've had the patch since before early September and device updates have gone out since then (Sprint FI27 was built on September 27, 3 weeks after the patch had even been merged to mainline Linux, and 4-5 weeks since they first authored it.)
Now there's a remote exploit and there is zero protection against malware causing permanent damage to a device.
Click to expand...
Click to collapse
Well pointed, for a discover like this they should pay a fortune to alephzain, and other devs that help fixing this security problems, but they just don't care. .
I'm sure they will fix it eventually in the next updates but they will encover it of course and will leave millions of users at risk until that. .they don't want this kind of publicity.
I hope that they give a good reward to our devs that everyday work to improve our devices. .but I know they will not do it. . But that's the fun of it isn't it?
Sent from my GT-I9300 using xda premium
@alephzain thanks for sharing the source code of the exploit: short, elegant, efficient, to me that's art
Your short documentation and clean writing style even made easier to learn from it.
Please keep this on topic: /dev/exynos-mem.
Sent from my SAMSUNG-SGH-I317 using Tapatalk 2
yugoport said:
In my point of view, we are a community of developers, not a bunch of people trying to help Sammy to solve the problems that their extremely well paid engineers can't see. .
I truly respect your point of view, and cheers to your sense of civism to try to protect the people that are using this phones and don't have ability and knowledge to protect themselves against a so severe lack of security, but seriously Sammy doesn't care about users or developers, they care about money. .So first I think he did well to post here and then inform Samsung.
Click to expand...
Click to collapse
This is not Samsung-specific in any way.
Fortunately most people discovering security flaws inform original authors so they can fix the issue and release updates before the exploit is publicly released.
I'm not judging alephzain here, because its possible he tried to report the issue but found no-one listening, taking him seriously, or simply couldn’t find who to contact, hence my question to him to know if he tried or just didn't care, also because I'm a fan of the technical exploit and use similar method in my apps as apps to do things not supposed to be done.
Millions of vulnerable devices are out there now. This exploit which is very well designed and I believe very hard to detect if carefully hidden inside an Android app.
It means privacy, security of a large amount of people and corporation is at a larger risk right now as the manufacturer didn't had the chance to provide a security fix to its users, because of not being aware of the issue.
What a nuisance!
The most important question is - how to quickly patch this?
A simple chmod 0600 /dev/exynos-mem does not survive reboot.
Any ideas that does not envolve unpack/pack update images?
julandroid said:
What a nuisance!
The most important question is - how to quickly patch this?
A simple chmod 0600 /dev/exynos-mem does not survive reboot.
Any ideas that does not envolve unpack/pack update images?
Click to expand...
Click to collapse
Nobody wrote yet an app that fixes the issue?
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.
For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
julandroid said:
I don't care about the app right now. That's why those reports *should* go directly to the root of the problem - Samsung. Because once they go to the surface everyone can exploit the device. Eventually, if someone decide to post the exploit first - then it should be prepared with the solution.
For know it will be a good idea, anyone with knowledge just to give idea what to do (manually). For example I don't have any ueventd.smdk4x12.rc (Galaxy S2, CM10). I guess I need to unpack boot.img, to find where permissions are set for /dev/exynos-mem, then to repack boot.img and flash it.
Click to expand...
Click to collapse
As far as I'm concerned I already implemented a fix into the kernel to just whitelist the FIMC0 memory space for the mmap function and to refuse access to the rest of lowmem. I'll post it later when I sorted some things with the other DMA spaces.
Okay I feel lazy this Sunday night but will still quickly write an app that fixes the vulnerability (simple chmod 660) at boot.
Just for the sake of it.
(Breaks camera on S III, not on Note II)
Related
Edit:
Check to see if your Tab 7.7 contains the brick bug using Chainfire's new "Got Brickbug?" app. URL below.
http://db.tt/ee0RCtoK
Here's my results:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Edit:
CONFIRMED. TAB 7.7 CONTAINS SUPERBRICK BUG. READ BELOW.
Entropy512 said:
MAG4FA fwrev 0x19 is the same chip the E4GT uses - it's affected.
So it's really a question of whether Samsung disables MMC_CAP_ERASE in the kernels or not. I personally wouldn't touch your ICS releases until source code is reviewed or Samsung acknowledges the issue and states that they have fixed it in P68x0 releases
Click to expand...
Click to collapse
Edit:
Yah. I flubbed a few things in my explanation. I'm not an expert. But I am thorough. And as I said in this post before editing, my Tab 7.7 has the same chip and firmware. I only listed the firmware version though, here's both now below. Please just take a look at it and tell me if I was right. (By the way, I'd really much prefer it if you told me I was wrong.)
Less summary. More facts.
GT-P6810 - MAG4FA
/sys/block/mmcblk0/device/cid
1501004d414734464119d71350251f49
GT-N7000 - VYL00M:
/sys/block/mmcblk0/device/cid
15010056594c30304d191e8647cbae3b
Entropy512 said:
You summarized a lot of things incorrectly.
MMC_CAP_ERASE is not a command, it's a flag in the driver that allows ERASE commands to be sent to the MMC chip.
Gingerbread kernels DID have this flag enabled - but they didn't cause damage because Gingerbread recovery does not attempt to erase a partition when wiping it, it just does a format (without a low-level ERASE).
Honeycomb recoveries/kernels are unknown.
Also, the fwrev is not the only important item - the flash chip name (/sys/block/mmcblk0/device/name) is also important.
To be in danger, you need:
MAG4FA, VYL00M, or KYL00M fwrev 0x19 - M8G2FA fwrev 0x11 (some Kindle Fires - assuming that the fwrev field is even at offsets 19,20 in the cid for that chip) may also be affected (There may be other Samsung eMMC chips/fwrevs affected, but these are the confirmed ones.)
A kernel with MMC_CAP_ERASE enabled in drivers/mmc/host/mshci.c
A recovery that performs erase operations when formatting a partition
Edit: It was recently confirmed that in nearly all configurations, large file deletion is safe. It's only dangerous if one of the partitions in use is mounted with the "discard" option - which isn't the case for any device I've seen yet.
Click to expand...
Click to collapse
Sent from my GT-N7000 using XDA Premium HD app
Sent from my GT-P6810 using XDA Premium HD app
Speaking generally (i.e. for all droids) under what circumstances is that command invoked, and does it need root permissions?
i.e. what normal app / or system function would call that command in normal operation?
wintermute000 said:
Speaking generally (i.e. for all droids) under what circumstances is that command invoked, and does it need root permissions?
i.e. what normal app / or system function would call that command in normal operation?
Click to expand...
Click to collapse
No. It is not dependant on root privileges. The bug is triggered by large erase operations such as large file deletion, "wipe data/factory reset" in ClockworkMod or stock recovery, or a simple factory reset from within the OS via the "Settings" menu. However, if the current Honeycomb builds for the Tab 7.7 made use of MMC_CAP_ERASE, I suspect we would know about it already. I'm fairly confident that we don't have anything to worry about for the time being. However, once ICS is released, things may change drastically. I'm hoping this thread gives devs and users enough to prepare themselves for the possibility of MMC storage problems in the future. With any luck, we'll be able to avoid the problems that so many Note owners experienced.
Sent from my GT-P6810 using XDA Premium HD app
Mister_Mxyzptlk said:
I'm not sure how many of you have been following the ongoing drama in the International Galaxy Note forum, but essentially, it was discovered that the MMC storage in the Galaxy Note contains a fatal glitch which under certain circumstances can cause the MMC storage to become permanently corrupted. Devices damaged by this bug cannot be restored via ODIN or even via JTAG repair. The specific error has to do with the MMC_CAP_ERASE command. Because this command was not implemented in any of the Note's Gingerbread kernels, devices remained unharmed. However, with the official release of ICS for the Note, Samsung implemented MMC_CAP_ERASE. Because of this, users who had upgraded to the new ICS release were at risk of permanently bricking their devices with no warning. Since this issue has come to light, several developers have begun looking into the issue and now with the ICS source for the Note released by Samsung, there are some built-from-source kernels that have had MMC_CAP_ERASE removed. These kernels are supposedly safe, and no verifiable bricks have been reported with them. For the time being, it seems as though the Note's issues have been reigned in.
However, given the not so insignificant similarities between the Note and the Tab 7.7, I decided to look into my GT-P6810 and see if my Tab 7.7 had the same MMC and MMC firmware as the Note. As it turns out, mine does. Below you will find a string from inside the file: "/sys/block/mmcblk0/device/cid". If you'll look at the nineteenth and twentieth characters, you'll see that they are "19". This is the MMC's firmware version, which is the same firmware version responsible for all the Note bricks. Now, before everyone gets into a panic, this does not mean that the Tab 7.7 is susceptible to random bricks. What I would like to do is start a coordinated investigation into this matter so that when ICS is released for our device, if it has MMC_CAP_ERASE enabled, we will be prepared. Besides, I could be completely wrong about this. What I would like is for a developer to look into it and see if I've missed, overlooked, or misinterpreted anything. For the time being, everyone should proceed as normal. There is no reason to panic. I simply wish to investigate this matter. If it is determined that the Tab 7.7 does indeed have this bug, we will be prepared to take the steps necessary to mitigate it. Thank you for your time.
GT-P6810:
/sys/block/mmcblk0/device/cid
1501004d414734464119d71350251f49
GT-N7000:
/sys/block/mmcblk0/device/cid
15010056594c30304d191e8647cbae3b
Sent from my GT-P6810 using XDA Premium HD app
Click to expand...
Click to collapse
You summarized a lot of things incorrectly.
MMC_CAP_ERASE is not a command, it's a flag in the driver that allows ERASE commands to be sent to the MMC chip.
Gingerbread kernels DID have this flag enabled - but they didn't cause damage because Gingerbread recovery does not attempt to erase a partition when wiping it, it just does a format (without a low-level ERASE).
Honeycomb recoveries/kernels are unknown.
Also, the fwrev is not the only important item - the flash chip name (/sys/block/mmcblk0/device/name) is also important.
To be in danger, you need:
MAG4FA, VYL00M, or KYL00M fwrev 0x19 - M8G2FA fwrev 0x11 (some Kindle Fires - assuming that the fwrev field is even at offsets 19,20 in the cid for that chip) may also be affected (There may be other Samsung eMMC chips/fwrevs affected, but these are the confirmed ones.)
A kernel with MMC_CAP_ERASE enabled in drivers/mmc/host/mshci.c
A recovery that performs erase operations when formatting a partition
Edit: It was recently confirmed that in nearly all configurations, large file deletion is safe. It's only dangerous if one of the partitions in use is mounted with the "discard" option - which isn't the case for any device I've seen yet.
Entropy512 said:
You summarized a lot of things incorrectly.
MMC_CAP_ERASE is not a command, it's a flag in the driver that allows ERASE commands to be sent to the MMC chip.
Gingerbread kernels DID have this flag enabled - but they didn't cause damage because Gingerbread recovery does not attempt to erase a partition when wiping it, it just does a format (without a low-level ERASE).
Honeycomb recoveries/kernels are unknown.
Also, the fwrev is not the only important item - the flash chip name (/sys/block/mmcblk0/device/name) is also important.
To be in danger, you need:
MAG4FA, VYL00M, or KYL00M fwrev 0x19 - M8G2FA fwrev 0x11 (some Kindle Fires - assuming that the fwrev field is even at offsets 19,20 in the cid for that chip) may also be affected (There may be other Samsung eMMC chips/fwrevs affected, but these are the confirmed ones.)
A kernel with MMC_CAP_ERASE enabled in drivers/mmc/host/mshci.c
A recovery that performs erase operations when formatting a partition
Edit: It was recently confirmed that in nearly all configurations, large file deletion is safe. It's only dangerous if one of the partitions in use is mounted with the "discard" option - which isn't the case for any device I've seen yet.
Click to expand...
Click to collapse
Okay. Let's go ahead and address the reason why I PM'ed you and asked you to look at this in the first place. I AM NOT AN EXPERT. I was asking for your help. I simply noticed that everything that made my Note susceptible to bricking was also found in the Tab 7.7. Now, if I understand you correctly, my Tab 7.7 has all the bad juju and the wrong kind of wipe/format could really ruin my day. Am I missing something?
Sent from my GT-N7000 using XDA Premium HD app
No - you still haven't posted the name of the flash chip, just the cid - we need the name too.
Entropy512 said:
No - you still haven't posted the name of the flash chip, just the cid - we need the name too.
Click to expand...
Click to collapse
Yes I did post the name. It's in the first post edit.
Sent from my GT-N7000 using XDA Premium HD app
MAG4FA fwrev 0x19 is the same chip the E4GT uses - it's affected.
So it's really a question of whether Samsung disables MMC_CAP_ERASE in the kernels or not. I personally wouldn't touch your ICS releases until source code is reviewed or Samsung acknowledges the issue and states that they have fixed it in P68x0 releases
Entropy512 said:
MAG4FA fwrev 0x19 is the same chip the E4GT uses - it's affected.
So it's really a question of whether Samsung disables MMC_CAP_ERASE in the kernels or not. I personally wouldn't touch your ICS releases until source code is reviewed or Samsung acknowledges the issue and states that they have fixed it in P68x0 releases
Click to expand...
Click to collapse
Thank you. I appreciate you hopping on the Tab 7.7 forum and looking at this. Any mods out there feel like posting a sticky about this? Or, Entropy, would you like to throw together a warning post about this? As eager as I am to get off of Honeycomb, I would rather avoid the palpitations that accompanied my GT-N7000 upgrade.
Sent from my GT-N7000 using XDA Premium HD app
Bump. Added download link for Chainfire's new Brick Bug app. See first post.
Sent from my GT-P6810 using Tapatalk
I got the same output..
How can we fix this?
Sent from my GT-P6800 using XDA
wathefak said:
I got the same output..
How can we fix this?
Sent from my GT-P6800 using XDA
Click to expand...
Click to collapse
There's nothing we can do to fix it. Either Samsung needs to find a way to update the eMMC firmware, or remove MMC_CAP_ERASE from the kernel (as far as I know). Unfortunately though, Samsung has yet to even acknowledge the existence of the bug.
Sent from my GT-N7000 using XDA Premium HD app
It's an understatement to say this is rather disquieting! If indeed as smarter people that I have said this "bug" exists on ALL 7.7's and Samsung has been less than forthcoming about it, would reaching out to the appropriate trades be a wise move? Perhaps they (with a "bigger and louder voice") motivate Samsung to effect a fix or at least plans to issue one?
I do so enjoy this tab and am concerned a "time bomb" lays in wait to bite me....
skeeterpro said:
It's an understatement to say this is rather disquieting! If indeed as smarter people that I have said this "bug" exists on ALL 7.7's and Samsung has been less than forthcoming about it, would reaching out to the appropriate trades be a wise move? Perhaps they (with a "bigger and louder voice") motivate Samsung to effect a fix or at least plans to issue one?
I do so enjoy this tab and am concerned a "time bomb" lays in wait to bite me....
Click to expand...
Click to collapse
Thursday, June 7, 2012
SkeeterPro & XDA Members:
Well, I understand your fear. I am an amateur when it comes to Android and mobile hardware. My forte has historically been networking. Just see Entropy's reply to my original post for an example of my ignorance. However, mobile or not, all computers contain the same basic components. Considering how integrated mobile devices are, this bug SHOULD scare the crap out of anyone with an affected device.
However, that being said, Tab 7.7 owners shouldn't have anything to worry about at present. It seems that Honeycomb on the Tab 7.7 is configured the same as Gingerbread on other affected devices. This means that while the bug is present, the OS will not trigger it. The problem with the other devices, like the International Note (Which I own), is that the new ICS updates for these devices were configured so that they COULD trigger the bug (Unlike Gingerbread). So until Samsung releases ICS for our beloved, unique, spectacular, awe-inspiring tablet, we should be in the clear. Of course, take all of this with a grain of salt; but if Honeycomb were capable of triggering the bug, I think we would have noticed by now.
Now, on another note, I think this thread should be stickied. Maybe it's just me, but I'd rather avoid the fiasco that the GT-N7000 endured. As an International Note owner, I would have much rather known about this bug BEFORE I updated to ICS. I was one of the first to update, so I didn't hear about the bug until the day after I updated. Lots of good people completely lost their devices to this bug! Now, if we're in any position to avoid this calamity, shouldn't we take advantage of it? Again, this is just my opinion. However, if you don't believe me about how awful this whole thing was/is, hop on over to the GT-N7000 forum and see for yourself. Samsung still hasn't issued a fix. It is a very terrible and very real problem. Hopefully, Samsung will forego enabling MMC_CAP_ERASE in our ICS build when it comes. But just in case it doesn't, I think we would all be better off if we understood what this bug is and what this bug isn't.
Anyway, I've rambled enough. If anyone with the power to do so would consider it, please sticky this. I would really appreciate it, and ALL of the Tab 7.7 owners would have the opportunity to benefit from it. Thank you.
Thank you,
Ed (Mister_Mxyzptlk)
Sent from my GT-N7000 using XDA Premium HD app
Well, I think stickying the thread would unnecessarily scare people. Remember, to be in danger requires ALL THREE of the conditions below - fail any of the conditions listed and you're safe.:
1) Defective flash chip
2) A kernel that allows ERASE commands to hit the chip
3) A recovery that attempts to do a low-level erase when wiping.
Currently, as far as I can tell:
1) All of your current stock kernels fail condition 3 for danger at a minimum
2) The CM9 release fails condition 2 for danger due to being based off of the I9100 Update4 source code.
In short - currently there is no known dangerous configuration for this device, despite the defective flash chip. When you receive ICS leaks that may change - but it is unknown.
Stickying this would create unnecessary panic - look at all of the I9100 users that got scared when Got Brickbug? made the portal, even though with one exception (a kernel which was quickly pulled), they have always been safe as all of their kernels/recoveries have always failed either condition 2 or 3 above or both.
Entropy512 said:
Well, I think stickying the thread would unnecessarily scare people. Remember, to be in danger requires ALL THREE of the conditions below - fail any of the conditions listed and you're safe.:
1) Defective flash chip
2) A kernel that allows ERASE commands to hit the chip
3) A recovery that attempts to do a low-level erase when wiping.
Currently, as far as I can tell:
1) All of your current stock kernels fail condition 3 for danger at a minimum
2) The CM9 release fails condition 2 for danger due to being based off of the I9100 Update4 source code.
In short - currently there is no known dangerous configuration for this device, despite the defective flash chip. When you receive ICS leaks that may change - but it is unknown.
Stickying this would create unnecessary panic - look at all of the I9100 users that got scared when Got Brickbug? made the portal, even though with one exception (a kernel which was quickly pulled), they have always been safe as all of their kernels/recoveries have always failed either condition 2 or 3 above or both.
Click to expand...
Click to collapse
Yeah. Maybe you're right. But I still think something should be done to caution users about updating to ICS when it comes out. Maybe an announcement instead of stickying this. As a Note owner, I'm already well aware of the danger, and I'm totally comfortable using my Tab 7.7 right now; and others should be too. However, there has to be a way to caution people without generating a panic. After all, nothing can compare to the panic that comes AFTER devices have started bricking. The N7000 forum still gets daily brick posts, and warnings have been posted all over the place. I would just like to see if we can make sure there isn't a single bricked Tab 7.7. That would be nice. Avoiding the problem would be a lot better than trying to clean it up. Would you feel like writing a casual, non-alarming word of caution on the matter?
Sent from my GT-N7000 using XDA Premium HD app
Hey, so what do we do if we have this bug? Not upgrade to ics when/if its released?
Sent from my GT-P6800 using XDA Premium HD app
aletheus said:
Hey, so what do we do if we have this bug? Not upgrade to ics when/if its released?
Sent from my GT-P6800 using XDA Premium HD app
Click to expand...
Click to collapse
I wouldn't upgrade until after the source is released to see if it's safe.
Sent from my GT-N7000 using XDA Premium HD app
Good advice. While it's most often best to be forewarned....no reason to morph into "Chicken Little"! Let's leave that to the Tea Party.
But seriously, thanks Ed and Entropy, for the information. I shall await ICS until source is deemed appropriately safe.
(Mr. Mxyzptlk..."Ed" would be simpler to say backwards. lol)
skeeterpro said:
Good advice. While it's most often best to be forewarned....no reason to morph into "Chicken Little"! Let's leave that to the Tea Party.
But seriously, thanks Ed and Entropy, for the information. I shall await ICS until source is deemed appropriately safe.
(Mr. Mxyzptlk..."Ed" would be simpler to say backwards. lol)
Click to expand...
Click to collapse
I agree forewarned is forearmed. I bought the 7.7 after bricking my note. Still waiting for it to be returned from Samsung who are charging an absolute fortune to repair what is essentially a manufacturing defect.
Sent from my GT-P6800 using xda premium
According to the BBC, "Serious security flaws that could give attackers complete access to a phone's data have been found in software used on tens of millions of Android devices." This includes the Nexus 6.
Full story here: http://www.bbc.co.uk/news/technology-37005226
App from Check Point for testing whether your device is susceptible: https://play.google.com/store/apps/details?id=com.checkpoint.quadrooter
I never worry for two reasons,
1) I watch what I download and install, trusted vendors and sources only
2) It is a Nexus device it will be patched
Don't worry, yesterday it was stagefright, now it's something else.
With Nexus we will be close to a patch
http://thetechportal.com/2016/08/08/new-android-vulnerability-quadrooter/
This one took six months of reverse engineering qual comm code to find. And that is only to outline theoretical avenue for attack...real exploit can be more challenging.
It is ranked as "high risk"...Not even the highest category (critical is highest). There are many high and critical vulnerabilities patched every month. I think the only thing unique about this one is press coverage drummed up by checkpoint to celebrate their finding and make themselves look more notable
http://www.recode.net/2016/8/8/12403088/android-security-mess-quadrooter
http://www.recode.net/2016/8/8/12403088/android-security-mess-quadrooter
"Google, meanwhile, says three of the four flaws tied to Quadrooter were patched in an August security update while the fourth is set to be fixed soon. "
electricpete1 said:
"Google, meanwhile, says three of the four flaws tied to Quadrooter were patched in an August security update while the fourth is set to be fixed soon. "
Click to expand...
Click to collapse
Hmmmm. I'm running MOB30W (dated 5th August), and the Checkpoint app claims that I'm vulnerable to 3 of the vulnerabilities, so either Google or Checkpoint have got something wrong...
Philip said:
Hmmmm. I'm running MOB30W (dated 5th August), and the Checkpoint app claims that I'm vulnerable to 3 of the vulnerabilities, so either Google or Checkpoint have got something wrong...
Click to expand...
Click to collapse
It needs stock kernel, because it's a kernel driver bug. I'm using my own build but with the stock kernel, and it says only one vulnerability left.
btw.. 3 of the 4 are already patched.
If you are on the August update only one of the four is still an issue. And Franco just rolled the commit in for the fourth one in his update today if yoy are using his kernel.
But as mentioned, just be careful what tou install and it is a non issue. And remember its a report of a flaw, not a report of it being used in the wild. Big difference.
The Checkpoint app is questionable I think. Lots of false positives being reported on the web.
Really guys this is nothing more then more fear mongering. As long as android offered open source code you will always find holes like this. Most are nothing to even worry about. Just like the stagefright issue. Dont sweat it.
Note that THREE of the FOUR bugs are within the closed source GPU (Adreno) drivers.
So this is a very strong argument in favor of getting this crap swapped out in favor of freedreno.
And I've applied the CAF patch to the kernel. Great, but the app still lists it as a vulnerability. So since the fix looks valid, then the app must give a false positive.
zelendel said:
Really guys this is nothing more then more fear mongering. As long as android offered open source code you will always find holes like this. Most are nothing to even worry about. Just like the stagefright issue. Dont sweat it.
Click to expand...
Click to collapse
finally a voice of reason!
thanks man, couldn't agree more. Unfortunately 95% of the people that come here don't get it..
zelendel said:
Really guys this is nothing more then more fear mongering. As long as android offered open source code you will always find holes like this. Most are nothing to even worry about. Just like the stagefright issue. Dont sweat it.
Click to expand...
Click to collapse
100% agree. Exploits usually need to be customized for different makes, models, and Android operating system versions in order for compromise to occur, really, really difficult to own an entire ecosystem.
Every year it's something new, first stagefright, now Qualcomm bug, nothing comes of it and it's packed withing a month or two, it makes you wonder why they even bother reporting on it.
did the scan and my nexus 6 is ok running the dev 5 android 7 rom
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
What's the vulnerability?
Plain and simple the software needs removed.. doesn't that apply to the devs policy's which they agreed to here on xda not to publish anything which may be a threat to someone... So you know what should of happened is the devs should of removed the software right away. That never happened so I've lost all faith in theses devs and publishers of official software threads...
I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened
sliding_billy said:
I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened
Click to expand...
Click to collapse
I ignore all posts that don't make sense like the OP's and this thread.
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
First, there are no Oreo roms. Secondly, the devs who support our phones for free owe you nothing. Lastly, you need more than 12 posts to be taken seriously about anything around here. And, you can never post enough to attain the right to throw around accusations about the devs who, again, support our phone for free.
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
Tell us how you really feel!
Windows people ?
Sent from my Pixel using XDA-Developers Legacy app
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
If this is the case all root and bootloader exploits need removing also.
Any bootloader exploits or method of rooting without and unlocked bootloader is a SIGNIFICANTLY large security risk.
Sent from my Pixel using Tapatalk
Are we going to remove ALL the old ROMs from XDA? SHEESH.
In before the lock.
One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.
Pixelxluser said:
One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.
Click to expand...
Click to collapse
Nobody hacks individual phones. They hack companies and clouds.
****! Hey, can y'all hold it for just a moment? Need to run to the store real quick. I'm out of popcorn.
Seriously, though, just simply rooting your phone is a security risk. Also, from what i've seen, the majority of ROM users are smart about what they download. It's the general public that downloads mischevious apps that spread viruses. And as someone else mentioned, the malware and viruses don't target one person's phone. They are free floating and latch onto whatever moron downloads it. Your phone is not exactly the best place to download all your porn
But seriously, there are exploits with every security patch...it's the reason we get them every month, lol. Android is great and I love it but the OS itself is full of holes that malware developers consistently take advantage of.
Couldnt say this better myself..
Security is engineered into everything we do
Our goal is to make Android the safest computing platform in the world. That's why we invest in technologies and services that strengthen the security of devices, applications, and the global ecosystem.
It's also one reason Android is open source. Being open allows us to tap into a global network of security talent full of innovative ideas that help make Android safer every day. Security experts around the world can review our code, develop and deploy new security technology, and contribute to Android’s protections.
As the Android ecosystem evolves, we continue to invest in leading-edge security ideas. And we want to share our knowledge openly with you. Explore below to learn about the latest technologies and information that help secure Android.
Adrian Ludwig
Director of Android Security
Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
With some custom ROMs whether or not the have the Sept security patch is probably the least of your problems, if security is a concern of yours... you should be more concerned with things like;
- what keys are they using to sign their ROM (Apks included). Did they generate their own private signing keys and platform keys, or did they just use a devkeys or keys provided in the SDK?
- what changes have they made to aosp sources or not integrate (or revert) that could reduce security?
- have they messed with android's security or permissions model?
- have they included legacy code (like forward porting), that may have been dropped in the first place do to being insecure (legacy mediaserver without seccomp integration).
- have they modified selinux policies in ways that potentially could open up attack vectors.
- does the ROM have odexing enabled? The fact is, odexing while useful for booting/loading programs faster, also has the side benefit of making an apk harder to tamper with...
- have any changes that have been made been audited, or verified for correctness?
...and the list goes on. You are worried about a monthly security patch, with a handful or two of fixes for CVEs, yet make no mention of far bigger concerns that may be present in XYZ custom ROM.
Just saying.
contribute to Android’s protections. Is one thing which is lacking from what I see... I hope you understand that there are underaged people who don't know any better about what's best for them and come running off to try to be the cool kids by rooting or adding unsecured software on their phones.. rooting is so crazy to do now a days you're all really going to the extremes by bypassing security features just so you can have root... That's not the message the younger generation should be taught... They should be taught the importance of how security works not 50 ways to bypass it... There's not a feature out there which Google wouldn't consider adding officially but also Google doesn't go off and use unofficial code to pull features from it would look bad for their business..
And as long as there's a community of underaged people who do go off and root and install unsecured software you might wanna lead by example and provide them with the best security you can... A child with unsecured software is scary that someone would open up security holes for them to be a possible victim and the best you're actually willing to do is try to remove yourself from the responsibility of being responsible for it by saying if you install our software you are responsible for any damages. You can't just publish something then go out and say you take no responsibility when by law you're still responsible for any damages cause you never legally got you're software that way...
Since you're the ones distributing the software you're liable for damages if there was a defect in you're product which was distributed.. security flaws and security bypasses count as defects in a product..
Distributorship and Liability
Even though the distributor is not responsible for manufacturing a product, it can be held liable in the event of defects. Under strict product liability laws, the seller, distributor, and manufacturer of a defective product can be held liable if a person is injured due to the defect. Though manufacturers are typically most responsible since they created the product, the liability can also fall to those that distribute or sell the defective items.
This liability law prevents the plaintiff from the need to prove the chain of supply. In order for any entity in the line of distribution to prove it has no fault, it would need to show which entity is actually responsible for the defect
I suggest you stick with Windows dude
The only thing your posts are good for is making people spit their coffee with humour, and embarrassing yourself.
Sent from my Pixel using XDA-Developers Legacy app
I posted this on a thread and then realised it probably belongs here instead, didnt realise there was a whole board for lineage.....
Hi all. I am just learning about LineageOS. I mainly want it for my kids, as I want NO google spyware/behaviour tracking in their life, no Youtube etc either. A friend advised me to try LineageOS, calling it a 'privacy based OS'. I then bought a used MotoG with LIneage on, a Google Asus tablet with Lineage on, and finally a Google Nexus again with LineageOS on. I was over the moon, picking up all three from a car boot sale dirt cheap, in mint condition too! BUT.... Another friend of mine, a software engineer and privacy 'expert' as far as I am concerned anyway - he said that LineageOS is not safe to use as rooting is dangerous and exposes the devices to a plethora of attacks and vulnerabilities. I just wondered what the opinions on here were about that?
I discussed it and said 'I just want privacy thats all', and he basically said "You cant have privacy without FIRST having security". Agree/Disagree? I am all ears! (this is all new to me, never flashed anything but my back side!)
Anyone?
dannythechamp said:
Anyone?
Click to expand...
Click to collapse
I guess all your questions are answered all over in XDA. Such as knowledge about root, privacy etc.
If you don't understand what rooting your device means or does, stay away from it.
If you do understand after digging into it, you will have almost endless tools to run your phone like it should run, and not like the pre-installed ROM you get it from the manufactory...
Thats a curious response. My question is about whether people agree or disagree with this point. The lack of responses (and yours) suggest people just dont want to discuss it. Thats curious in itself and now makes me think the point is valid.
I understand a bit about rooting, I Just have not done it with my own hands. The main point I understand about it is the fact that it gives the user of the phone (or anyone emulating that via attack/theft) superuser/admin level access. Great, for removing built in spyware from Google (which is my main motivation here), but as was suggested to me, not so great if it makes the device inherently insecure. I was hoping for some discussion on this topic, clearly nobody wants to discuss it. Maybe that's an answer in itself.
complex jobs
ha, I refer to my last!
Danny, pre installed Android is more secure, if you don't know exactly what you are doing with your os. Lineage os, or simply a rooted phone, puts you in control of everything, included your privacy, but you have to know what you are doing. I agree with your friend.
Inviato dal mio SM-A405FN utilizzando Tapatalk
Thanks for chipping in Alessia. Yes, I certainly don't enough to claim "i know what I am doing"! My friend does though, and even he says with all the expertise in the world, you can't close the loophole that is "Rooting". Yes he could certainly mitigate much of the risks, but not all, and he still believes with all the mitigation in the world, a rooted phone (especially one running Lineage) is still less secure than a stock android with secure hardware such as (ironically) Google's Pixel. That's what he says anyway. I am not tech enough to believe him out of knowledge, but I certainly do trust him to tell me the truth, which these days certainly counts for something!
He summed up his advice with something like this.....
'If you can afford a Pixel running Graphene (IF the OS keeps being worked on, which is in doubt at the mo), then that's the most secure AND privacy-respecting option. If you can't, next stop stock iOS, next stock Android, Lineage way down the list, Lineage on an old MotoG or any old (cheap ) unsupported device which gets no hardware/firmware updates/patches, that's just security and privacy suicide!'
That's about the best round up I can give for his comments. So it's stock iOS or Android for me. Now to decide which! I already have an iPhone. Was looking forward to dumping it, and I certainly do prefer Android, but he says stock iOS is slightly more secure than stock Android.
The biggest pain in the ar5e for me is the fact that, in order to avoid security risks, you have to give yourself to Apple and/or Google. That's a depressing state of affairs indeed. I will just have to do everything I can to prevent as much spying as possible, turn off siri type stuff, location services, etc etc
dannythechamp said:
Thanks for chipping in Alessia. Yes, I certainly don't enough to claim "i know what I am doing"! My friend does though, and even he says with all the expertise in the world, you can't close the loophole that is "Rooting". Yes he could certainly mitigate much of the risks, but not all, and he still believes with all the mitigation in the world, a rooted phone (especially one running Lineage) is still less secure than a stock android with secure hardware such as (ironically) Google's Pixel. That's what he says anyway. I am not tech enough to believe him out of knowledge, but I certainly do trust him to tell me the truth, which these days certainly counts for something!
He summed up his advice with something like this.....
'If you can afford a Pixel running Graphene (IF the OS keeps being worked on, which is in doubt at the mo), then that's the most secure AND privacy-respecting option. If you can't, next stop stock iOS, next stock Android, Lineage way down the list, Lineage on an old MotoG or any old (cheap ) unsupported device which gets no hardware/firmware updates/patches, that's just security and privacy suicide!'
That's about the best round up I can give for his comments. So it's stock iOS or Android for me. Now to decide which! I already have an iPhone. Was looking forward to dumping it, and I certainly do prefer Android, but he says stock iOS is slightly more secure than stock Android.
The biggest pain in the ar5e for me is the fact that, in order to avoid security risks, you have to give yourself to Apple and/or Google. That's a depressing state of affairs indeed. I will just have to do everything I can to prevent as much spying as possible, turn off siri type stuff, location services, etc etc
Click to expand...
Click to collapse
Let's start by asking the question, are stock cell phones secure? The answer is very simple, NO! The list of entities watching you is nearly endless, starting with your provider, then the manufacturer ... None of them have your interests at heart. For most the objective is to separate you from your money. For others the objective is to collect information that can be used to manipulate you socially or politically.
So is third party software safer. Depending if it is open source or not. Closed source, probably not.Open source software is generally considered safer, for the simple reason that it is more difficult include malware in it. There is a caveat, the size of the development/user community matters - in general the larger the better - the more eyeballs on the developers the better.
Is "rooting" a good idea, for most users the answer is NO. It increases the security exposure which is not a good idea.
Dear Danny, if you want to avoid security risks, just do it. You are not compelled to do or buy anything.
Use your brain, your knowledge, root your phone and take full control on your device. That's enough.
But, if you want Google or Apple to avoid security risks for you, the price is your privacy (and a new phone every 2 years, to receive security patches).
For me, it is a simple as this.
The choice is up to you.
And, again, I agree with your friend.
Inviato dal mio SM-A405FN utilizzando Tapatalk
zzz2002 said:
Let's start by asking the question, are stock cell phones secure? The answer is very simple, NO! The list of entities watching you is nearly endless, starting with your provider, then the manufacturer ... None of them have your interests at heart. For most the objective is to separate you from your money. For others the objective is to collect information that can be used to manipulate you socially or politically.
So is third party software safer. Depending if it is open source or not. Closed source, probably not.Open source software is generally considered safer, for the simple reason that it is more difficult include malware in it. There is a caveat, the size of the development/user community matters - in general the larger the better - the more eyeballs on the developers the better.
Is "rooting" a good idea, for most users the answer is NO. It increases the security exposure which is not a good idea.
Click to expand...
Click to collapse
very well put and for the most part, I completely agree. However, I perhaps should have said, but when I say "secure", I am basically talking about unauthorised/malicious access. I believe that just about everything Google/FB and friends do IS malicious! However, we give them access (we are the self-basting turkeys) by buying an Android device and using Gmail, Google, Youtube or whatever else. Same goes for Apple users who use Siri and location services. The point being.... if Google tracks me on my Android device, I wouldn't call that "insecure", just anti-privacy and horrible in many others, but not a security hole for the context of this conversation. However, in order to remove Google and mainstream spyware/dragnet surveillance from my life, it's not as simple as just replacing the stock Android with a custom rom (and rooting), as that's like closing the front curtains but removing the back wall of my house!
I am coming to the conclusion that I have to choose between two evils, one is official spyware run by the likes of Google, and in doing so I protect myself from most hackers and exploits (As Google needs to keep its users safe from that to stay in business) - OR - I tell Google where to stick it's big fat nose, install a custom rom and root my device to gain the control needed to make that happen, but meanwhile expose myself to smaller and perhaps more overtly malicious attackers.
I wish there was a solution, and I wish there was even a happy medium. But when I want ultra security AND privacy (the latter being dependent on the former really), I think the only answer I can find so far, is to have no phone at all. Or perhaps an old pre internet phone for calls and texts, and a laptop for all data stuff, which can be secured/privacified to a much greater degree than a smart device can.
dannythechamp said:
very well put and for the most part, I completely agree. However, I perhaps should have said, but when I say "secure", I am basically talking about unauthorised/malicious access. I believe that just about everything Google/FB and friends do IS malicious! However, we give them access (we are the self-basting turkeys) by buying an Android device and using Gmail, Google, Youtube or whatever else. Same goes for Apple users who use Siri and location services. The point being.... if Google tracks me on my Android device, I wouldn't call that "insecure", just anti-privacy and horrible in many others, but not a security hole for the context of this conversation. However, in order to remove Google and mainstream spyware/dragnet surveillance from my life, it's not as simple as just replacing the stock Android with a custom rom (and rooting), as that's like closing the front curtains but removing the back wall of my house!
I am coming to the conclusion that I have to choose between two evils, one is official spyware run by the likes of Google, and in doing so I protect myself from most hackers and exploits (As Google needs to keep its users safe from that to stay in business) - OR - I tell Google where to stick it's big fat nose, install a custom rom and root my device to gain the control needed to make that happen, but meanwhile expose myself to smaller and perhaps more overtly malicious attackers.
I wish there was a solution, and I wish there was even a happy medium. But when I want ultra security AND privacy (the latter being dependent on the former really), I think the only answer I can find so far, is to have no phone at all. Or perhaps an old pre internet phone for calls and texts, and a laptop for all data stuff, which can be secured/privacified to a much greater degree than a smart device can.
Click to expand...
Click to collapse
Talking about a happy medium: I tried to setup a stock android nokia1 without Google. First of all: you don't need a Google account. Install f-droid. You can disable most Google apps. Sadly i need a stock phone app to receive calls and Google play services to get system updates. Disable all permissions of Google play services.
Good luck.
dannythechamp said:
he said that LineageOS is not safe to use as rooting is dangerous and exposes the devices to a plethora of attacks and vulnerabilities.
Click to expand...
Click to collapse
Ummm, that statement seems to imply that if you're running LineageOS then your device must also be rooted, which in my limited experience is incorrect. I flashed my several year old Huawei phone with LineageOS only about a week ago and that was my first experience with flashing a custom ROM so take anything I say with that in mind. My phone was not then and still isn't rooted, haven't decided on that yet and for now I see no need, for me personally anyway... one step at a time.
Do I feel that the security of my phone is now less secure with lineageOS? Well in the time I've owned the phone it hasn't seen any official system updates and the Android Security Patch level was from 2016, with LOS 14.1 the Android security patch level is November 2018, not the absolute latest but far better than before on the stock Huawei ROM... there are probably other things too but that's one thing that springs to mind, your experience may differ.
Like I said I'm not very experienced with all this and I may have misunderstood something in your friends reasoning, but if his concern is about rooting devices, it's perhaps a separate issue altogether. Anyway just my 2 cents worth...
As others have said, LineageOS is likely as secure as stock Android, probably even moreso. It often icludes more recent security patches, and it's open source. If I were you I would definitely go for the LOS.
But rooting can be a bit problematic. To be perfectly clear, rooting almost certainly does NOT create any additional security holes on it's own. If you root your phone without using shady Chinese software you are good.
However the rooting becomes a problem when you don't know what you're doing. If you accidentally allow root access to a malicious app you are 100% screwed. That's why people say rooting is dangerous. It's only dangerous if you misuse it. But the great thing is that you can just unroot your phone and you will be good to go.
I am late to this party, but I will comment anyway because computer security is a big part of what I do for a living, and android security is important to me because I am a rather militant privacy advocate and I use an android phone.
So.
If you want to fully secure the android system, and guarantee your privacy, you have to root the phone. Period. Full stop. There are many apps out there that require root to run that will greatly enhance your privacy and security. Afwall and Greenify are two that immediately come to mind.
That said, if you root your phone and you don't know what you are doing, you can indeed leave your phone in a very vulnerable state, without knowing it.
The basic issue is that, when you root, you gain complete and total access to the device. You can add or change or delete literally anything on the phone. This enables you to screw it up in a big way, and this also makes it easy for certain malware to take complete control of the device.
Now, there is malware out there which will silently root your phone for you, then take control, and you actually can block this malware by rooting it yourself and installing a root manager. But most malware does not do that and by rooting your phone then exposing it to that malware, you give the malware a level of access it would never have if the phone was not rooted.
For safety, unless you are technically sophisticated, you should not root. This limits YOUR access to your device, and keeps you from hosing it, and also limits what most malware can do. But it also prevents you from removing some built-in software that you don't want or that is spying on you, and it limits your ability to restrict the activity of some software that you want to have running, but you don't want to have able to do certain things.
In many ways the android phone is not built to serve YOUR interests; it is built to serve Google's interests, and the interests of those third parties who have paid money to have their apps placed on it by default. The facebook app immediately springs to mind; no one should have that malicious POS on their device because it sells you out completely. Unless you root, you cannot make the phone solely serve your interests.
LineageOS gives you the capability to turn root on, then turn it back off. Thus, using LOS, you can enable root, remove those noxious apps, and turn root off again. This, to my mind, is a decent compromise. Nonetheless, root is present on the phone and if you leave it on you can both (a) lock that phone down tight and make it fully secure, and (b) hose it completely if you make a mistake, and (c) leave it more vulnerable than stock if you don't know what you are doing.
So those who tell you that rooting is a bad idea...are more or less right. For most people, they are right. If you want a fully secure android, then you have to both root AND thoroughly educate yourself, which takes a lot of effort.
So, you decide.
Any word on LineageOS 17 for the Nexus 6?
Verstuurd vanaf mijn Nexus 6 met Tapatalk
dannythechamp said:
I posted this on a thread and then realised it probably belongs here instead, didnt realise there was a whole board for lineage.....
Hi all. I am just learning about LineageOS. I mainly want it for my kids, as I want NO google spyware/behaviour tracking in their life, no Youtube etc either. A friend advised me to try LineageOS, calling it a 'privacy based OS'. I then bought a used MotoG with LIneage on, a Google Asus tablet with Lineage on, and finally a Google Nexus again with LineageOS on. I was over the moon, picking up all three from a car boot sale dirt cheap, in mint condition too! BUT.... Another friend of mine, a software engineer and privacy 'expert' as far as I am concerned anyway - he said that LineageOS is not safe to use as rooting is dangerous and exposes the devices to a plethora of attacks and vulnerabilities. I just wondered what the opinions on here were about that?
I discussed it and said 'I just want privacy thats all', and he basically said "You cant have privacy without FIRST having security". Agree/Disagree? I am all ears! (this is all new to me, never flashed anything but my back side!)
Click to expand...
Click to collapse
Security does not equal privacy. Stock ROM is for those who are willing to sacrifice privacy for security and functionality.
Graphene and Lineage are for these people
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
So what realistically are the time frames on getting a new root and BL unlock for the snapdragon chipsets?
I ask since now the leak that happened means keys and other information are public.
Here's the thing about real security that has been properly implemented: a source leak doesn't compromise the security of the system. Thus, there is no realistic time frame, because there is no guarantee that a source leak will even result in a bootloader unlock method. A source leak will give insight into how the system works, and it might even expose a vulnerability, but even if revealed, it doesn't mean it will translate into a practical bootloader unlock method.
Imagine for example this purely hypothetical speculation: the persistent state of the OEM unlock bit, in the steady partition or wherever it is stored, is not encrypted or protected by a secure hash. While such a hypothetical vulnerability represents an attack vector, it would likely still be problematic to activate, possibly even requiring direct physical access to the device's eMMC IC.
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
I dont imagine it will be long.
FesterCluck said:
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
Click to expand...
Click to collapse
There is a lot there for sure. That said, the Snapdragon (cinammon) bootloader trees seem a lot lighter than the Exynos (strawberry) bootloader trees.
On the Exynos side, "SATURN/bootloader/lib/sbl_security/ddi.c implements get_oem_unlock_val() which is called in a variety of places. I'm still trying to understand the relationship between the two instances of the OEM Unlock flag, that is FROM_RPMB vs. FROM_PERSISTENT. In the case of the latter, this seems to simply be stored in the clear as the last byte in the PERSISTENT partition, where 0 means locked, and 1 means unlocked. As such, it can probably be readily written via JTAG or directly to the eMMC in a matter analogous to how the PERSISTENT partition is deleted to clear FRP state in many YouTube videos, though admittedly these both require special tools and invasive physical access.
I assume there exists at least conceptually similar implementation on the Snapdragon side, but so far I have not found it.
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
sjevtic said:
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
Click to expand...
Click to collapse
I'll move it to the "Guides and News" section since that would be the more appropriate section. Thanks for the shout out.
I'd be happy to donate to make progress. Just bought a new S20 and of course it has v2 BL. So lmk if there is anything needed.