Daer all
I have more question about setcon, setenforce.
At Lollipop, init can use setcon, setenforce in init.rc's early-init like
that..
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
write /sys/fs/selinux/checkreqprot 0
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
*setcon *u:r:init:s0
But from M os, It was deleted.
I think, if it was deleted, it would operate kernel domain.
But, in M os, it was operated init domain.
*In case of M OS, How to change domain kernel to init in init.rc except
setcon u:r:init:s0 ?*
Kingroot.apk using init domain by kernel's vulnerability, lt will change
untrusted_app to init domain, and than using setenforce and setcon.
Thanks.
2015-12-04 12:35 GMT+09:00 심현용 <[email protected]>:
> 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 <[email protected]>:
>
>>
>>
>> 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"<[email protected]>
>> *To:* [email protected];
>> *Cc:* <[email protected]>; "Stephen Smalley"<[email protected]>;
>>
>> *Sent:* 2015-12-02 (수) 11:23:19
>> *Subject:* Re: How to prevent kingroot.apk..
>>
>>
>>
>> On Dec 1, 2015 9:15 PM, "심현용" <[email protected]> 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 <[email protected]>:
>> >>
>> >>
>> >> On Nov 28, 2015 4:40 AM, "심현용" <[email protected]> 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 <[email protected]
>> >:
>> >> >>
>> >> >> 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, "심현용" <[email protected]> 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
>> >> >>> [email protected]
>> >> >>> To unsubscribe, send email to [email protected].
>> >> >>> To get help, send an email containing "help" to
>> [email protected].
>> >> >
>> >> >
>> >
>> >
>>
>
>
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
