是否有可能突破受限(自定义)外壳?

不确定这是否是问的地方。</ p>

说我 编写一个接受stdin输入,过滤该输入的shell,所以我们只说某些命令,例如</ p>


  • ls(二进制目录和子目录的列表内容)</ li>
  • 更新(git克隆)</ li>
  • 构建(开始构建)</ li>
  • 测试(进行测试)</ li>
  • 开始(systemctl启动此 </ li>
  • 停止(仅systemctl停止此service。)</ li>
  • 正在运行(正在执行该二进制文件并且具有多少个GOMAXPROCS?)</ li> \ n
  • 使用情况(内存,cpu使用情况)</ li>
  • gensvc(生成.service文件)</ li>
  • 退出(离开shell /注销)</ li>
    < / ul>

    工作,您猜对了,我正在尝试为用户提供通过ssh进行的非常有限的维护访问。</ p>

    说我对< code> \ 0 </ code>(无论如何,我都会使用bufio.Scanner在Go中编写它)</ p>

    是否有任何方法可以停止正在运行的shell并执行/ bin / sh或类似的方法 或以任何方式绕过此外壳?</ p>

    i dea是一个用户,用户应该通过git将自己的东西推送到一个裸仓库中,该仓库被克隆到文件系统中的某个目录中,然后调用go build并使用先前生成的systemd .service文件运行该二进制文件。 p>

    从逻辑上考虑,如果用户只能编写某些可以接受的字符串,则没有办法。 但是也许您知道其中一种,有些ctrl + z巫术;)或其他任何东西。</ p>

    唯一的攻击面是输入字符串或字节。 当然,用户可以git推送一个构建自己的shell或运行某些命令的程序,但这超出了范围(我将删除systemd的功能并限制设备访问,并禁止除与数据库服务器,专用tmp的连接之外的所有操作) ,命名空间和子命名空间(待办事项)</ p>

    我看到的唯一问题是git push,但我确定我可以在git only argv模式下解决该问题并将其添加到〜/ .ssh / authorized_keys中。 像 lish gitmode </ code>之类的东西,如果它们以git或类似的东西开头,则执行stdin命令。</ p>

    示例:</ p>

    < a href =“ https://gist.github.com/dalu/ce2ef43a2ef5c390a819” rel =“ nofollow”> https://gist.github.com/dalu/ce2ef43a2ef5c390a819 </ p>
    </ div >

展开原文

原文

Not sure if this is the right place to ask.

Say I write a shell that takes stdin input, filters this input so let's say only certain commands like

  • ls (list contents of binary directory and subdirectory)
  • update (git clone)
  • build (go build)
  • test (go test)
  • start (systemctl start this.service only)
  • stop (systemctl stop this.service only)
  • running (is the binary being executed and with how many GOMAXPROCS?)
  • usage (memory, cpu usage)
  • gensvc (generate .service file)
  • exit (leave shell/logout)

work, you guessed it, I'm trying to give a user only very limited maintenance access over ssh.

Say I'm careful with \0 (I'd write it in Go anyway using bufio.Scanner)

Is there any way to stop the running shell and execute /bin/sh or similar or any way to get around this shell?

The idea is a user should push their stuff via git to a bare repo, this repo is cloned to the filesystem to a certain directory, then go build is called and the binary is ran with a systemd .service file that is generated previously.

Thinking logically, if the user is only able to write certain strings that are accepted, no there is no way. But maybe you know of one, some ctrl+z witchcraft ;) or whatever.

The only attack surface is the input string or rather bytes. Of course the user could git push a program that builds its own shell or runs certain commands, but that's out of scope (I would remove capabilities with systemd and restrict device access and forbid anything but the connection to the database server, private tmp and all, namespace and subnamespace it TODO)

The only problem I see is git pushing but I'm sure I could work around that in a git only mode argv and adding it to ~/.ssh/authorized_keys. something like lish gitmode and execute stdin commands if they start with git or something like it.

Example:

https://gist.github.com/dalu/ce2ef43a2ef5c390a819

doubu5154
doubu5154 这是gitpushoriginmaster问题gist.github.com/dalu/d890bc70e898ff60dab1的答案如此简单,有时喜欢Go:)
接近 6 年之前 回复
doulong4169
doulong4169 嗯是的@isedevrbash是更通用的。我希望只允许用户“写入”某些预定义的命令(或接受),这些命令将执行预定义的操作。感谢您的建议tho:)。
接近 6 年之前 回复
dongzhansong5785
dongzhansong5785 受限制的外壳程序使您可以准确地决定用户可以执行的操作
接近 6 年之前 回复
dongtan7201
dongtan7201 确实,我需要锁定环境。命名空间,已删除的功能。最后是selinux,apparmor或rbac/grsec。因此,仅在某人以某种方式获取用户的私钥或凭据以通过ssh或使用凭据的管理控制台登录服务器的情况下,这才是真的。
接近 6 年之前 回复
duanqiao1961
duanqiao1961 我明确地不想为用户提供在文件系统中运行执行二进制文件的能力。
接近 6 年之前 回复
doukang5966907
doukang5966907 如果允许您推送通过gotest运行的代码,那么该代码肯定可以产生任何东西。
接近 6 年之前 回复
dongliping003116
dongliping003116 如果考虑安全性,也许您应该考虑使用标准的受限制外壳程序(例如rbash),并集中精力正确配置它。
接近 6 年之前 回复
dongzhuandian3292
dongzhuandian3292 有趣;是的,vim-Z似乎减少了一些选择。原始的vi包含得不太好。至少,您必须非常小心允许哪些编辑器。
接近 6 年之前 回复
duanpin5168
duanpin5168 如果以vim-Z开头,vim应该是安全的。
接近 6 年之前 回复
douhui1333
douhui1333 不要让他们使用像vim这样的编辑器。一旦他们使用了vim,他们就可以进入shell,然后随心所欲。您没有提及编辑,因此可能会很好。请特别注意build和test命令可能执行的操作。
接近 6 年之前 回复

3个回答



如果只允许使用某些命令,则您的“ shell”将读取该命令,将其解析然后执行,那么您应该 很好,除非我误解了。</ p>

去执行“内存”是不可能的,而且无论如何都不用汇编进行一些讨厌的修改,因此您不必担心shell注入 </ p>

以下几行应该是安全的:</ p>

  func getAction()(名称字符串,参数[]字符串){
//读取stdin以获取用户的命令
}

func doAction(){
表示{
动作,args:= getAction()
切换动作{
case“ update”:// 让我们假设完整的命令是:如果len(args)!= 1 {
// error
}
out,则更新https://repo/path.git
err:= exec.Command(“ / usr / bin / git“,” clone“,” --recursive“,args [0])。CombinedOutput()
//使用out和err进行处理
}
}
}
}
</ code> </ pre>
</ d 四>

展开原文

原文

If you're only allowed certain commands, your "shell" will read the command, parse it and then execute it then you should be fine, unless I misunderstood it.

Go "memory" can't be executed, not without you doing some nasty hacks with assembly anyway, so you don't have to worry about shell injection.

Something along these lines should be safe:

func getAction() (name string, args []string) {
    // read stdin to get the command of the user
}

func doAction() {
    for {
        action, args := getAction()
        switch action {
            case "update": //let's assume the full command is: update https://repo/path.git
                if len(args) != 1 {
                    //error
                }
                out, err := exec.Command("/usr/bin/git", "clone", "--recursive", args[0]).CombinedOutput()
                // do stuff with out and err
        }
    }
} 



如果您自己实现外壳程序并通过 exec()</ code>直接执行命令或在内部实现, 那么肯定有可能生产出安全的受限外壳。 如果您只是在将命令行传递给真实的shell之前只是对命令行进行了表面检查,那么可能会有一些您可能不会想到的极端情况。</ p>

话虽如此,我会有点 关注您列出的 test </ code>命令。 是否打算运行用户上传的Go软件包的测试套件? 如果是这样的话,如果我是攻击者,我什至不会尝试利用受限制的shell:我只是上传一个包含执行我想要的动作的测试的程序包。 对于 build </ code> / start </ code>也是如此。</ p>
</ div>

展开原文

原文

If you are implementing the shell yourself and directly executing the commands via exec() or implementing them internally, then it is certainly possible to produce a secure restricted shell. If you are just superficially checking a command line before passing it on to a real shell then there will probably be edge cases you might not expect.

With that said, I'd be a bit concerned about the test command you've listed. Is it intended to run the test suite of a Go package the user uploads? If so, I wouldn't even try to exploit the restricted shell if I was an attacker: I'd simply upload a package with tests that perform the actions I want. The same could be said for build/start.

douqiao7958
douqiao7958 是的,git push,克隆,构建,测试,生成服务,运行服务。 除了tcp outbound和tcp到本地数据库节点外,我需要完全隔离环境。 程序运行时,我需要确定什么都不能挂载,并且只写到预定义的目录中(如果是文件上传)。 私人tmp。 除了对/ dev节点的基本访问以外,所有其他访问都被禁止。 事实是,即使有人设法运行可通过http访问的shell,他们也不应以提升的权限运行任何东西。 我不知道该选择哪个答案。 我将其保持打开状态,两者都很好。
接近 6 年之前 回复



由渗透测试小组进行审核。 </ p>

突破任何类型的沙箱时,人们都可能很有创造力。 只有在您从不接受用户输入的情况下,您才能认为自己在场所中相当安全(但是这里的任何命令都是输入)-纸质安全性假设被认为是评估软件的薄弱环节。 它们类似于纸上算法的“无错误”假设:一旦实现,便有99%的时间会引发错误。</ p>
</ div>

展开原文

原文

Have it reviewed by a pentesting team.

People can be very creative when breaking out a sandbox of any type. Only if you never accept the user's input you can consider yourself rather safe on premises (but here any command is an input) - paper security assumptions are considered a weak to assess the software. They are similar to 'no-bug' assumptions for an algorithm on paper: as soon as you implement it, 99% of time a bug raises

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐