SQL style injection with bash input?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
Given a script that allows anyone to provide input. Is there any input that can break out of a variable. For example given the following script:
echo $1
Would there be anyway to make $1
something like:
text && rm -rf /
I'm trying to do something like the above and it doesn't work.
Can anyone confirm that the above would be impossible?
bash security
 |Â
show 1 more comment
up vote
6
down vote
favorite
Given a script that allows anyone to provide input. Is there any input that can break out of a variable. For example given the following script:
echo $1
Would there be anyway to make $1
something like:
text && rm -rf /
I'm trying to do something like the above and it doesn't work.
Can anyone confirm that the above would be impossible?
bash security
1
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
1
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
1
In this case, ifecho
supports option-e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.
â wjandrea
Nov 5 '17 at 3:08
 |Â
show 1 more comment
up vote
6
down vote
favorite
up vote
6
down vote
favorite
Given a script that allows anyone to provide input. Is there any input that can break out of a variable. For example given the following script:
echo $1
Would there be anyway to make $1
something like:
text && rm -rf /
I'm trying to do something like the above and it doesn't work.
Can anyone confirm that the above would be impossible?
bash security
Given a script that allows anyone to provide input. Is there any input that can break out of a variable. For example given the following script:
echo $1
Would there be anyway to make $1
something like:
text && rm -rf /
I'm trying to do something like the above and it doesn't work.
Can anyone confirm that the above would be impossible?
bash security
asked Nov 4 '17 at 20:43
Philip Kirkbride
2,2922470
2,2922470
1
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
1
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
1
In this case, ifecho
supports option-e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.
â wjandrea
Nov 5 '17 at 3:08
 |Â
show 1 more comment
1
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
1
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
1
In this case, ifecho
supports option-e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.
â wjandrea
Nov 5 '17 at 3:08
1
1
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
1
1
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
1
1
In this case, if
echo
supports option -e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.â wjandrea
Nov 5 '17 at 3:08
In this case, if
echo
supports option -e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.â wjandrea
Nov 5 '17 at 3:08
 |Â
show 1 more comment
3 Answers
3
active
oldest
votes
up vote
5
down vote
accepted
In 2014, there was a exploit in the wild for a Bash vulnerability nicknamed Shellshock. Like most vulnerabilities in common software, a Common Vulnerabilities and Exposures (CVE) Bulletin was released, CVE-2014-6278. Shellshock is a remote exploit for Bash which allowed arbitrary code execution on the remote host via several attack vectors in common server software stacks including Apache's cgi modules as well as OpenSSH.
The vulnerability affects all versions of Bash from 1989 until 2014 when it was patched once easily created exploits were widely demonstrated.
For further reading:
OWASP Shellshock Presentation, PDF
NIST CVE-2014-6278
ServerFault Shellshock Question, 2014
I believe most versions available in Distro Repos have been patched.
Correction: Shellshock is a family of vulnerabilities... CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
And, it's good to remember that these can easily affect a LAN if there exists port forwarding for things like Apache web servers or SSH... as well as any unpatched (and probably unpatchable) Internet of Things devices.
add a comment |Â
up vote
4
down vote
Command separators are processed before expansions, therefore there is no way that n
, ;
, &
, &&
, or ||
in a variable will ever have an effect unless the variable contents are eval
ed.
add a comment |Â
up vote
3
down vote
It seems like globbing is a vulnerability:
$ echo 'echo $1' > injection.sh
$ bash injection.sh '/*'
/bin /boot /dev /etc /home /lib /lib64 /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var
This is why you always quote vars:
$ echo 'echo "$1"' > injection.sh
$ bash injection.sh '/*'
/*
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
In 2014, there was a exploit in the wild for a Bash vulnerability nicknamed Shellshock. Like most vulnerabilities in common software, a Common Vulnerabilities and Exposures (CVE) Bulletin was released, CVE-2014-6278. Shellshock is a remote exploit for Bash which allowed arbitrary code execution on the remote host via several attack vectors in common server software stacks including Apache's cgi modules as well as OpenSSH.
The vulnerability affects all versions of Bash from 1989 until 2014 when it was patched once easily created exploits were widely demonstrated.
For further reading:
OWASP Shellshock Presentation, PDF
NIST CVE-2014-6278
ServerFault Shellshock Question, 2014
I believe most versions available in Distro Repos have been patched.
Correction: Shellshock is a family of vulnerabilities... CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
And, it's good to remember that these can easily affect a LAN if there exists port forwarding for things like Apache web servers or SSH... as well as any unpatched (and probably unpatchable) Internet of Things devices.
add a comment |Â
up vote
5
down vote
accepted
In 2014, there was a exploit in the wild for a Bash vulnerability nicknamed Shellshock. Like most vulnerabilities in common software, a Common Vulnerabilities and Exposures (CVE) Bulletin was released, CVE-2014-6278. Shellshock is a remote exploit for Bash which allowed arbitrary code execution on the remote host via several attack vectors in common server software stacks including Apache's cgi modules as well as OpenSSH.
The vulnerability affects all versions of Bash from 1989 until 2014 when it was patched once easily created exploits were widely demonstrated.
For further reading:
OWASP Shellshock Presentation, PDF
NIST CVE-2014-6278
ServerFault Shellshock Question, 2014
I believe most versions available in Distro Repos have been patched.
Correction: Shellshock is a family of vulnerabilities... CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
And, it's good to remember that these can easily affect a LAN if there exists port forwarding for things like Apache web servers or SSH... as well as any unpatched (and probably unpatchable) Internet of Things devices.
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
In 2014, there was a exploit in the wild for a Bash vulnerability nicknamed Shellshock. Like most vulnerabilities in common software, a Common Vulnerabilities and Exposures (CVE) Bulletin was released, CVE-2014-6278. Shellshock is a remote exploit for Bash which allowed arbitrary code execution on the remote host via several attack vectors in common server software stacks including Apache's cgi modules as well as OpenSSH.
The vulnerability affects all versions of Bash from 1989 until 2014 when it was patched once easily created exploits were widely demonstrated.
For further reading:
OWASP Shellshock Presentation, PDF
NIST CVE-2014-6278
ServerFault Shellshock Question, 2014
I believe most versions available in Distro Repos have been patched.
Correction: Shellshock is a family of vulnerabilities... CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
And, it's good to remember that these can easily affect a LAN if there exists port forwarding for things like Apache web servers or SSH... as well as any unpatched (and probably unpatchable) Internet of Things devices.
In 2014, there was a exploit in the wild for a Bash vulnerability nicknamed Shellshock. Like most vulnerabilities in common software, a Common Vulnerabilities and Exposures (CVE) Bulletin was released, CVE-2014-6278. Shellshock is a remote exploit for Bash which allowed arbitrary code execution on the remote host via several attack vectors in common server software stacks including Apache's cgi modules as well as OpenSSH.
The vulnerability affects all versions of Bash from 1989 until 2014 when it was patched once easily created exploits were widely demonstrated.
For further reading:
OWASP Shellshock Presentation, PDF
NIST CVE-2014-6278
ServerFault Shellshock Question, 2014
I believe most versions available in Distro Repos have been patched.
Correction: Shellshock is a family of vulnerabilities... CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
And, it's good to remember that these can easily affect a LAN if there exists port forwarding for things like Apache web servers or SSH... as well as any unpatched (and probably unpatchable) Internet of Things devices.
edited Nov 4 '17 at 21:55
answered Nov 4 '17 at 21:12
RubberStamp
1,4651216
1,4651216
add a comment |Â
add a comment |Â
up vote
4
down vote
Command separators are processed before expansions, therefore there is no way that n
, ;
, &
, &&
, or ||
in a variable will ever have an effect unless the variable contents are eval
ed.
add a comment |Â
up vote
4
down vote
Command separators are processed before expansions, therefore there is no way that n
, ;
, &
, &&
, or ||
in a variable will ever have an effect unless the variable contents are eval
ed.
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Command separators are processed before expansions, therefore there is no way that n
, ;
, &
, &&
, or ||
in a variable will ever have an effect unless the variable contents are eval
ed.
Command separators are processed before expansions, therefore there is no way that n
, ;
, &
, &&
, or ||
in a variable will ever have an effect unless the variable contents are eval
ed.
answered Nov 4 '17 at 20:46
Ignacio Vazquez-Abrams
32.1k66780
32.1k66780
add a comment |Â
add a comment |Â
up vote
3
down vote
It seems like globbing is a vulnerability:
$ echo 'echo $1' > injection.sh
$ bash injection.sh '/*'
/bin /boot /dev /etc /home /lib /lib64 /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var
This is why you always quote vars:
$ echo 'echo "$1"' > injection.sh
$ bash injection.sh '/*'
/*
add a comment |Â
up vote
3
down vote
It seems like globbing is a vulnerability:
$ echo 'echo $1' > injection.sh
$ bash injection.sh '/*'
/bin /boot /dev /etc /home /lib /lib64 /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var
This is why you always quote vars:
$ echo 'echo "$1"' > injection.sh
$ bash injection.sh '/*'
/*
add a comment |Â
up vote
3
down vote
up vote
3
down vote
It seems like globbing is a vulnerability:
$ echo 'echo $1' > injection.sh
$ bash injection.sh '/*'
/bin /boot /dev /etc /home /lib /lib64 /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var
This is why you always quote vars:
$ echo 'echo "$1"' > injection.sh
$ bash injection.sh '/*'
/*
It seems like globbing is a vulnerability:
$ echo 'echo $1' > injection.sh
$ bash injection.sh '/*'
/bin /boot /dev /etc /home /lib /lib64 /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var
This is why you always quote vars:
$ echo 'echo "$1"' > injection.sh
$ bash injection.sh '/*'
/*
edited Nov 5 '17 at 3:03
answered Nov 5 '17 at 2:57
wjandrea
462312
462312
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f402550%2fsql-style-injection-with-bash-input%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Shellshock? But I think most versions have been patched.
â RubberStamp
Nov 4 '17 at 20:46
@RubberStamp interesting I'd never heard of that looks like it was fairly recent.
â Philip Kirkbride
Nov 4 '17 at 20:48
1
Here's a description of how to test if you are vulnerable ServerFault Shellshock Question
â RubberStamp
Nov 4 '17 at 20:51
@RubberStamp I think if you post that as an answer it would be more correct. If this was patched in 2014 there are likely still a lot of old machines running vulnerable code?
â Philip Kirkbride
Nov 4 '17 at 20:58
1
In this case, if
echo
supports option-e
, you might be able to do something malicious with control chars or terminal escape sequences, but I can't find anything specific.â wjandrea
Nov 5 '17 at 3:08