Any Network Attackers Can Execute Arbitrary Code to Destroy Users' System during Installation #25

Closed
biergaizi opened this Issue Jan 4, 2017 · 1 comment

Projects

None yet

2 participants

@biergaizi

Oh, yeah! Good old curl | sh via HTTP. Fucking awesome. I wonder how many people get unknowingly pwned while executing such curl | sh instructions. It's not hard at all to MitM HTTP, detect if shellcode is being transmitted, then add your own instructions to it. Or you can just compile a list of known sources that encourage to execute curl | sh and MitM only them if you want to make your exploits even more discreet. What a nice way to get yourself your own little botnet. Way to go! There's a catch though. You need access to infrastructure of ISP. But is it that hard to get such access? No.

Short-term Solution

Using https://spacevim.github.io or another HTTPS URL. If you are going to use a service like CloudFlare, make sure the upstream server also has HTTPS, and CloudFlare SSL/TLS is set to "Strict" mode.

Long-term Solution

Creating a proper installation process.

@biergaizi biergaizi changed the title from Any Network Attackers Can Execute Arbitrary Code to Destory Users' System during Installation to Any Network Attackers Can Execute Arbitrary Code to Destroy Users' System during Installation Jan 4, 2017
@wsdjeg wsdjeg added the enhancement label Jan 4, 2017
@mhinz mhinz added a commit to mhinz/SpaceVim that referenced this issue Jan 4, 2017
@mhinz mhinz README: address security concerns
Fixes #25.
eeca29a
@mhinz mhinz added a commit to mhinz/SpaceVim that referenced this issue Jan 4, 2017
@mhinz mhinz README: address security concerns
Fixes #25.
812f420
@wsdjeg wsdjeg pushed a commit that closed this issue Jan 4, 2017
@mhinz mhinz README: address security concerns
Fixes #25.
812f420
@wsdjeg wsdjeg closed this in 812f420 Jan 4, 2017
@wsdjeg wsdjeg reopened this Jan 6, 2017
@wsdjeg
Member
wsdjeg commented Jan 6, 2017

I will enable https for spacevim.org

@wsdjeg wsdjeg self-assigned this Jan 7, 2017
@wsdjeg wsdjeg added the in progress label Jan 7, 2017
@wsdjeg wsdjeg closed this in #59 Jan 7, 2017
@wsdjeg wsdjeg removed the in progress label Jan 7, 2017
@wsdjeg wsdjeg modified the milestone: 0.1.0 Jan 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment