Re: Bug on function.
Hi, Let me start the story in this way. Please note on param 10 onwards to
param 19. why is my param 1 merge with param 10 - 19.
dumbass@Lucifer:~$ ./repo.sh a 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
18 19 20
param 1: a
param 2: 1
param 3: 2
param 4: 3
param 5: 4
param 6: 5
param 7: 6
param 8: 7
param 9: 8
param 10: a0
param 11: a1
param 12: a2
param 13: a3
param 14: a4
param 15: a5
param 16: a6
param 17: a7
param 18: a8
param 19: a9
param 20: 10
*Execution Section. *the initial mail is successfully inserting the command
reboot into 18th param which trigger system reboot.
./repo.sh a 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
*Script Section*
#!/bin/bash
function gateway {
echo "param 1: $1"
echo "param 2: $2"
echo "param 3: $3"
echo "param 4: $4"
echo "param 5: $5"
echo "param 6: $6"
echo "param 7: $7"
echo "param 8: $8"
echo "param 9: $9"
echo "param 10: $10"
echo "param 11: $11"
echo "param 12: $12"
echo "param 13: $13"
echo "param 14: $14"
echo "param 15: $15"
echo "param 16: $16"
echo "param 17: $17"
echo "param 18: $18"
echo "param 19: $19"
echo "param 20: $20"
}
gateway $*
On Tue, Dec 8, 2015 at 3:58 PM, Kelvin Tan Thiam Teck
wrote:
> dumbass@Lucifer:~$ ./report.sh "echo ln -s /sbin/halt; mv halt ;reboot8 ;*
> reboot*" AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
> AAA AAA AAA AAA
> Before Passing Thru Function: echo ln -s /sbin/halt; mv halt ;reboot8 ;
> reboot AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
> AAA AAA AAA
> reboot: Need to be root
> 9th:
> 10th: echo0
> 11th: echo1
> 12th: echo2
> 13th: echo3
> 14th: echo4
> 15th: echo5
> 16th: echo6
> 17th: echo7
> ./report.sh: line 29: echo8: command not found
> 19th: echo9
> 20th: ln0
> dumbass@Lucifer:~$
>
>
> On Tue, Dec 8, 2015 at 3:27 PM, Pierre Gaston
> wrote:
>
>> On Tue, Dec 8, 2015 at 9:16 AM, Kelvin Tan Thiam Teck <
>> kelvin...@gmail.com> wrote:
>>
>>> Hi,
>>> Please try my payload on that script, before telling me what $@ and $*
>>> does. and see if my param1 injection will cause your system to reboot on
>>> 18th param. it has nothing to do with $@ & $*, it's another bugs on bash
>>> which i found out, similar to shockbash, except it's harder to execute due
>>> to the requirement for it to happen.
>>>
>>>
>>> Regards
>>> KT
>>>
>>>
>> But it's code injection because your script is badly written, it's not a
>> bug in bash.
>> It's badly written because without quotes around "$@" the parameters are
>> split into words and then you tell bash to execute one of these words.
>> Bash does what it is supposed to do in your example.
>>
>> And yes, there are many many way to write a script that allows code
>> injections.
>>
>> Shellshock was entirely different in that it allowed to inject code no
>> matter how the script was written..
>>
>>
>
Re: Bug on function.
On Tue, Dec 8, 2015 at 9:58 AM, Kelvin Tan Thiam Teck
wrote:
> dumbass@Lucifer:~$ ./report.sh "echo ln -s /sbin/halt; mv halt ;reboot8 ;*
> reboot*" AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
> AAA AAA AAA AAA
> Before Passing Thru Function: echo ln -s /sbin/halt; mv halt ;reboot8 ;
> reboot AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
> AAA AAA AAA
> reboot: Need to be root
> 9th:
> 10th: echo0
> 11th: echo1
> 12th: echo2
> 13th: echo3
> 14th: echo4
> 15th: echo5
> 16th: echo6
> 17th: echo7
> ./report.sh: line 29: echo8: command not found
> 19th: echo9
> 20th: ln0
> dumbass@Lucifer:~$
>
I think you misunderstand me, I'm not denying that you inject some code.
What I'm saying is that the bug is in your code.
Here is a simpler way to reproduce:
cat inject
#!/bin/bash
function foo {
"$2"
}
foo $*
$ ./inject "blah date"
Tue Dec 8 10:08:45 EET 2015
You can see that "date" is executed, but it's a bug in the script, $* is
split in 2 as it is supposed to and foo receives 2 arguments.
you can fix the bug using "$@"
$ vi inject
$ cat inject
#!/bin/bash
function foo {
"$2"
}
foo "$@"
$ ./inject "blah date"
./inject: line 3: : command not found
Now the arguments are not split again and foo receives only one argument,
hence the error.
As I said, there are many pitfalls in shellscript that's why allowing
running a script with more privilege than the user have is dangerous.
Re: Bug on function.
eh thanks, listed them to show that my param from 10th to 18 is affected,
instead of 18th param only.
On Tue, Dec 8, 2015 at 4:13 PM, Pierre Gaston
wrote:
>
>
> On Tue, Dec 8, 2015 at 9:58 AM, Kelvin Tan Thiam Teck > wrote:
>
>> dumbass@Lucifer:~$ ./report.sh "echo ln -s /sbin/halt; mv halt ;reboot8 ;*
>> reboot*" AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
>> AAA AAA AAA AAA
>> Before Passing Thru Function: echo ln -s /sbin/halt; mv halt ;reboot8 ;
>> reboot AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
>> AAA AAA AAA
>> reboot: Need to be root
>> 9th:
>> 10th: echo0
>> 11th: echo1
>> 12th: echo2
>> 13th: echo3
>> 14th: echo4
>> 15th: echo5
>> 16th: echo6
>> 17th: echo7
>> ./report.sh: line 29: echo8: command not found
>> 19th: echo9
>> 20th: ln0
>> dumbass@Lucifer:~$
>>
>
> I think you misunderstand me, I'm not denying that you inject some code.
> What I'm saying is that the bug is in your code.
> Here is a simpler way to reproduce:
>
> cat inject
> #!/bin/bash
> function foo {
> "$2"
> }
>
> foo $*
> $ ./inject "blah date"
> Tue Dec 8 10:08:45 EET 2015
>
> You can see that "date" is executed, but it's a bug in the script, $* is
> split in 2 as it is supposed to and foo receives 2 arguments.
>
> you can fix the bug using "$@"
> $ vi inject
> $ cat inject
> #!/bin/bash
> function foo {
> "$2"
> }
>
> foo "$@"
> $ ./inject "blah date"
> ./inject: line 3: : command not found
>
>
> Now the arguments are not split again and foo receives only one argument,
> hence the error.
>
> As I said, there are many pitfalls in shellscript that's why allowing
> running a script with more privilege than the user have is dangerous.
>
>
>
Re: Bug on function.
dumbass@Lucifer:~$ ./report.sh 'echo' 1 2 3 4 5 6 7 8 9 10
param 1 : echo
param 2 : 1
param 3 : 2
param 4 : 3
param 5 : 4
param 6 : 5
param 7 : 6
param 8 : 7
param 9 : 8
param 10 : echo0
param 11 : echo1
param 12 : echo2
param 13 : echo3
param 14 : echo4
param 15 : echo5
param 16 : echo6
param 17 : echo7
param 18 : echo8
param 19 : echo9
param 20 : 10
param 21 : 11
param 22 : 12
param 23 : 13
param 24 : 14
param 25 : 15
param 26 : 16
param 27 : 17
param 28 : 18
param 29 : 19
param 30 : 20
param 31 : 21
param 32 : 22
param 33 : 23
param 34 : 24
param 35 : 25
param 36 : 26
param 37 : 27
param 38 : 28
param 39 : 29
param 40 : 30
On Tue, Dec 8, 2015 at 4:15 PM, Kelvin Tan Thiam Teck
wrote:
> eh thanks, listed them to show that my param from 10th to 18 is affected,
> instead of 18th param only.
>
> On Tue, Dec 8, 2015 at 4:13 PM, Pierre Gaston
> wrote:
>
>>
>>
>> On Tue, Dec 8, 2015 at 9:58 AM, Kelvin Tan Thiam Teck <
>> kelvin...@gmail.com> wrote:
>>
>>> dumbass@Lucifer:~$ ./report.sh "echo ln -s /sbin/halt; mv halt ;reboot8
>>> ;* reboot*" AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
>>> AAA AAA AAA AAA AAA
>>> Before Passing Thru Function: echo ln -s /sbin/halt; mv halt ;reboot8 ;
>>> reboot AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
>>> AAA AAA AAA
>>> reboot: Need to be root
>>> 9th:
>>> 10th: echo0
>>> 11th: echo1
>>> 12th: echo2
>>> 13th: echo3
>>> 14th: echo4
>>> 15th: echo5
>>> 16th: echo6
>>> 17th: echo7
>>> ./report.sh: line 29: echo8: command not found
>>> 19th: echo9
>>> 20th: ln0
>>> dumbass@Lucifer:~$
>>>
>>
>> I think you misunderstand me, I'm not denying that you inject some code.
>> What I'm saying is that the bug is in your code.
>> Here is a simpler way to reproduce:
>>
>> cat inject
>> #!/bin/bash
>> function foo {
>> "$2"
>> }
>>
>> foo $*
>> $ ./inject "blah date"
>> Tue Dec 8 10:08:45 EET 2015
>>
>> You can see that "date" is executed, but it's a bug in the script, $* is
>> split in 2 as it is supposed to and foo receives 2 arguments.
>>
>> you can fix the bug using "$@"
>> $ vi inject
>> $ cat inject
>> #!/bin/bash
>> function foo {
>> "$2"
>> }
>>
>> foo "$@"
>> $ ./inject "blah date"
>> ./inject: line 3: : command not found
>>
>>
>> Now the arguments are not split again and foo receives only one argument,
>> hence the error.
>>
>> As I said, there are many pitfalls in shellscript that's why allowing
>> running a script with more privilege than the user have is dangerous.
>>
>>
>>
>
Re: Bug on function.
On Tue, Dec 8, 2015 at 10:29 AM, Kelvin Tan Thiam Teck
wrote:
> dumbass@Lucifer:~$ ./report.sh 'echo' 1 2 3 4 5 6 7 8 9 10
> param 1 : echo
> param 2 : 1
> param 3 : 2
> param 4 : 3
> param 5 : 4
> param 6 : 5
> param 7 : 6
> param 8 : 7
> param 9 : 8
> param 10 : echo0
> param 11 : echo1
> param 12 : echo2
> param 13 : echo3
> param 14 : echo4
> param 15 : echo5
> param 16 : echo6
> param 17 : echo7
> param 18 : echo8
>
> always hard to understand what you mean by a simple output...ok your other
problem is that you need:
echo "${11}" to display the 11th argument, echo $11 is really the same as
echo "${1}"1, it appends a 1 after "$1"
set -- one two three four five six seven eight nine ten eleven;echo
"$11";echo "${11}"
one1
eleven
Re: Bug on function.
On Tue, Dec 08, 2015 at 09:45:29AM +0800, Kelvin Tan Thiam Teck wrote:
> hi, there's a bug on function that allow attacker to inject parameters.
> function Gateway {
> unset param
> param[7]="$8"
> piaram[8]="$9"
> param[9]="$10"
> param[10]="$11"
> param[11]="$12"
> param[12]="$13"
> param[13]="$14"
> param[14]="$15"
> param[15]="$16"
> param[16]="$17"
> param[17]="$18"
> param[18]="$19"
> #echo "After Passing Thru Function: ${param[@]}"
> echo "9th: `$9`"
Your bug is right there on that line. You have backticks around $9 which
means you execute the value of $9 as a command. This is your function's
fault, not bash's fault.
bash process substitution weird behavior
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall
uname output: Linux EliteBook 4.2.0-19-generic #23-Ubuntu SMP Wed Nov 11
11:39:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
1.
BASH$ { echo 111; echo 222 ;} 2> >( echo -en "\e[01;31m" >&2; read line; echo
"$line" >&2; echo -en "\e[0m" >&2 ) >&2
111# result is one line and red-colored that is expected behavior.
2.
# If i remove ">&2" that is at the end of command
# result is two lines with white-colored that is also expected behavior.
BASH$ { echo 111; echo 222 ;} 2> >( echo -en "\e[01;31m" >&2; read line; echo
"$line" >&2; echo -en "\e[0m" >&2 )
111# white colored
222# white colored
3.
# If i add external "date" command in the middle of two echo commands
# result is in red-colored after external date command output
# i think there must be no red-colored because { echo 111; date; echo 222 ;}
only direct to stdout
BASH$ { echo 111; date; echo 222 ;} 2> >( echo -en "\e[01;31m" >&2; read line;
echo "$line" >&2; echo -en "\e[0m" >&2 )
111 # white colored
Tue Dec 8 20:33:33 KST 2015 # red colored
222 # red colored
Re: Bug on function.
On 2015-12-08 08:16, Kelvin Tan Thiam Teck wrote: Hi, Please try my payload on that script, before telling me what $@ and $* does. and see if my param1 injection will cause your system to reboot on 18th param. it has nothing to do with $@ & $*, it's another bugs on bash which i found out, similar to shockbash, except it's harder to execute due to the requirement for it to happen. Regards KT Hi, I tried your payload on that script, using Bash 4.2.37(1)-release. It behaves exactly as expected: when calling the Gateway function, $* expands the script's "$1" to separate words and "reboot" becomes the 9th positional parameter to the function. Then 'echo "9th: `$9`"' tries to execute 'reboot' (and fails since I'm not root, in my case). Note all other "echo"s don't have those backticks. Nothing special happens on param 18 since $18 expands as expected to "$1"8 = "echo8" inside the function (and that command does not exist, at least on my system). Please provide your output to that script (not run as root so as not to make the system reboot) if it's different from what I describe above. Regards, Quentin
Re: Bug on function.
On 2015-12-08 02:45, Kelvin Tan Thiam Teck wrote:
hi, there's a bug on function that allow attacker to inject
parameters.
./report.sh "echo ln -s /sbin/halt; mv halt ;reboot8 ; reboot" AAA AAA
AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
AAA
#!/bin/bash
function library {
echo ${@}
}
function Gateway {
unset param
param[7]="$8"
piaram[8]="$9"
param[9]="$10"
param[10]="$11"
param[11]="$12"
param[12]="$13"
param[13]="$14"
param[14]="$15"
param[15]="$16"
param[16]="$17"
param[17]="$18"
param[18]="$19"
#echo "After Passing Thru Function: ${param[@]}"
echo "9th: `$9`"
echo "10th: $10"
echo "11th: $11"
echo "12th: $12"
echo "13th: $13"
echo "14th: $14"
echo "15th: $15"
echo "16th: $16"
echo "17th: $17"
$18
echo "19th: $19"
echo "20th: $20"
}
echo "Before Passing Thru Function: $*"
Gateway $*
Hi,
I think you should read the "Special Parameters" and "Parameter
Expansion" sections of the Bash man page.
Specifically:
* $* does not expand parameters as separate words (as "$@" does)
* positional parameters with more than 1 digit require braces: "${11}"
Cheers,
Quentin
Re: bash process substitution weird behavior
On Tue, Dec 08, 2015 at 09:03:08PM +0900, Hyunho Cho wrote:
> # result is in red-colored after external date command output
> # i think there must be no red-colored because { echo 111; date; echo 222 ;}
> only direct to stdout
>
> BASH$ { echo 111; date; echo 222 ;} 2> >( echo -en "\e[01;31m" >&2; read
> line; echo "$line" >&2; echo -en "\e[0m" >&2 )
>
> 111 # white colored
> Tue Dec 8 20:33:33 KST 2015 # red colored
> 222 # red colored
What you have here is a race condition.
You are launching a background process (echo -en ...) which writes to
the shell's stderr, then tries to read from stdin, then writes some
more stuff to the shell's stderr.
While that background job is running, you write various lines to the
shell's stdout.
The order of the arrival of the output of the background job (echo -en)
and the output of the foreground job (echo 111) is not predictable.
