shc
shc copied to clipboard
neurobin
shc compiled not protected anymore with Linux kernel >= 4.2
There has been radical changes in Linux kernel "fs/proc/cmdline.c" and now shc compiled script can be extracted completely using /proc/[pid]/cmdline!
Note that this will happen with all kernel versions starting from 4.2. Example below is from Ubuntu 15.10 that is using 4.2.0-19-generic. I have also tested all available versions of shc.
It seems that copying example here is not exactly accurate (due to github web). There is lots of space betwen "./test.sh.x-c" and "#! /bin/bash" when you watch it from /proc/22366/cmdline.
$ cat test.sh
! /bin/bash
while true do sleep 10 done
$ shc -f test.sh $ ./test.sh.x & [1] 22366 $ cat /proc/22366/cmdline ./test.sh.x-c #! /bin/bash
while true do sleep 10 done
I can confirm this.
The mitigation is that cmdline only shows the first bytes of the script so you can add a lot of junk at the beginning to hide your code. However, for what I've read, somebody can change the size of the cmdline contents by changing the kernel source code, recompiling it and executing the script.
I am in kernel 4.4.0 and just checked it:
$ cat >test.sh
#! /bin/bash
#
while true
do
sleep 10
done
$ shc -U -f test.sh
$ sudo ./test.sh.x &
[3] 23741
$ cat /proc/23741/cmdline
sudo./test.sh.x
If you don't use the -U flag, then the cmdline will expose the script.
-U stands for Untraceable (The -T option was reversed and renamed to -U from shc-3.9.1)
I am using debian 9 (stretch) and kernel 4.9
I followed the above procedure to compile a simple script with -U and -f When i run the script using sudo the code is indeed hidden.
However when i run it as a simple user without sudo the code is revealed
./test.sh.x &
cat /proc/30064/cmdline
./test.sh.x-c #!/bin/bash
#
while true
do
sleep 10
done
I also tested switching to user root with sudo su and then run it without sudo and it revealed as well.
Is this a known standing bug? Should I compile with other options?
im on 4.4.0-97-generic, ubuntu 16.04 summary:
- as normal user, cant run binary after adding -U , premission denied.
- as sudo, the script is hidden.
- as sudo su, the script is NOT hidden
$ ./shc -U -f abc.sh $ ./abc.sh.x ./abc.sh.x: Operation not permitted Killed
$ sudo ./abc.sh.x & [1] 804 $ cat /proc/804/cmdline sudo./abc.sh.x -----> hidden, fine.
$ sudo su #./abc.sh.x & [1] 841 #cat /proc/841/cmdline ./abc.sh.x-c
#! /bin/bash ------> not hidden. while true do sleep 10 done
This should be fixed in the last commit ... you need to use -H (Hardening) flag
'cat /proc/[pid]/cmdline' issue is covered in latest shc version but still you could reveal all script code with simple 'ps auxww' command even if you use the '-H' flag.
are you sure about that 'ps auxww' ? i can not get the script revealed with that.
Yes. i'm running the script as root and this is 'ps auxww' output:
root 9109 0.0 0.0 4348 804 pts/4 S 22:38 0:00 ./test.sh.x root 9110 0.0 0.0 4348 88 pts/4 S 22:38 0:00 ./test.sh.x root 9111 0.0 0.0 11372 2932 pts/4 S 22:38 0:00 sh -c #! /bin/bash while true do sleep 10 done root 10286 0.0 0.0 6004 816 pts/4 S 22:38 0:00 sleep 10 root 10521 0.0 0.0 13000 2420 pts/4 R+ 22:38 0:00 ps aux
Indeed, confirmed i will look at this when i have the time, nice finding by the way !
@TJokiel solved here https://github.com/Intika-Linux-Apps/SHC-Hardening/tree/master i don't know if this will be merged
issue still exists in original version and in "solved" version "https://github.com/Intika-Linux-Apps/SHC-Hardening/tree/master" ps aux|grep script.sh.c.x shows code. I'm on Linux 4.4.0-138-generic x86_64
@felix303 with the solved version with what parameter did you built your sh script ?
just checked with "shc -H -f script.sh -o whatever" it's protected it does not leak... just try again with '-H' or '-U' ... If you have further issue, please post the complete steps you are doing
Also this have been merged (i don't know if it's on release but it's merged... )
just checked with "shc -H -f script.sh -o whatever" it's protected it does not leak... just try again with '-H' or '-U' ... If you have further issue, please post the complete steps you are doing
No, it is not a good option for "positional parameters", please add this feature as soon as possible @intika
