You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current installation method can be exploited to cause arbitrary code to be executed on the client machine due to a timing difference between piping directly into bash and into stdout or another file. The user would be unable to detect such a malicious payload through conventional means.
I've noticed that your installer is based on a Chef tutorial. I've made a similar issue on their GitHub too.
Gif of exploit - Note different payloads depending on if it is output to bash or stdout:
The following command is insecure: curl https://getmic.ro | bash
This is because the server for https://getmic.ro can watch and delay the connection speed incredibly carefully and detect if the client is curling directly into bash, or if it is being output to stdout/into a file.
The consequences of this timing difference mean it's possible to send entirely different payloads for each scenario, evading detection from anyone who decides to look for the contents by outputting the downloaded data.
The way to fix this command:
The getmic.ro script needs to be output into a file before the user executes it. Otherwise different payloads can be used without any way for the user to verify what they're executing.
The following commands fix the security issue, but aren't as pretty and short. You might be able to improve upon this.
Any of the following will work instead and be more secure: curl https://getmic.ro > GetMicro; bash GetMicro curl -o GetMicro https://getmic.ro; bash GetMicro wget https://getmic.ro; bash index.html wget https://getmic.ro/install; bash install# This one will require a server-side change.
The text was updated successfully, but these errors were encountered:
Description
The current installation method can be exploited to cause arbitrary code to be executed on the client machine due to a timing difference between piping directly into bash and into stdout or another file. The user would be unable to detect such a malicious payload through conventional means.
I've noticed that your installer is based on a Chef tutorial. I've made a similar issue on their GitHub too.
Gif of exploit - Note different payloads depending on if it is output to bash or stdout:
Please read the following article to see how this exploit works:
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
How can this be fixed?
The following command is insecure:
curl https://getmic.ro | bash
This is because the server for https://getmic.ro can watch and delay the connection speed incredibly carefully and detect if the client is curling directly into bash, or if it is being output to stdout/into a file.
The consequences of this timing difference mean it's possible to send entirely different payloads for each scenario, evading detection from anyone who decides to look for the contents by outputting the downloaded data.
The way to fix this command:
The getmic.ro script needs to be output into a file before the user executes it. Otherwise different payloads can be used without any way for the user to verify what they're executing.
The following commands fix the security issue, but aren't as pretty and short. You might be able to improve upon this.
Any of the following will work instead and be more secure:
curl https://getmic.ro > GetMicro; bash GetMicro
curl -o GetMicro https://getmic.ro; bash GetMicro
wget https://getmic.ro; bash index.html
wget https://getmic.ro/install; bash install
# This one will require a server-side change.The text was updated successfully, but these errors were encountered: