Thanks to AndrewT who posted a link on chat, having this research paper as a refernce in one of the answers. This answer is entirely based on the this paper (May 2015) and highlights common user understandable aspects ( it has a lot of security related material for those interested)
What are the pros and cons apart from above?
If a device has both options - app based rooting and rooting by methods by developers, which one should I opt for?
Answer: It's all about malware vulnerability. Using Root exploits is a HUGE security risk and that over-weighs any other advantages
What is Soft Root and Hard Root?
Soft Root : Root is obtained directly by
running a piece of software (i.e., root exploits)- either by directly installing on the device or requiring adb shell through a PC connection
Hard Root : Root is obtained by flashing su binary externally via an update package or ROM
Malware Threat - in general
Even though legitimate, many convenient one-click root methods operate by exploiting vulnerabilities in the Android system. If not carefully controlled, such exploits can be abused by malware author to gain unauthorized root privilege.
As described in the Android Malware Genome Project , 36.7% ( of 1260 ) malware samples had embedded at least one root exploit.
These well-engineered exploits are not well protected, it is extremely dangerous if they fall in the wrong hands.
Who are major root providers and broadly, how does it work?
What are the types of root expolits ?
The paper covers 78 exploits studied. In general , the order of impact ( from the highest to lowest) :
Kernel Exploits: Due to its privileged position, targeting Linux Kernel is natural to achieve full control over an Android device- example ,TowelRoot
Library Exploits: the exploits targeting libraries that are used by Android system processes, or external libraries used for supporting different applications, example ZergRush exploit , libsysutils used by Volume Manager daemon
Application and Application Framework Application layer root exploits : exploits targeting system applications or services, mostly include vulnerable logics introduced by setuid utilities, system applications, or services. example is a vulnerable setuid utility that is only present on XoomFE devices
that has a command injection vulnerability
Vendor-Specific Kernel or Drivers: Vendors either customize the kernel (e.g., Qualcomm’s custom Linux kernel branch) or provide vendor-specific device drivers for various peripherals (e.g., camera, sound). Such code runs inside the kernel space and the compromise of which can also lead to full control over the device.
Number wise , exploits are as in figure below
How difficult is it to lay your hands on Exploit (Source or Binary) ?
Very easy. Easily available from Google search, making it a cake walk for malware authors to leverage such exploits. Googling for 73 exploits lead to 68 of them being available - 46 with source code and 22 with binaries
How do these exploits work?
Major requirements for exploits to work (ordered from most difficult to least) ( malware tag has a lot of these instances)
Requiring user interactions: (6 out of 78 studied)
- Asking the user to download an app and manually interrupt the installation
- Asking the user to boot into recovery at least once .
- Asking the user to manually put the device into “battery
saving†mode .
- Asking the user to open a vendor specific app and hit a button
Requiring adb shell through a PC connection: (17 out of 78 studied). For some exploits, adb shell connection is required because of the following most common reasons:
The exploit can successfully modify a setting in local.prop which enables root for adb shell only.
The exploit needs to write to a file owned by group shell and group-writable (not world-writable)
The exploit targets the adb daemon process that requires the attack process to run with shell user. For instance, the Rage Against the Cage exploit targets the vulnerability of adb daemon’s missing check on return value of setuid()
Reboot: (6 out of 78 studied) Generally, many root exploits require at least one reboot. For instance, a symbolic link attack would allow an attacker to delete a file owned by system with weak permission, to setup a link at the same location to a protected file. After a reboot, the corresponding init scripts would attempt to change the permission of the original file to world-writable, which in reality changes the permission of the linked file
None or permission: (44 out of 78 studied) The exploits in this category have no hard requirements, however, some of them may require certain Android permissions like READ LOGS in order for the process owner to be placed in certain user group.
Can these exploits be detected by Anti-Virus ?
Since the root exploits are highly sensitive and may be leveraged by various Android malware, it is expected that anti-virus software on Android platform can identify most of them, including the ones implemented by root providers. Overall, the result shows that the state-of-the-art security products on Android platform still cannot address root exploits effectively
4 representative Android anti-virus products were used to test the largest provider (name not revealed) having 167 exploits. Because originally downloaded exploits from the providers database have packed the actual exploit code and employed a tamper-detection mechanism, study crafted 3 different versions for every exploit:
Original exploit fetched directly from providers servers, with
packing and tamper-detection on.
Unpacked exploit, which will expose all actual exploit logic to
anti-virus products.
Re-packed exploit with tamper-detection disabled.
Exploit binaries engineered by large root providers are surprisingly “clean†as all major anti-virus software have difficulty detecting them as table below shows
Conclusion
Simple. Stay away from Soft Root methods unless you are capable of dealing with the consequences