Dear HAN
Your right.
Kingroot.apk will change untrusted_app to init domain like bellow.
u:r:init:s0 exe ->
/data/data/com.kingroot.kinguser/app_workspace/data/com.kingroot.RushRoot/krsdk/play/winkle32
you mentioned,
> Maybe I can add some codes to force a crash when kingroot binaries are
being changed to init.
*where is the point in kernel source?*
>However, I've added some points in SELinux and kernel, but I couldn't find
it.
>Where would be a great point to find that?
I think that domain is access to memory in /sys/fs/selinux path.
I found that these files were changed after rooting. (time changed in this
path)
but enforce is not changed during rooting.. when I check cat
/sys/fs/selinux/enforce, but It is still 1.
So I think It may be direct kernel memory attack.
/sys/fs/selinux/$ ll
-rw-rw-rw- root root 0 1969-12-31 19:00 access
dr-xr-xr-x root root 1969-12-31 19:00 avc
dr-xr-xr-x root root 1969-12-31 19:00 booleans
-rw-r--r-- root root 0 1969-12-31 19:00 checkreqprot
*dr-xr-xr-x root root 2015-12-03 02:55 class*
--w------- root root 0 1969-12-31 19:00 commit_pending_bools
-rw-rw-rw- root root 0 1969-12-31 19:00 context
-rw-rw-rw- root root 0 1969-12-31 19:00 create
-r--r--r-- root root 0 1969-12-31 19:00 deny_unknown
--w------- root root 0 1969-12-31 19:00 disable
-rw-r--r-- root root 0 1969-12-31 19:00 enforce
dr-xr-xr-x root root 1969-12-31 19:00 initial_contexts
-rw------- root root 0 1969-12-31 19:00 load
-rw-rw-rw- root root 0 1969-12-31 19:00 member
-r--r--r-- root root 0 1969-12-31 19:00 mls
crw-rw-rw- root root 1, 3 1969-12-31 19:00 null
-r--r--r-- root root 450870 1969-12-31 19:00 policy
*dr-xr-xr-x root root 2015-12-03 02:55 policy_capabilities*
-r--r--r-- root root 0 1969-12-31 19:00 policyvers
-r--r--r-- root root 0 1969-12-31 19:00 reject_unknown
-rw-rw-rw- root root 0 1969-12-31 19:00 relabel
-r--r--r-- root root 0 1969-12-31 19:00 status
-rw-rw-rw- root root 0 1969-12-31 19:00 user
It will make kernel source in android/kernel/security/selinux/selinuxfs.c.
And in case of permissive mode, It may be changed memory attack in
*alloc_page(GFP_KERNEL|__GFP_ZERO)'s
status->enforcing adress.*
How to read kernel that kernel memory..
This is source to change SELinux status, in
/android/security/selinux/ss/status.c
struct page *selinux_kernel_status_page(void)
{
struct selinux_kernel_status *status;
struct page *result = NULL;
mutex_lock(&selinux_status_lock);
if (!selinux_status_page) {
*selinux_status_page = alloc_page(GFP_KERNEL|__GFP_ZERO);*
if (selinux_status_page) {
status = page_address(selinux_status_page);
status->version = SELINUX_KERNEL_STATUS_VERSION;
status->sequence = 0;
*status->enforcing = selinux_enforcing;*
/*
* NOTE: the next policyload event shall set
* a positive value on the status->policyload,
* although it may not be 1, but never zero.
* So, application can know it was updated.
*/
status->policyload = 0;
status->deny_unknown = !security_get_allow_unknown();
}
}
result = selinux_status_page;
mutex_unlock(&selinux_status_lock);
return result;
Thank you, your detail debugging.
2015-12-04 11:54 GMT+09:00 HAN <kk...@naver.com>:
>
>
> Dear all.
>
>
>
> I have found this same issue in my custom ROM as well.
>
> My ROM is using Lollipop 5.1 with Kernel 3.4.
>
>
>
> Kingroot apk downloads so many binaries&scripts from there server and
>
> try to get root access with various methods.
>
>
>
> I was trying to find a vulnerable point in kernel,
>
> it's difficult because they're using so many binaries to root though.
>
>
>
> It is a problem that kingroot binares are changed to init domain by
> vulnerable kernel.
>
>
>
> Now, I'm trying to add some codes in kernel to look for the attack
> location.
>
> Maybe I can add some codes to force a crash when kingroot binaries are
> being changed to init. Afater crash, I can collect a crash dump and will be
> able to find a root point in kernel.
>
>
>
> However, I've added some points in SELinux and kernel, but I couldn't find
> it.
>
> Where would be a great point to find that?
>
>
>
> Thanks
>
>
>
> HAN
>
>
>
>
>
> -----Original Message-----
> *From:* "William Roberts"<bill.c.robe...@gmail.com>
> *To:* jonesn5...@gmail.com;
> *Cc:* <seandroid-list@tycho.nsa.gov>; "Stephen Smalley"<s...@tycho.nsa.gov>;
>
> *Sent:* 2015-12-02 (수) 11:23:19
> *Subject:* Re: How to prevent kingroot.apk..
>
>
>
> On Dec 1, 2015 9:15 PM, "심현용" <jonesn5...@gmail.com> wrote:
> >
> > Dear William.
> >
> > Thank you for your explanation.
> >
> > I'm doing debugging this apk a bit more.
> >
> >
> > > Really only kernel should be allowed to transition to init. So we
> likely want to verify the policy has this.
> >
> > As your mention, I want to find kernel source where domain changed
> untrusted_app to init.
> >
> > But, I'm SELinux developer not kernel developer.. so please help me,
> where can i find this source where change init domain in kernel?
>
> You might not even need to go that deep. Just look at what the policy
> allows. The kernel enforces the policy, assuming no defects or tampering.
> The tampering could be from a kernel exploit. Use tools like sesearch.
>
> The code that changes to init domain is likely part of the payload of the
> exploit run by kingroot.
> >
> > I always thank you for your help..
> >
> > Thanks.
> >
> >
> > 2015-11-29 22:55 GMT+09:00 William Roberts <bill.c.robe...@gmail.com>:
> >>
> >>
> >> On Nov 28, 2015 4:40 AM, "심현용" <jonesn5...@gmail.com> wrote:
> >> >
> >> > Thank you for your quick reply.
> >> >
> >> > I checked more detail about kingroot.
> >> >
> >> > It using chcon using in their toolbox.
> >> >
> >> > postroot.sh
> >> > kr_set_perm() {
> >> > #if [ -f "$5" -o -d "$5" ]; then
> >> > $MY_TOOLBOX chown $1.$2 $5
> >> > if [ -f "/system/bin/chcon" ]; then
> >> > $MY_TOOLBOX chcon $3 $5
> >> > fi
> >> > $MY_TOOLBOX chmod $4 $5
> >> > #fi
> >> > }
> >> >
> >> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755 /data/data-lib
> >> >
> >> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
> /data/data-lib/king
> >> >
> >> > kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
> /data/data-lib/com.kingroot.RushRoot
> >> >
> >> > kr_set_perm 0 0 u:object_r:system_file:s0 00755 /system/xbin/krdem
> >> >
> >> > kr_set_perm 0 0 u:object_r:system_file:s0 00755 $1/xbin/supolicy
> >> >
> >> >
> >> > so, their apk file and other daemon will change system_file,
> >> >
> >> > Why chcon needed in toolbox?
> >> >
> >> > It is very vulnerable to hackers..
> >>
> >> Whether or not chcon exists is irrelevant. One could bundle that in the
> apk if they wanted to. Code is never a security boundary. The policy would
> have to allow it to chcon and do other things. I bet their is more to the
> story then just calling chcon.
> >>
> >> >
> >> > even that it could change init domain..
> >> >
> >> > Kingroot apk also changed to init domain during rooting process..
> >>
> >> I'm a bit remote at the moment (sitting in the middle of a forest
> hunting deer) but the policy shouldn't allow domain transitions from
> untrusted app to init. Really only kernel should be allowed to transition
> to init. So we likely want to verify the policy has this. I can't recall
> offhand.
> >>
> >> >
> >> >
> >> > Is it possible disable chcon in toolbox?
> >> >
> >> > Thanks.
> >> >
> >> > 2015-11-27 23:05 GMT+09:00 William Roberts <bill.c.robe...@gmail.com
> >:
> >> >>
> >> >> From what I can tell, kingroot bundles up exploits on a server and
> then figures out what one will work on your device and tries it.
> >> >>
> >> >> I would start by patching and fixing all known vulnerabilities for a
> given system.
> >> >>
> >> >> From there, you state it does a setenforce 0. IIRC only init has
> this capability, so somehow its already gotten its process context to init.
> You could remove this permission and pass enforcing mode via kernel
> cmdline, but that's not going to help you here. If it was able to change
> process context to init, its likely doing kernel exploits and poking at
> kernel data structures. A good example of an exploit that does this would
> be towel root. In a nutshell, any exploit that provides the ability to
> tamper with kernel memory, especially strict cred and the auxillary void *
> for lsms, all bets are off for selinux.
> >> >>
> >> >> You could start to see if a change to policy would prevent the
> proper execution of a given exploit. However something like towel root used
> a futex vulnerability, their is no selinux controls on futex usage, so its
> very exploit dependent.
> >> >>
> >> >> You could, as an additional safeguard, use some type of higher
> privilege mode of execution (think trustzone or hypervisor) to protect
> various kernel pages like the cred and selinux structures in memory, so
> even the kernel has to trap to you to write these pages. The techniques to
> do this are highly architecture specific.
> >> >>
> >> >> On Nov 27, 2015 5:42 AM, "심현용" <jonesn5...@gmail.com> wrote:
> >> >>>
> >> >>> Dear all.
> >> >>>
> >> >>> Thank you for your always kindly explain.
> >> >>> I have some question about rooting app 'kingroot'
> >> >>>
> >> >>> You can install apk bellow site.
> >> >>> http://www.kingroot.net/
> >> >>>
> >> >>> It can root device though supolicy.
> >> >>> I think It use to policy-inject, It will change setenforce 0
> (permissive mode)
> >> >>> and will change permissive per domain like init, init_shell,
> toolbox, etc...
> >> >>>
> >> >>> How can I prevent this apk's tool.
> >> >>> Is it any method to fix?
> >> >>>
> >> >>> Please help me..
> >> >>>
> >> >>> Thanks.
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Seandroid-list mailing list
> >> >>> Seandroid-list@tycho.nsa.gov
> >> >>> To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
> >> >>> To get help, send an email containing "help" to
> seandroid-list-requ...@tycho.nsa.gov.
> >> >
> >> >
> >
> >
>
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
